DNS resolver vs NS record TTL

Solution 1:

When a DNS resolver lookup a domain/zone for an authoritative name server, does it take in all 6 records and cycle through them ?

Yes, a proper recursive nameserver takes into account all nameservers and will try to query each time later the fastest one.

A rough algorithm is kind of:

• from a cold start (no cache), try all of them randomly, record how fast they reply (you might need to separate the UDP case from the TCP case there)
• after some time, start to use more frequently the fastest one based on previous replies
• but note that you need to make sure not to stick indefinitely with any given nameserver, you have to try "from time to time" the other ones too. Why? Because the network topology can change, as well as the nameservers themselves. ns3 might be the faster one today for your specific vantage point, but maybe tomorrow it is ns5 instead; so you have to use the fastest one, but not always, just to make sure to be able to automatically discover any other one faster than the one you believe to be the fastest right now.

If a resolver use the 1st NS server

Stop here. Records are coming in a set, not a list. That is there is no inherent order in the DNS. Of course there is an order in the wire or display representation, but it does not come from the protocol.

Records sets are bags: you get records, without orders. In fact, you can see that many nameservers, for the exact same query, if there are multiple records in the reply, will order the records differently each time you query, exactly to combat client systems that would only take into account the first item and disregard the others.

when that authoritative name server is not responding

See algorithm above: if one of the nameservers in the NS set is not responding, you can consider it to be the same as "replying as slowest from any other one". The client DNS has timeouts so it won't wait infinitely but mark this specific nameserver has too slow, and will switch to other ones. So at first time you incur a penalty because the system has to try to contact that nameserver, wait a little (few seconds), retry and at some point stop using that nameserver. After that ramp, it will use the other nameservers and things will be fast. But the first time you have to discover a given nameserver is slow/not responding by really trying to contact it, you can't infer the problem without trying.

Does that mean i need to set short TTL for NS records ?

Maybe, but it is mostly irrelevant. Why? Because your NS records are published in the parent zone of your domain, to ensure the DNS delegation. They are published there with a TTL of course, as all records have a TTL attached to them, but they are published in a zone you don't control, hence you can NOT choose their TTL values!

(There is a complicated/not completely finished discussion here about those records, like NS that exist in two parts: the parent and the child, with the question "which one is really authoritative"? If the parent has a TTL of 1 week on NS records and you in your zone the same NS records have a TTL of 1 second, what should the recursive nameserver do? One might arrive to the conclusion that normally the child part of the delegation IS authoritative, so 1 second wins here; in practice multiple DNS implementations are "parent-centric" that is they use the data at the parent side, so 1 week wins there)

TTLs are always a trade-offs. Once known some people are immediately jumping to the conclusion that things work better with very low TTLs... which is true for some cases and not so much for others. Caches are good, if they were not there (aka: not using big enough TTLs) you are not resilient against any small problems, that would make everything vanish because caches would have expired the names already.

Also the TTL value has no (or little) impact for the algorithm above in cycling along all nameservers, trying with timeout and converging on the fastest one.

So if you look at what happens in TLD nameservers (that host NS records for all domains under that TLD) or in various recommendations, you will often see NS records with a TTL of 1 or 2 days.

Any advise on how resolver DNS works with non-responsive NS and its TTL ?

Each resolver does its own :-) This is not really specified by the protocol, it is an implementation detail. You can study source code for the one you can install, but probably won't be able to gather details about that from big public recursive DNS providers.

You can find more details though here:

• https://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/
• https://www.nanog.org/meetings/nanog54/presentations/Tuesday/Yu.pdf

RFC 1034 §5.3.3 does give some information too (note also that it takes into account one case you forgot: a given nameserver may have multiple IP addresses - today even it should always be the case, with one IPv4 and one IPv6 - and there is no guarantee you get results in the same amount of time with each):

In addition to the names and addresses of the servers, the SLIST data structure can be sorted to use the best servers first, and to insure that all addresses of all servers are used in a round-robin manner. The sorting can be a simple function of preferring addresses on the local network over others, or may involve statistics from past events, such as previous response times and batting averages.

Step 3 sends out queries until a response is received. The strategy is to cycle around all of the addresses for all of the servers with a timeout between each transmission. In practice it is important to use all addresses of a multihomed host, and too aggressive a retransmission policy actually slows response when used by multiple resolvers contending for the same name server and even occasionally for a single resolver. SLIST typically contains data values to control the timeouts and keep track of previous transmissions.

RFC 1035 §7.2 has this to say:

To complete initialization of SLIST, the resolver attaches whatever history information it has to the each address in SLIST. This will usually consist of some sort of weighted averages for the response time of the address, and the batting average of the address (i.e., how often the address responded at all to the request). Note that this information should be kept on a per address basis, rather than on a per name server basis, because the response time and batting average of a particular server may vary considerably from address to address. Note also that this information is actually specific to a resolver address / server address pair, so a resolver with multiple addresses may wish to keep separate histories for each of its addresses. Part of this step must deal with addresses which have no such history; in this case an expected round trip time of 5-10 seconds should be the worst case, with lower estimates for the same local network, etc.

Note that whenever a delegation is followed, the resolver algorithm reinitializes SLIST.

The information establishes a partial ranking of the available name server addresses. Each time an address is chosen and the state should be altered to prevent its selection again until all other addresses have been tried. The timeout for each transmission should be 50-100% greater than the average predicted value to allow for variance in response.

Also to finish and more specifically about this:

As illustrated in this writeup from imperva

This article you reference talks about the issue that happened for people using Dyn nameservers, when there was an outage. Then, yes, if you use only Dyn nameservers you have a problem. As even if you change your zone to use other ones, the NS records TTL means your change won't be seen immediately. But that in reality does not say a lot about TTLs but just says a lot about DNS management: if you want to be resilient, for important zones, do not use a single DNS providers, but multiple ones (which of course mandates some coordination between them you can not just arbitrarily mix and match provider X and Y, and it is even more complicated if you through DNSSEC into the mix, but is possible). That way, exactly because of the algorithm quickly drafted above, even if 2 out of 5 let us say nameserver are failing to reply completely because this specific provider has a problem, the other will take the load and make your domain work. There might be an extra delay at each new query for visitors (because all recursive nameservers can not immediately understand that they have to switch to specific nameservers because 2 out of 5 are down), and also more delays because the other 3 are overwhelmed with more queries than normal (the DNS is load balancing by default so in theory each nameserver gets roughly the same volume of queries), but still a reply will be given.

PS: not asked for, but as it is sometimes not clear, all records in a given recordset have to have the same TTL. The TTL is per record, but needs to be the same in a given recordset, which means for a given tuple of (name, record type) [and class, but no one uses anything besides IN as class]