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

[<dominic.chambers@glencore.com>]

HI Rich,

Thanks for the prompt response here. Apologies for any confusion I may have created, but I think the server is responding with an overall `NXDOMAIN` response. This is what I get from running `dig google.com.default.svc.cluster.local`:

```
; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com.default.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20863
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.default.svc.cluster.local. IN A

;; AUTHORITY SECTION:
cluster.local.          60      IN      SOA     ns.dns.cluster.local. hostmaster
.cluster.local. 1489579200 28800 7200 604800 60

;; Query time: 0 msec
;; SERVER: 10.43.0.10#53(10.43.0.10)
;; WHEN: Wed Mar 15 12:49:14 UTC 2017
;; MSG SIZE  rcvd: 147
```

Although there's less information with nslookup, the response from running `nslookup google.com.default.svc.cluster.local` seems even more definitive:

```
Server:         10.43.0.10
Address:        10.43.0.10#53

** server can't find google.com.default.svc.cluster.local: NXDOMAIN
```

Maybe I was just reading too much into the output from dig regarding exactly what was being returned from the server. Any further thoughts?

Thanks again, Dominic.

-----Original Message-----
From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
Sent: 15 March 2017 13:25
To: musl@lists.openwall.com
Subject: Re: [musl] Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work

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-2239
> 01519
> 
> 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-2865
> 61614
> 
> 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
LEGAL DISCLAIMER. The contents of this electronic communication
and any attached documents are strictly confidential and they may not
be used or disclosed by someone who is not a named recipient.
If you have received this electronic communication in error please notify
the sender by replying to this electronic communication inserting the
word "misdirected" as the subject and delete this communication from
your system.