Re: [PATCH] resolv/res_query.c - do not append search paths if number of dots in query is greater or equals ndots

["Canto . via Libc-alpha" <libc-alpha@sourceware.org>]

Florian,

My sincere apologies for late reply. I've somehow missed your email.
I hope that not many people use this as a feature, it's very misleading.

I'll be more than happy to introduce this as an option.
If you have any recommendations, please let me know, I'll implement
them from the very start.

Thanks,
Oskar


pt., 20 gru 2019 o 16:38 Florian Weimer <fweimer@redhat.com> napisał(a):
>
> * 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
>


-- 

Best regards,
Oskar.