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.

DNSsec as is a solution, right?

Since the latest DNS patch horror for those who _still_ use BIND over DJBDNS or OpenDNS, a lot of smart people who know a lot more about DNS then you & me together have been pointing to DNSsec as an even better cure.

DNSsec is a bitch to setup and use, even the guruus over at SANS are reluctantly and carefully touching the DNSsec waters. To actually benevit from the sec part of DNSsec, the end user would need to 'see' something like a nice big fat green thingy when connected to a DNSsec protected website, right?

Unfortunatly DNSsec is still not really widely deployed. There is no buildin firefox [or anyother browser for that matter] support.

Well for Firefox there is an extention for all your needs, to for DNSsec there is too. Called the DRILL extention. It would not install on my FF 3.0.1 since the DRILL exention ‘will not be installed because it does not provide secure updates’. Solution: go to the about page, create a new bolean called extensions.checkUpdateSecurity and set it to false. Try again & fail again: the extention does not support FF 3.x

So much for the nice effort.