Farsight’s Advanced Exchange Access (AXA) is a suite of tools and library code that brings the Security Information Exchange (SIE) directly to the end-user’s network. This article explains some of the less documented AXA features and options.

Before reading this document, we recommend you become familiar with AXA basics and related technologies by reading the AXA Advanced Exchange document.

AXA Subscriber Tools

Farsight freely provides several end-user tools to stream AXA data. They are:

sratool/radtool: The AXA Swiss Army knives, used to test / debug SRA or RAD connections and stream presentation format AXA watch hits (sratool) or AXA anomaly hits (radtool). sratunnel/radtunnel: The AXA workhorses, used to tunnel binary SIE data. axamd_client: Convenience tool that is a RESTful client and doubles as a Python extension library, used to stream AXA hits formatted as JSON blobs.

Many of the features and options we’ll be discussing are isomorphic amongst all of the tools and examples will be given where appropriate.

AXA Watches

In the AXA world, the way an end-user registers interest in an asset is through what’s known as a watch. These are fundamental building blocks of AXA sessions. In order to get anything done, an end-user must specify one or more watches to inform the AXA server what she is interested in seeing.

There are four different types of AXA watches, each is described below:

Watches are referenced by tags. A tag is simply an arbitrary 16-bit integer label used to keep track of individual watches.

When connected to an SRA server, tags must be unique. Each watch will use a different tag.

When connected to a RAD server, watch tags can be reused. This is because anomaly modules are designed to be able to use multiple watches per invocation. This is accomplished by “bundling” together watches under a single tag.

Depending on the tool, tagging may be done explicitly by the end-user or implicitly, by the tool. Examples follow.

AXA Watch Examples: SRA

The following examples show how to watch for SIE messages on channel 204 containing the IP address, are in the CIDR block 192.168.0/24, or are in the *.farsightsecurity.com domain.


The end-user specifies a unique tag per watch:

$ sratool
sra> connect ...
sra> 1 watch ip=
sra> 2 watch ip=192.168.0/24
sra> 3 watch dns=*.farsightsecurity.com
sra> channel 204 on


With sratunnel, tags are generated internally so the end-user only needs to specify the -w option and the assets above:

$ sratunnel <strong>-w ip= -w ip=192.168.0/24 \
    -w dns=\*.farsightsecurity.com</strong> -s ... -o ... -c 204


With axamd_client, tags are also internally generated so the invocation is similar to sratunnel’s:

$ axamd_client --server https://axamd.sie-remote.net/ --watches ip= \
    ip=192.168.0/24 dns=\*.farsightsecurity.com</strong> --channels 204

AXA Watch Examples: RAD

The end-user wishes to invoke the domain_sentry service (which is delivered through RAD) and ensure the DNS name www.farsightsecurity.com always has the A record and the AAAA record 2620:11c:f004:0:0:0:0:104.


The end-user specifies the watches as in the sratool example above, but notice this time the watches are bundled using the same tag. This is to let the RAD server know that “all of these watches are to be used with the domain_sentry service invocation with the same tag”.

$ radtool<br />
...<br />
rad> connect ...
<strong>rad> 1 watch ip=
rad> 1 watch ip=2620:11c:f004:0:0:0:0:104
rad> 1 watch dns=www.farsightsecurity.com</strong>
rad> 1 anomaly domain_sentry types=a,aaaa


With radtunnel, tags are generated internally so the end-user only needs to specify the -w option and the IP asset as above.

$ radtunnel -w ip= -w ip=2620:11c:f004:0:0:0:0:104 \
    -w dns=www.farsightsecurity.com -s ... -o ...


With axamd_client, as above, tags are also generated internally:

$ axamd_client --server https://axamd.sie-remote.net/ --watches ip= \
    ip=192.168.0/24 dns=www.farsightsecurity.com</strong> \
    --anomalies domain_sentry types=a,aaaa

Rate Limiting

Rate limiting is used to limit the rate of incoming AXA messages as emitted from the server to the client. While it works for both SRA and RAD, it is primarily useful for high bitrate SIE channels such as the Passive DNS Channel Package channels and the DNS Errors channels.


The end-user wishes to watch for all SIE messages on channel 204 (a channel with an average bandwidth of 21Mbps) but only wishes to receive (at most) 10 messages per second.


With sratool, the end-user has the option to receive rate limit loss reports. As such, she specifies a rate limit value of 10 and a 5 second interval between server rate limit reports:

$ sratool
sra> connect ...
sra> rate 10 5
    10 per second; current value=0
    5 seconds between reports
sra> 1 watch ch=204
sra> channel 204 on
    missed 0 input packets, dropped 0 for congestion,
    dropped 57911 for rate limit, filtered 72417
    since 2016/10/11 14:25:32

