RE: [musl] resolv.conf and ndots:5

["Briner Cédric (DI)" <Cedric.Briner@etat.ge.ch>]

Hi Rich and Quentin,
 
> > Hi,
> I followed up as you were leaving IRC:

Sorry for this, my bad ! 

> > ge.ch.app-5580-capitastra-rec-01.svc.cluster.local
> > [pid 1228780] recvfrom(3, "\2567\205\200\0\1\0\0\0\1\0\1\2ge\2ch\4ceti\7etat-ge\2"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.177.0.10")}, [16]) = 140
>                                   ^^^^^^^^
> 
> The low 4 bits of the underlined part of the response packet form
> RCODE=0, success. This is 10.177.0.10 saying the queried name does
> exist and just does not have an A record. (It might have AAAA records,
> MX records, whatever -- we can't know.)
> 
> Since normal recursive nameservers on the public internet correctly
> report RCODE=3 (NxDomain) for ge.ch.ceti.etat-ge.ch, something in your
> k8s cluster must be rewriting the answer to give an incorrect result.
> 
> glibc (like most traditional stub resolvers) handles this case
> sloppily and just treats NODATA and NxDomain the same, continuing
> search. This makes the results potentially unstable depending on
> whether the caller requested both v4 and v6 results or just one or the
> other, and semantically mismatches what's in DNS. musl handles this
> very intentionally with the aim of delivering only consistent results.


Thanks you for the detailed and precised response provided. That helped us a lot !

What I’ve learned is:
- that NODATA is considered as a valid answer, showing that this entry belong to the DNS ceti.etat-ge.ch
- that the dig command shows information on this respect in the section ->>HEADER<<-
  - it used to be status: NOERROR (saying that it belongs to this DNS, but have not an A record)
  - and it is now status:NXDOMAIN (saying that ge.ch.ceti.etat-ge.ch does not belong to this DNS)
- that musl has a different algorithm (stricter to the DNS rfc) than the other libc, which gives different results in our case

> Rich

With all my considerations.
Cedric (from Switzerland)