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
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 @myveryownresolverFor 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.
