<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 4, 2016 at 6:14 AM, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br></span>
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.<br>
<br>
otherwise this sounds quite reasonable.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>+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.</div><div><br></div><div>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.</div></div></div></div>