This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] resolv/res_query.c - do not append search paths if number of dots in query is greater or equals ndots
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Canto ." <cantorek at gmail dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 20 Dec 2019 16:38:16 +0100
- Subject: Re: [PATCH] resolv/res_query.c - do not append search paths if number of dots in query is greater or equals ndots
- References: <CADk=2vb4_d5RMqouVTi+EMoX3ENuZN8eUv_ZaBWbVkya2vDvhA@mail.gmail.com>
* Canto .:
> When NXDomain response is received, resolver appends original query
> with search path and retries. It happens even if original query has
> more dots than ndots.
> It's causing unnecessary and excessive traffic to DNS servers,
> especially with environments based on DNS service discovery, where
> users often query for non-existent fqdns to local DNS server.
I'm worried that many users depend on this behavior. For example, the
Kubernetes documentation seems to suggest that KUBERNETES.DEFAULT is
searched along the search path even with the default ndots:1 setting.
The current stub resolver behavior makes it impossible to configure the
system in such a way that it follows the ICANN recommendations on search
list processing (bug 25163):
<https://www.icann.org/en/groups/ssac/documents/sac-064-en.pdf>
I believe your patch would bring us closer to the recommended
single-label/multi-label split (search processing vs no search
processing). But I don't think it's possible to get back the
old/current behavior through configuration, so this is not something we
can adopt as-is, sorry.
Do you want to continue working on this, maybe introducing a new
resolver option? Such a change would be slightly larger and likely
require copyright assignment to the FSF.
Thanks,
Florian