Internet Performance Delivered right to your inbox

Setting Up Secondary DNS for Redundancy and Security in a Volatile Internet Environment

DNS Administration

So far in our series we explored DNS records to perform work, the zones which contain them, and the delegation allowing their navigation. Up to this point, we have a zone on a single provider with our answers. What happens if that provider has a problem? A very common topic is that of multiple provider DNS configurations. While the specifics have been covered in depth in a different piece, the terms related to that process belong here.

In order to have multiple providers, the zone files between them must be in sync, as any nameserver in the delegation might receive the traffic. Historically, this has been performed by a process of a Master DNS server, which handles zonebfile management updating a Secondary DNS server. Today this is performed by letting the secondary know that there’s an update via a NOTIFY which activates the secondary to compare the serial value in the SOA record which designates the version of the zone.

If the master serial is higher, it is time to update. The secondary may initiate an IXFR to get the changes that have occurred between those two serials, or will perform an AXFR for the whole zone in cases where the number of changes is too large or this is the first time loading the zone or if it does not support IXFR. Because this update process is a sensitive one, a Transaction Signature (TSIG) can be used to ensure the master DNS server really is who it says it is by way of a symmetric key verification.

Nameserver Selection and Announcement

From the perspective of the recursive, all of this is hidden. The only thing the recursive will see is a list of nameservers handed out by the parent delegation. Whatever relationship those nameservers have is completely lost. If that’s not how the resolver chooses which nameserver to send traffic to, how does traffic actually get there?

To start the process off, if the resolver is just getting the delegation for the first time it will merely pick one randomly and send the first query off. After that, it might continue using that same name server. To improve performance, however, it may then mark down the Round Trip Time (RTT) – the time between when the query was sent until the reply was received. It may then send the next query to one of the other unknown nameservers and repeat the process until all the known nameservers have a round trip time associated with them.

Many resolvers will then use these times to send more traffic to the fastest nameserver. This is called nameserver affinity, or a preference for some NS over the others. This accelerates responses for users and reduces some process time for the resolver. In order to adapt to changes, resolvers will periodically test the nameservers that responded more slowly to see if an improvement has occurred.

That is how the resolver chose which nameserver to go to, but how did the resolver get to the DNS server itself? While this lies in network engineering, there are two terms which are important to DNS itself. One way of operating a network is to have a one-to-one relationship in the number of servers to nameservers, and announce these like any other address. This is what is called a unicast announcement strategy.

This can present problems however. As we mentioned above, the resolvers are going to try every NS—including those which might be on the other side of the world. Furthermore, an attacker could deliberately target a nameserver because the IP maps to a single location. To combat this, network engineers use a technique called anycast, in which the routes to a single IP for a nameserver are announced from many locations on a regional or global network leading to greater performance and reliability. For modern DNS providers, this has largely become a standard practice.

One of the ways network operators will combat an attack is through use of Response Rate Limiting (RRL). RRL is a fairly simple concept. The response of a query is usually much larger than the request, so if unnecessary queries are identified, filtration will result in less impact on the network. If a resolver is respecting the TTL, then any answer handed to it should be used for the cache to any query within that time period. If additional queries are sent to the authoritative, the TTL is not being respected, and the query may be filtered.

Volumetric attacks such as the Distributed Denial of Service (DDoS) operators use RRL to address are a major security concern in modern DNS administration. The other large security concern is that of Man-in-the-Middle (MITM) attacks. These occur when traffic en route to a destination is intercepted for spying or manipulation. To address this, DNS Security Extensions (DNSSEC) were created to provide a level of trust in responses. This is a subject so involved we will cover it in full when we convene for our final article in the series.

Share Now

Matt Torrisi
Whois: Matt Torrisi

Matt Torrisi is a Senior Solutions Engineer at Oracle Dyn Global Business Unit, a pioneer in managed DNS and a leader in cloud-based infrastructure that connects users with digital content and experiences across a global internet.

Find out more about the fundamentals of DNS and how it actually functions in the real world.

Learn More

To current Dyn Customers and visitors considering our Dynamic DNS product: Oracle acquired Dyn and its subsidiaries in November 2016. After June 29th, 2020, visitors to will be redirected here where you can still access your current Dyn service and purchase or start a trial of Dynamic DNS. Support for your service will continue to be available at its current site here. Sincerely, Oracle Dyn