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

[Doug Barton]

May 4 2016 12:52 AM, "Nico CARTRON" <nicolas at ncartron.org> wrote:
> Hi Florian,
> 
>> On 04 May 2016, at 09:05, Florian Weimer <fweimer at redhat.com> wrote:
>> 
>> Our stub resolver currently has a hard limit for 6 search domains that can be specified in
>> /etc/resolv.conf. We are considering lifting that limit. Apparently, this is desirable for
>> deployments which migrate from NIS host name lookups to DNS because NIS supports a larger number of
>> default domain names (or something equivalent to that).
>> 
>> From a larger ecosystem perspective, do you think that longer search paths would increase resolver
>> load in an unacceptable way? For example, host name lookups with a 10-element search path could
>> easily require 20 queries.
> 
> How many search domains are you thinking of?
> 20? 50? No limit?
> 
> I've seen Windows clients with long lists (15+); while this didn't really affect resolution times
> seriously, there was a collateral effect: the cache was much bigger with of course a lot of
> NXDOMAIN for all the tested search domains.

My experience is the same as Nico's, in fact I've seen higher numbers when an enterprise that started off with 10 or 12 sites in the search list was undergoing a massive IP address renumbering + domain name refactoring at the same time. So for almost every one of the original names there was now a new version of the same name at the top of the list, and the old names at the bottom; about 20 in all. 

There was a statistically significant change in load on the resolvers, but one of the things we did was refactor the list so that any query for an existing name was answered on the first or second try. So when I say "change" above what I mean is that the load went *down*, since the previous list was a mess. :) The biggest user complaint was that when someone fat-fingered a name it took a measurable amount of time for the NXDOMAIN to come back. But fortunately the goal was to remove the old names from the list down the road, so hopefully they actually did that. 

All that said, I don't see any harm in raising the limit on a Unix'y system, but I would not remove the limit entirely as doing so may introduce a DOS vector. I would set it to something ridiculously high like 30 (or better yet, 31 since it's a prime).  :)

hth,

Doug