Why would I want to have a local nameserver?

As thing are on the internet, having fast reliable access to a trustworthy dns resolver, both for looking up internal hosts and external hosts becomes increasingly more a thing that needs focus. Gone are the days where you could just trust anyone to tell you where things are, in other words, using a random nameserver.

In so many ways have we seen, over the last years, ways for ill intending people to cause trouble for DNS. These ways range from the hard to catch poisoning of zone data, to outright massive bombardments with data to overwhelm the name service system on a more global scale.

There are things we can, and possibly should, do to make things more difficult for those attacking "us". There is the relatively simple (once you get up up and running) DNSSEC, creating a tree of trust all the way from the root to the host that's being searched for, ensuring that others can have confidence in the results they are getting from lookups in your zone. There is the technique of anycasting the resolvers. which technically speaking is more of a network hack than something that needs to be done on the nameserver (more about this soon..). And the latest feature we've seen emerging is labeled as RRL (Response Rate Limiting) letting the server follow some rules controlling the way it responds to clients requests.

One of the really good reasons for taking a good look at RRL and either use what comes with the resolver or implement something similar ind the infrastructure in front of it is the very nature and friendliness of DNS servers. Basically, the way they operate is simple, a relatively small UDP packet arrives asking for a lookup of something, and the server sends a response back with some kind of reply.. That doesn't sound so bad.. but.

There are two well known attack vectors on this kind of behaviour.

First of all there is the fact that it's using UDP, this tells you (if you know your protocols) that it's stateless. To understand what this meens it's, in my opinion, simplest to learn what is meant by state by learning what happens when you have a statefull connection as you do with TCP. Tne whole state of TCP is negotiated at the very start of the communication between the connector (the client) and the listener (the server).

There are three stages to going from just throwing packets at each other, to have a statefull connection.. And yes, UDP really is just throwing packets at each other and hoping the other party hears you..

First thing that happens is the connector opens what is called a socket (network programming speak for a communications link) bound to it self (this happens for both UDP and TCP) and then comes the difference, at this point UDP is really ready to send now (the actual function you call is called send), but TCP has to get it ready first.

At this point TCP needs the connect call, that tries to do what the name implies, connect to the recipient. When this is done, and you look at the actual network traffic you will see a few things that are relevant here, a TCP packet is sent from the connector to the listener with some interresting details in, a TCP flag called SYN and an identifier called sequence number. This is the first packet in the "famous" three way handshake.

The listener, which has literallly been waiting for this to happen, sees the SYN packet, creates a local data structure to keep track of the connector and sends back a SYN/ACK package, signaling an acknowledgement of the connectors SYN with the ACK and sends an own SYN.

Now the connector responds with an ACK og the listeners SYN and the three way handshake is done.

Found this image on Wikipedia

The end result is two things, it's a lot harder to hijack an IP address for TCP than simply spoofing it for use with UDP. On the other hand, it takes 3 times roundtrip time befor you get any kind of conversation going. Meaning, the further there is between the connector and the listener the longer it takes before they start talking, amplified by a factor of three.

So, if your nameserver is on your LAN, with a roundtrip time of 0.1ms, you'll be able to measure the difference, but won't really feel it.. But if you're using a nameserver placed on another continent and have a roundtriptime of 300ms, there is suddenly a 1sek delay before any lookup of an internet hostname, doesn't sound like much, but it is really an unacceptable delay.

There is a fairly obvious solution to the problems of having a nameserver far away.. Move either yourself or the nameserver closer. For some the only option is to switch nameserver, but creating your own nmaeserver, if your allready know a bit of unix (linux, bsd, solaris or some other POSIX system) isn't really that much of a deal. Especially if you can set it up and close it down so abusing it for people other that a trusted "few" becomes very diffucult.

But this text is so long so I'll make a diffent post about that ;-)