DNS and what have you

DNS, the beast. 

There is a lot to know about DNS and it keeps evolving in a steady pace.

A blog I like that focusses on the abuse part of DDoS DNS is dnsamplificationattacks. I even tried to setup a sort of the same infrastructure to see how long it would take for a resolver to be descovered and abused. The result? It takes mere minutes to be discovered [scanned by 122.136.196.116] and rather hour then days before your open resolver is used.

/var/log/syslog.1:Oct 15 13:25:25 vps1463 named[1376]: client 122.136.196.116#835: query: aa.10781.info IN ANY +E (91.213.195.47)
/var/log/syslog.1:Oct 15 13:25:25 vps1463 named[1376]: client 122.136.196.116#835: query (cache) 'aa.10781.info/A/IN' denied
/var/log/syslog.1:Oct 15 13:25:53 doknowevil named[18459]: client 198.206.14.130#33765: query: aa.10781.info IN ANY +E (91.213.195.47)
/var/log/syslog.1:Oct 15 13:25:53 doknowevil named[18459]: client 198.206.14.130#33765: query (cache) 'aa.10781.info/ANY/IN' denied
/var/log/syslog.1:Oct 15 13:25:53 manandmice named[11516]: client 198.206.14.130#33765: query: aa.10781.info IN ANY +E (91.213.195.198)
/var/log/syslog.1:Oct 15 13:25:53 manandmice named[11516]: client 198.206.14.130#33765: query (cache) 'aa.10781.info/ANY/IN' denied
/var/log/syslog.1:Oct 15 14:09:39 xxx.static.dimenoc.com named[429]: client 122.136.196.116#64794: query: aa.10781.info IN A +E (198.49.72.223)
/var/log/syslog.1:Oct 15 14:09:39 xxx.static.dimenoc.com named[429]: client 122.136.196.116#64794: query (cache) 'aa.10781.info/A/IN' denied

These 4 hosts are AS miles apart from one and other. None has ever functioned as a open resolver.

Then I wanted to find out a little more about the current state of the DNS protocol. When I started using DNS, it would use UDP for about everything but a zone transfer. That has changed with the Extension Mechanisms for DNS (EDNS0). Initially the larger requests originated from [poorly] implemented DNSSEC zones caused pain. Loads of TCP queries all of a sudden and the surprise results that came with it in different networks.

 RFC 4035 has something to say about DNSSEC and message sizes:

A security-aware name server MUST support the EDNS0 ([RFC2671]) message size extension, MUST support a message size of at least 1220 octets, and SHOULD support a message size of 4000 octets.

Come in:

OARC's DNS Reply Size Test Server

The maximim reply size between a DNS server and resolver may be limited by a number of factors:

• If a resolver does not support the Extension Mechanisms for DNS (EDNS), replies are limited to 512 bytes.
• The resolver may be behind a firewall that blocks IP fragments.
• Some DNS-aware firewalls block responses larger than 512 bytes.

The BIND resolver, since version 9.5.0, includes a feature to decrease its advertised EDNS receive buffer size (down to 512) when its queries time out. We've seen this lead to significant increases in TCP for DNSSEC-signed zones.

DNS-OARC built the DNS Reply Size Test Server to help users identify resolvers that cannot receive large DNS replies.

How To Use

To use the DNS Reply Size Test Server, simply use dig command line tool to issue a TXT query for the name rs.dns-oarc.net:

$ dig +short rs.dns-oarc.net txt

You can test a specific DNS resolver by using the @server feature of dig.

The output should look something like this:

rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
"192.168.1.1 sent EDNS buffer size 4096"
"192.168.1.1 DNS reply size limit is at least 4023 bytes"

The first three lines of the output are CNAME records in the response. The "x" numbers represent the sizes of successfully received responses at each step in the test. The final two lines are TXT records that provide information on the test results. Here we can see that the resolver advertised a receive buffer size of 4096 and the server was able to send a response of 4023 bytes.

If your test results in a reply size limit of less than about 4,000 you may want to investigate further. See the excellent write up here.

With all the dig'ing like

dig google.com ANY @myveryownresolver

came the desire for more useable statistics on what was going on in named land. Over at merit the there is a nice little tool that does exactly that. statDNS. The tool is called for what it does. The output is limited and that is what I was looking for to get an impression of what as happening.

For a little more info on the resolving ability side of things, I actually liked the CLI version of netalyzer. Ok it requiers java but on a trashable VPS that is not a real issue. Check here for sample output of one of the hosts I tried it on. It shows a lot more then only DNS resolving issues, and I was surprised to see the IPv6 tests it did. Guess there is still hope for v6 ;)

You made it to here, well done! Here´s a present.