With sratunnel (or radtunnel), rate limiting is specified as a simple command line option:

$ sratunnel -r 10 -w ch=204 -s ... -o ... -c 204

With axamd_client, like sratunnel, rate limiting is specified as a command line option:

$ axamd_client --server https://axamd.sie-remote.net/ --rate-limit 10 \
    --watches ch=204 --channels 204

Loss reports are not available with sratunnel, radtunnel, or axamd_client.


Sampling is a way to statistically sample a percentage of messages from the server. For example, if a value of 50 is chosen, AXA will return a uniformly distributed random 50% sample of the messages its watches catch. Enabling sampling with any of the tools is quite straightforward.


$ sratool<br />
sra> connect ...<br />
sra> sample 50
* OPTION sample 50.00%


$ sratunnel -m 50 -s ...


$ axamd_client --server https://axamd.sie-remote.net/ --sample-rate 50 ...

TCP Buffer Sizing

AXA allows the end-user to get or set the TCP send buffer size used by the server. As described in Increasing TCP Window Size on Stack Overflow https://stackoverflow.com/questions/14381303/increasing-tcp-window-size, these buffers serve to accumulate outgoing data that the stack has not yet been able to put on the wire and data that has been received from the wire but not yet read by your application respectively. In simpler terms, if you know what you’re doing, these options allow the end-user to adjust the size of the in-kernel TCP buffers presumably with the goal of optimizing network performance. As an aside, these options do not directly adjust the TCP window size (see TCP Windows and Window Scaling http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/ for more information).

Note that internally TCP actually allocates twice the size of the buffer requested (using the extra space for administrative purposes and internal kernel stuff. This is why when you set a value, AXA returns to you a buffer size that is twice the size you requested. The minimum size is 1024 and the maximum is 262142. Only sratool and radtool support this option for TCP-based connections.


With sratool, getting and setting the window size is easy:

$ sratool
sra> connect ...
sra> window
* OPTION bufsize=262142
sra> window 8192
* OPTION bufsize=16384


AXA has a series of server-side packet counters used to track traffic totals. They are fully described in Farsight’s Advanced Exchange Access Internals: Understanding Accounting https://www.farsightsecurity.com/txt-record/2015/09/24/mschiffm-axa-accounting/.


Requesting accounting totals with sratool:

$ sratool
sra> connect ...
sra> acct
* OK ACCOUNTING total-filtered=113564 total-missed=0 total-collected=0
    total-sent=1 total-ratelimited=0 total-congested=0


With sratunnel, accounting totals can be synchronously emitted to stdout every five seconds with the following:

$ sratunnel -d -A 5 -s ...
ACCOUNTING total-filtered=4247 total-missed=0 total-collected=0
    total-sent=1356 total-ratelimited=0 total-congested=817

(The -d option enables debug mode which is required to see accounting output.)


With axamd_client, accounting totals are sent by default every 60 seconds. This value is tunable using the –report-interval option:

$ axamd_client --report-interval 10 ...
    total-missed=0 total-collected=2912 total-sent=0
    total-ratelimited=0 total-congested=0"}

Commands File

Both sratool and radtool provide a convenience option that enables the end-user to specify commands to run prior to command invocation. This feature provides the end-user with a simple mechanism to script commonly used commands. A commands file is a text file with valid newline-delimited sratool or radtool commands.

A common example is to script the connection procedure. In the following example, we setup a commands file that will connect to a RAD server and list the anomaly modules we are provisioned for:

$ cat > radtool.cmd
connect tls:user@axa-server,1022
list anomalies
$ radtool -c radtool.cmd
* HELLO radd version 1.4.1 axa-server AXA protocol 1
      * domain_sentry        [10/10]
      * brand_sentry         [5/5]

The output of the list anomalies command presents the end-user with the list of currently provisioned anomaly modules as well as the number of available domains and IP prefixes for domain_sentry and the number of available brands for brand_sentry.

Additional Information

About Farsight Security

Farsight Security, Inc. is the world’s largest provider of historical and real-time DNS intelligence solutions. We enable security teams to qualify, enrich and correlate all sources of threat data and ultimately save time when it is most critical - during an attack or investigation. Our solutions provide enterprise, government and security industry personnel and platforms with unmatched global visibility, context and response. Farsight Security is headquartered in San Mateo, California, USA. Learn more about how we can empower your threat platform and security team with Farsight Security passive DNS solutions at www.farsightsecurity.com or follow us on Twitter: @FarsightSecInc.

This document was originally published on Farsight’s blog as Advanced Exchange Access: The Missing Manual by Mike Schiffman https://www.farsightsecurity.com/txt-record/2016/10/20/mschiffm-axa-missing-manual/