Re: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work

[Rich Felker <dalias@libc.org>]

On Wed, Mar 15, 2017 at 10:28:15AM +0000, dominic.chambers@glencore.com wrote:
> As you can see from the comments starting here:
> 
>   https://github.com/gliderlabs/docker-alpine/issues/8#issuecomment-223901519
> 
> quite a number of people are finding that the `search` and `domain` support added to musl libc doesn't work in their case. In that same issue I wrote my findings up, here:
> 
>   https://github.com/gliderlabs/docker-alpine/issues/8#issuecomment-286561614
> 
> which I'll duplicate here so that's it's archived on the mailing list:
> 
> [...]
> 
> While I can confirm the second part (queries greater
> than `ndots` never fall-back to using search), the first part
> (queries smaller than `ndots` fall-back to using an absolute query)
> isn't what I observe.
> 
> Using dig on an Ubuntu container and attempting to resolve the
> nonsensical query `google.com.default.svc.cluster.local` (simulates
> the type of initial query for a short domain that would be
> occurring) returns a `QUESTION SECTION` and an `AUTHORITY SECTION`,
> but no `ANSWER SECTION`. This should cause musl libc to attempt to
> resolve the absolute query (`google.com`) instead, yet it doesn't
> seem to based on the final result of the query.

This is where your problem lies. A response with an empty answer
section is an affirmative answer that the requested name exists but
has no records of the requested type (A or AAAA). In this case the
answer must be accepted; otherwise results are inconsistent depending
on how the query is performed. See the previous discussion of the same
topic here: http://www.openwall.com/lists/musl/2017/01/19/4
and commit 0fef7ffac114befc94ab5fa794a1754442dcd531.

To fix the problem, whatever local nameserver is returning affirmative
no-A-record results for nonexistent domains needs to be fixed to
return NxDomain.

Rich