Farsight - the Public Benefit Company that works to sustain the spirit of the Internet - is expanding the capacity of our Passive DNS System. Passive DNS provides the industry greater insight into how the cyber-criminals are using DNS to violate the Internet. Vetted organizations are invited to join the Passive DNS network by configuring their DNS infrastructure to be a Passive DNS sensor. Once you join, your system becomes a part of the global Passive DNS network, helping to fight against cybercrime gaining you access to new and effective tools.
Passive DNS is a very scalable network design and has minimal operational impact. As an additional bonus for participating, all vetted organizations that contribute Passive DNS will have access to the DNS Database (DNSDB) at the Farsight Security Information Exchange (SIE) – an investigative tool that we use to analyze the cyber-criminal’s use of DNS. By participating in this effort, you are expanding the data collected, thereby enabling greater insights into how the cyber-criminals are using DNS to exploit the Internet.
Your organization's IP addresses can also appear in other parts of the packet as well, for instance if there are any authoritative DNS servers in your IP address space, and your resolvers query those authoritative DNS servers. e.g., I see the zones "abc.xyx.edu" and "abcxyz.com" are hosted on DNS servers in the 192.0.2.0/24 net block. If your resolvers weren't stealth secondaries for those zones those queries and responses would be captured, just like any other DNS zone.
If you wanted to exclude DNS transactions for your own zones we have a qname filtering feature that can be activated by setting an environment variable in the sie-dns-sensor config file, e.g.:
DNSQR_FILTER_QNAMES_EXCLUDE="abc.xyz.edu:abcxyz.com"This will exclude any DNS transaction whose qname matches .abc.xyz.edu or .abcxyz.com from being captured.
In order to received redistributed raw Passive DNS data, we require that a physical server be co-located at one of our redistribution nodes, and that a non-disclosure agreement and master services agreement be signed. Additionally we require a high degree of trust, for example an individual may be vetted via opsec-trust https://ops-trust.net/ or a similar community. We don't make our list of sensor operators and vetted researchers publicly available. However, do provide the list to any of the Passive DNS contributors and make introductions.
Most of the researchers performing analysis on our Passive DNS data make use of a heavily de-duplicated stream of data that aggregates data from all of the organizations providing us with raw Passive DNS data. for further details please see our presentations at DNS-OARC and def con last year:
https://www.dns-oarc.net/files/workshop-201010/edmonds_sie.pdf
https://www.defcon.org/html/links/dc-archives/dc-18-archive.html#Vixie
This de-deduplicated data format contains fewer details than the raw format and is more anonymized.
If the revelation of the IP addresses of your recursive nameservers to SIE and SIE's trusted partners is a deal breaker for your organization we would be willing to commit to doing custom development work to implement a mode which zeroes out the address of the recursive nameserver in captured packets. This would necessitate performing UDP checksum verification in the capture tool prior to modifying the IP header.
We do capture the full and complete IP datagrams sent between the recursive nameserver(s) being monitored and the authoritative nameservers that are contacted, including the original IP header and the IP source and destination addresses. Our end goal is to perform Passive DNS replication (for details, see Florian Weimer's original 2005 FIRST paper and presentation, http://www.enyo.de/fw/software/dnslogger/#2), i.e. the replication of historical DNS zone content, rather than the monitoring of the query stream sent by individual recursive nameservers. That is, we are interested in recording a history of individual DNS records as served by authoritative nameservers on the internet, rather than in monitoring what records are being queried for by individual recursive nameservers.
At a minimum we do need to capture the IP address of the remote authoritative servers (the IP destination address in queries, and the IP source address in responses) in order to perform what we call "Passive DNS bailiwick verification", and we do need to capture the IP address of the recursive nameserver in order to perform verification of the UDP checksum, which covers the IP source/destination addresses.
The sie-dns-sensor and sie-scripts packages start the sensor in "capture RD=0 DNS transactions only" mode. This causes the sensor to capture the following types of data:
all query/response UDP pairs where the DNS query has the RD ("recursion desired") flag cleared.
all unanswered UDP queries where the RD flag is cleared.
all unsolicited UDP responses where the RD flag is cleared.
Note: Additionally the sensor also captures TCP traffic initiated by the recursive nameserver and ICMP traffic related to UDP queries sent or responses received by the nameserver.
This means the sensor captures all packets between the recursive nameserver and the authoritative nameservers that it talks to. We explicitly do not capture any traffic sent from or to individual stub clients (RD=1 traffic) for obvious privacy reasons.
We consider the fact that we only capture the RD=0 traffic generated by the recursive nameserver as a result of a cache miss to provide the first layer of "sanitization" or "obfuscation", as the caching performed by recursive nameservers masks the pattern, volume, timing, and identity of individual client queries sent to the recursive nameserver for a particular record.
Yes, we support some binaries. We supply a pre-packaged version of our sensor code along with startup scripts and config files here:
https://dl.farsightsecurity.com/dist/sie-dns-sensor/
These binaries are for Red Hat and Debian based distributions for the amd64 and i386 architectures. we also have a set of scripts for other platforms (including Freebsd ports) available here:
We try to keep external dependencies to a minimum. Most systems already have tcpdump installed which includes the libpcap needed by the sensor. If you don't already have libpcap installed, please install it before installing the sensor package.
Our the schema that is used for our Passive DNS data is located in the nmsg/isc/dnsqr.proto file. The DNS sensor itself is implemented in a self-contained file nmsg/isc/dnsqr.c.
Yes, SIE Passive DNS Sensor is professionally managed and freely available open source. It is available from:
https://dl.farsightsecurity.com/dist/nmsg/
At this time, there is no support contract for our Passive DNS Sensor. The public benefit project is support through donations to the SIE Forum.
"Passive DNS" or "Passive DNS replication" is a technique invented by Florian Weimer in 2004 to opportunistically reconstruct a partial view of the data available in the global Domain Name System into a central database where it can be indexed and queried.
Passive DNS databases are extremely useful for a variety of purposes. Malware and e-crime rely heavily on the DNS, and so-called "fast flux botnets" abuse the DNS with frequent updates and low TTLs. Passive DNS databases can answer questions that are difficult or impossible to answer with the standard DNS protocol, such as:
For further reading, please check the following papers:
The Farsight Passive DNS Architecture document is located at: https://www.farsightsecurity.com/assets/media/download/passive-dns-architecture.pdf.