<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 28, 2017 at 7:29 AM, Florian Weimer <span dir="ltr"><<a href="mailto:fw@deneb.enyo.de" target="_blank">fw@deneb.enyo.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The fact is that some users push very hard for state tracking in the<br>
stub resolver because that's what they are used to from other systems,<br>
despite its inherent limitations. It's unlikely that we're going to<br>
implement this part of the glibc stub resolver, though, because there<br>
already many alternative solutions.</blockquote><div><br></div><div>It's not simply a matter of what the other systems do, it's also the extent to which things snowball when the first attempted server is unreachable. Most sysadmins without a degree in DNS do not realize how badly search domains interact with glibc's DNS module. Every search domain permutation will be attempted before resolution moves on to the second server, plus an additional attempt to resolve the absolute name if the <i>ndots</i> criteria is met (default: 1 dot). They're a force mutliplier to the timeout that makes the lack of state tracking for remote server availability extremely painful, and much greater than the 5 seconds that people like to talk about being a problem for mission critical applications.</div><div><br></div><div>We can have the usual discussion over the evils of search domains, but the reality is that 1) the math behind this snowball is not evident to most sysadmins consuming the manpage of resolv.conf, and 2) generally they do not get to choose the number of search domains that their employers require them to maintain support for. Mixed server environments typically require at least one because Active Directory exists, and a second because the *nix admins will run their own DNS servers if anyone gives them a say in the matter. That's two, and it only goes up from there.<br></div><div><br></div><div>To avoid a philosophical debate over whether glibc's behavior is the "right" one, I'll simply say that most users of glibc's NSS module for DNS (read: everyone who isn't on this list and a few more besides) don't understand the extent to which these factors multiply with each other. Without that data, it's hard for them to understand just how badly the defaults are going to impact their production environments when the first server goes down for any reason -- planned or otherwise. It's quite a lot of avoidable, repetitive pain that companies world over are forced to learn and re-learn because the math is not readily on the tin/user docs.</div></div></div></div>