Home Many DNS servers is enough

[talep]

While Steve is working on DNS benchmark I came across a DNS topic which I think lot's of member here would find interesting.
One of my favourite podscasts called PING by APNIC which describe itself as a podcast about measuring the internet had a very interesting episode with the title "How Many DNS nameservers is enough".

It starts by asking why we have 13 root name servers ? does a big number of nameserver make sense considering most common clients and recursive resolves behaviour ?
Does spreading you nameservers globally , will really result in a client querying the nearest one ?
What DNS has to do with anycast ? and eventually what is the optimum criteria to where should you put your DNS nameserver.

I hope you will find it interesting as I did https://blubrry.com/ping_podcast/141791029/how-many-dns-nameservers-is-enough/

 

[AlanD]

Does spreading you nameservers globally , will really result in a client querying the nearest one ?

Apart from whether a DNS server will query the nearest root server, having a global spread means that, if a major interconnect goes down, "fairly local" services are still available.

 

[talep]

You are right about having multiple DNS servers spread globally in order to create highly available DNS service world wide will work, however implementing it by having a different address for each server globally appears to be less optimal due to DNS client (and by client I am also talking about recursive resolvers) behaviour.

One of the major problems is the inconsistency behaviour between different DNS clients.
A good solution to this problem is for example what Google are doing.
Ask yourself where is 8.8.8.8 located , the answer is everywhere since it is defined as as anycast ip https://ipinfo.io/8.8.8.8

What is really happening is that Google is taking advantage of BGP protocol always routes to the shortest path and declares this address in many other locations around the world where they keep their DNS server.

If a region goes down BGP protocol will take of the rest routing the packets to the new shortest path while the old one expired , until it comes back.

The optimal solution is actually a place with dense BGP presence so in case one path goes does there will be many other to choose from.

 

[AlanD]

The optimal solution is actually a place with dense BGP presence so in case one path goes does there will be many other to choose from.

Having a single server in a location with dense BGP presence will not avoid a problem if you have server hardware issues as opposed to network issues. Having multiple ( theoretical) clones in different locations gets round both problems.

 

[talep]

Obviously it is not a single server you will have a cluster of them serving as one , even if you go spreading your servers globally with different IPs you will still make them highly available.
And you would also create some sort of mechanism to detect faulty server and remove it's configuration ASAP otherwise you will have lots of clients querying a dead sever reaching timeout before giving up , and you can never know or assume client behaviour.

Same thing you would do to any DNS server even if you use BGP you would still need some mechanism to detect that the service is not responsive and remove the route.

Still you wil need to make sure you dont break all your DNS servers with configuration that will take them out of the BGP remember Facebook outage at 2021 , this is exactly what happened.