3 ms·

> Even if a root server were to experience a major failure due to some sort of administration problem, there are twelve more. This usually does not help in cas

> Even if a root server were to experience a major failure due to some sort of administration problem, there are twelve more. This usually does not help in case of DNS. Let's say a resolver queries a root that does not reply. The resolver will time out after n seconds and then try another root server, but will not send any replies to the querying client. Therefore, the querying client has no way to know if it's the resolver that is broken or the upstream authoritative server and the querying client itself will timeout after m seconds and switch to another resolver, ignoring any possible later response from the first initialized query. If m is larger or equal to n, the problem is aparent -- client will never know if the root is broken or the resolver, usually treating the resolver as such.

fanf2 3y ago
Traditionally (in the Berkeley code) the timeouts in the stub resolver in libc are 3x longer than the timeouts in the iterative resolver in the recursive server. I don’t think this is specified or that the RFCs even have much to say about timeout periods or retry counts.
mike_d 3y ago
Maybe for a query or two, but the problem sorts itself out. Auth servers are very rarely running from a completely cold cache. Additionally most resolver software uses a system called scoreboarding where response times for each IP are recorded and it will prefer the fastest known nameserver for a query (some number of queries are still periodically sent to "slower" or unknown servers to gather metrics for them). Clients never treat a system resolver as "broken." Most operating systems will round-robin the list of available recursive servers when there is a timeout before returning failure to the software. In the case of web browsers and such, they'll retry with a resolver operated by the browser vendor before admitting defeat.
- hardaker 3y ago
  Minor note: authoritative servers don't have caches. I think you meant recursive resolver (or better "caching resolver" which covers other types of resolvers that may also be caching, such as some stub-resolvers).
  - mike_d 3y ago
    Yes, you are correct. I probably put the word auth there because I had just finished setting up a new cluster of authoritative servers.

fanf2 3y ago

Traditionally (in the Berkeley code) the timeouts in the stub resolver in libc are 3x longer than the timeouts in the iterative resolver in the recursive server. I don’t think this is specified or that the RFCs even have much to say about timeout periods or retry counts.

mike_d 3y ago

Maybe for a query or two, but the problem sorts itself out. Auth servers are very rarely running from a completely cold cache. Additionally most resolver software uses a system called scoreboarding where response times for each IP are recorded and it will prefer the fastest known nameserver for a query (some number of queries are still periodically sent to "slower" or unknown servers to gather metrics for them). Clients never treat a system resolver as "broken." Most operating systems will round-robin the list of available recursive servers when there is a timeout before returning failure to the software. In the case of web browsers and such, they'll retry with a resolver operated by the browser vendor before admitting defeat.

hardaker 3y ago
Minor note: authoritative servers don't have caches. I think you meant recursive resolver (or better "caching resolver" which covers other types of resolvers that may also be caching, such as some stub-resolvers).
- mike_d 3y ago
  Yes, you are correct. I probably put the word auth there because I had just finished setting up a new cluster of authoritative servers.