[dns-operations] Increasing the number of search path entries in a stub resolver

[Andrew Boling]

On Wed, May 4, 2016 at 6:14 AM, Paul Vixie <paul at redbarn.org> wrote:
>
>
> above six, i'd hope you sent some or all of the queries in parallel, and
> turned on the round-robin option, to avoid server microbursts.
>
> otherwise this sounds quite reasonable.
>
>
+1. Additionally, deployments not meeting this criteria can run into
significantly delayed resolution times when the first nameserver in
/etc/resolv.conf is unreachable. I've seen scenarios in mixed environments
where /etc/resolv.conf is pointing at domain controllers (directly, no LB),
and the AD admins assume that impact of a downed DC is minimal if one
server still responds. This interacts poorly with applications that are
sensitive to long delays in lookups. If I recall correctly, glibc will make
one attempt against the first server for every DNS search suffix before
moving on to the next server. Please correct me if this has changed in
recent years.

This isn't a new problem, and increasing the number of search domains only
increases the damage that the operators can do to themselves. It's just
worth the periodic reminder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160523/ce26571c/attachment.html>