In the last few posts on this topic, we’ve talked about the various bits and parts of the DNS system, from who pays to how it works to DNS tools. This time, we’re going to finish off DNS in this (probably record breaking for Packet Pushers) series, and talk about some various aspects of DNS security. The next section in this series on How The Internet Really Works (HTIRW) is the routing system, after which we’ll move into standards bodies and other parts of the Internet ecosystem. There are three elements to DNS security that are of interest: DNS based DDoS protection, DNSSEC, and protected DNS names. Let’s start with DNS based DDoS protection, using the illustration below.
In this diagram, a controlling host (shown in grey) is using a botnet to attack a server on some remote network. Simply put, the DNS system is updated to point the DNS record for the attacked device (or network) so it points at a cloud based cleaner service. This “cleaner service,” is really a data center with a ton of bandwidth and specialized processing designed to remove attack traffic while allowing legitimate traffic through. Arbor, for instance, makes hardware devices that provide this sort of service, but appliances are often combined with custom written software and intelligence streams to provide a complete service. The traffic is then tunneled, normally using a GRE tunnel, back to the edge router in the customer’s network. While I’m showing this as a function of DNS, it’s actually possible (and fairly common) to just update the BGP table to draw the attack traffic through the data center where the cleaner service is located.
DNSSEC is the second of the three security mechanisms that impacts the DNS space, illustrated below.
There are several ways in which a recursive DNS server can be persuaded to return the wrong information to DNS queries (Wikipedia has a good page describing several specific attacks). DNSSEC, specified in RFC4033, RFC4034, and RFC4035. These three RFCs describe a process where a domain name holder can generate a public/private key pair, and advertise a hash of the DNS record along with the DNS record itself. The hash advertised is created using the private key out of the key pair, and can be verified by building the same hash using the public key. An attacker cannot generate a matching hash without the private key, which the domain holder (is supposed to) keeps in strict secrecy. The host can thus validate the information received from the recursive DNS server, and either decide to attempt retrieving the information from another server, or from the TLD server itself, or to simply abandon the connection.
The final DNS related security system of interest is protected domain name registrations. There are two specific types of protection a domain holder can configure on a specific domain: domain encryption and protection against unauthorized domain transfers. The second is fairly common — generally implemented by most registrars, so we won’t spend a lot of time on it here. The second is something not a lot of domain holders take advantage of, but it’s something you should seriously consider if you hold a domain name in one of the TLDs that support it. The illustration below shows the whois results of a domain that has been encrypted.
As you can see, all the information about the person who holds the domain is encrypted. To find out any information about the domain holder, you must contact the registrar (in this case Network Solutions), who will then check with the domain holder on what information can be released, or will forward the contact request to the domain holder. This is an important protection for individuals — particularly children — who have domain names, but who prefer their contact information not be public knowledge. This discourages stalking and other privacy violations.
So that’s it for DNS — next time we’ll start looking at the routing system, particularly in the area of policy.