Re: Re: Would love to see reconsideration for domain and search

Re: Re: Would love to see reconsideration for domain and search

[Jan Broer]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

A very interesting discussion going on here.

> You can't query all nameservers and just take
> the first NXDOMAIN to respond.  You can only accept NXDOMAIN if all of
> the higher-priority (listed first in resolv.conf) nameservers have
> timed out or SERVFAIL'ed.  You can issue queries in parallel, but you
> must process responses in order, which is what you describe below.

GNU libc resolver gives priority to the primary nameserver because it
assumes that this is the one with the lowest RTT / highest availability.
This priorization was never understood as meaning that the primary's
servers records are more "authorative" than those of secondary nameservers.

> My view has always been that multiple
> nameservers in resolv.conf are for redundancy, not for serving
> conflicting records.

I agree.

>I have to disagree.  Some non-forwarding DNS servers use SERVFAIL to
>indicate "I am not serving for that domain" specifically to make the
>client move to their next nameserver.  if ns1 returns SERVFAIL, try
>ns2.  If ns1 times out, try ns2.  Otherwise what good is ns2?

This kind of result unioning you want from musl-libs isn't even supported
by GNU libc resolver. Yes it works for you - but this is because your DNS
server is breaking DNS RFC specs: SERVFAIL is not a technically legal
response for  "I am not serving for that domain". It's just WRONG. When an
authorative server (which the Kubernetes DNS server is) doesn't serve a
specific zone it has to respond with  NXDOMAIN. Of course if your server
would follow the rules than that type of result unioning doesn't work
because GNU libc resolver does not failover to secondary servers when the
response is NXDOMAIN.
It's just a weak argument to essentially say: "The GNU libc resolver does
exactly what i want when i point it to my broken DNS server, why can't
musl-libc?".

The bottom line:

Leave nameserver querying logic as it is: Check!
Implement search paths: Check!
Consider ndots option in resolv.conf: Check!

query name <= ndots: search first
query name > ndots : never search

LGTM!

Jan

[-- Attachment #2: Type: text/html, Size: 2621 bytes --]

Re: Re: Re: Would love to see reconsideration for domain and search

[Tim Hockin]

On Fri, Oct 23, 2015 at 8:30 AM, Jan Broer <jasiu.79@gmail.com> wrote:

> Leave nameserver querying logic as it is: Check!
> Implement search paths: Check!
> Consider ndots option in resolv.conf: Check!
>
> query name <= ndots: search first
> query name > ndots : never search

I think that is where we have arrived (except it's < and >= in your
expressions).  Kubernetes will have to change some to satisfy the
assumed fungibility of nameservers, but it's the direction things are
almost certainly moving anyway.

Re: Re: Re: Would love to see reconsideration for domain and search

[Jan Broer]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

>I think that is where we have arrived (except it's < and >= in your
>expressions).  Kubernetes will have to change some to satisfy the
>assumed fungibility of nameservers, but it's the direction things are
>almost certainly moving anyway.

Hi Tim, i guess i skipped these last message - sorry.

If you could clear this up for me:
When there are multiple nameservers, does the musl resolver return the
first response it receives regardless of it's status?
So even when it is something like SERVFAIL or REFUSED it will not wait for
the responses from the other nameservers that might be positive?

Thanks!

[-- Attachment #2: Type: text/html, Size: 763 bytes --]

Re: Re: Re: Would love to see reconsideration for domain and search

[Tim Hockin]

I don't know the answer to that - my knowledge of the details of musl
are pretty limited and mostly stop at "search doesn't work".

On Fri, Oct 23, 2015 at 10:40 AM, Jan Broer <jasiu.79@gmail.com> wrote:
>>I think that is where we have arrived (except it's < and >= in your
>>expressions).  Kubernetes will have to change some to satisfy the
>>assumed fungibility of nameservers, but it's the direction things are
>>almost certainly moving anyway.
>
> Hi Tim, i guess i skipped these last message - sorry.
>
> If you could clear this up for me:
> When there are multiple nameservers, does the musl resolver return the first
> response it receives regardless of it's status?
> So even when it is something like SERVFAIL or REFUSED it will not wait for
> the responses from the other nameservers that might be positive?
>
> Thanks!

Re: Re: Re: Would love to see reconsideration for domain and search

[Jan Broer]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

> On Thu, Oct 22, 2015 at 10:37:53PM -0700, Tim Hockin wrote:
> > I saw from a different thread that musl doesn't or didn't do TCP
> > fallbacks - is that still the case?  I know we need that for things
> > like large multi-SRV sets (which I do not expect libc to support), and
> > we have some people who have large A sets (which I do expect libc to
> > support).

>Indeed. The only way you can overflow the UDP size limit with the
>records the stub resolver uses is with a max-length CNAME pointing to
>a max or near-max length record with little or no overlap to allow for
>compression.

Most DNS servers are actually well able to send records greater than
512 bytes over UDP. This is part of the EDNS0 DNS extension. I think
it's worth discussing to implement EDNS0 in the musl resolver.
Codewise you just have to set the UDP receive buffer to the desired
size and include an OPT RR in every query indicating the supported max
UDP size.

[-- Attachment #2: Type: text/html, Size: 1184 bytes --]

Re: Re: Re: Would love to see reconsideration for domain and search

[Rich Felker]

On Fri, Oct 23, 2015 at 07:40:45PM +0200, Jan Broer wrote:
> >I think that is where we have arrived (except it's < and >= in your
> >expressions).  Kubernetes will have to change some to satisfy the
> >assumed fungibility of nameservers, but it's the direction things are
> >almost certainly moving anyway.
> 
> Hi Tim, i guess i skipped these last message - sorry.
> 
> If you could clear this up for me:
> When there are multiple nameservers, does the musl resolver return the
> first response it receives regardless of it's status?
> So even when it is something like SERVFAIL or REFUSED it will not wait for
> the responses from the other nameservers that might be positive?

No. musl basically ignores and response except success or nxdomain.
Actually servfail is treated specially and results in a limited number
of immediate retries because there are a lot of broken nameservers
that return servfail but immediately succeed on a second try, and
doing the immediate retry drastically speeds up queries in such
environments.

In any case, only success or nxdomain are treated as results
reportable to the caller. Otherwise musl waits for one of these and
returns a transient failure (not does-not-exist) if it times out.

Rich

Re: Re: Re: Would love to see reconsideration for domain and search

[Jan Broer]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

>
> In any case, only success or nxdomain are treated as results
> reportable to the caller. Otherwise musl waits for one of these and
> returns a transient failure (not does-not-exist) if it times out.
>
> Rich
>

Thank you that makes a lot of sense.

[-- Attachment #2: Type: text/html, Size: 548 bytes --]