DNS resolver patch

DNS resolver patch

[Tarun Johar]

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

Hi Team, 

The VirtualBox --natdnsresolver does not support IPv6 AAAA address queries. It returns "NotImp" (code 4) for such queries. 

The MUSL library (https://www.musl-libc.org/) resolver does not recognize this code and retries the query until the timeout. This causes DNS lookups to take several seconds after which they are eventually successful. 

The GLIBC resolver works properly with the same configuration, suggesting that a fix should be made to MUSL to handle the "NotImp" response code. 

The root cause is this section of code in musl/src/network/res_msend.c:149 
/* Only accept positive or negative responses; 
* retry immediately on server failure, and ignore 
* all other codes such as refusal. */ 
switch (answers[next][3] & 15) { 
case 0: 
case 3: 
break; 
case 2: 
if (servfail_retry && servfail_retry--) 
sendto(fd, queries[i], 
qlens[i], MSG_NOSIGNAL, 
(void *)&ns[j], sl); 
default: 
continue; 
} 

If "case 4" is added after "case 3" and before "break", the NotImp code is treated as a positive or negative response and the name resolution loop completes immediately. 

Can the patch for this be included in MUSL 1.1.21 ? 

Thanks, 
Tarun 

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

Re: DNS resolver patch

[Rich Felker]

On Wed, Dec 05, 2018 at 09:31:55PM -0800, Tarun Johar wrote:
> Hi Team, 
> 
> The VirtualBox --natdnsresolver does not support IPv6 AAAA address
> queries. It returns "NotImp" (code 4) for such queries.
> 
> The MUSL library (https://www.musl-libc.org/) resolver does not
> recognize this code and retries the query until the timeout. This
> causes DNS lookups to take several seconds after which they are
> eventually successful.
> 
> The GLIBC resolver works properly with the same configuration,
> suggesting that a fix should be made to MUSL to handle the "NotImp"
> response code.
> 
> The root cause is this section of code in musl/src/network/res_msend.c:149 
> /* Only accept positive or negative responses; 
> * retry immediately on server failure, and ignore 
> * all other codes such as refusal. */ 
> switch (answers[next][3] & 15) { 
> case 0: 
> case 3: 
> break; 
> case 2: 
> if (servfail_retry && servfail_retry--) 
> sendto(fd, queries[i], 
> qlens[i], MSG_NOSIGNAL, 
> (void *)&ns[j], sl); 
> default: 
> continue; 
> } 
> 
> If "case 4" is added after "case 3" and before "break", the NotImp
> code is treated as a positive or negative response and the name
> resolution loop completes immediately.
> 
> Can the patch for this be included in MUSL 1.1.21 ? 

No, this is specifically wrong. If one buggy nameserver is responding
with "NotImp", the correct behavior is waiting for a response from a
different one that's not broken. It's possible that we could try to
remember such errors for each nameserver, and abort the lookup early
with an error (not a negative result, since this is not a result) if
*all* of them have failed, but it's not clear that that's the right
thing to do if there might be multiple actual servers behind each
logical one (ip address), which is probably the case for things like
8.8.8.8; in that case an error from one should not result in aborting
the query. Note also that treating it as an error would not help with
the practical need, since then the whole query would fail and you
wouldn't get the IPv4 results either.

The real fix here is just making VirtualBox's nameserver do the right
thing, or bypassing it and querying a real nameserver. Apparently
there's some reason it's desirable for use with certain NAT setups,
but I'm not clear on what this is. If it's returning real results, it
should just support AAAA and pass it through. If it's returning faked
results for some reason, and doesn't use IPv6 for them, it should just
return NxDomain for AAAA queries rather than an error. I'm happy to
help in explaining to upstream why the current behavior is problematic
if needed.

Rich

Re: DNS resolver patch

[Natanael Copa]

On Thu, 6 Dec 2018 09:13:01 -0500
Rich Felker <dalias@libc.org> wrote:

> On Wed, Dec 05, 2018 at 09:31:55PM -0800, Tarun Johar wrote:
> > Hi Team, 
> > 
> > The VirtualBox --natdnsresolver does not support IPv6 AAAA address
> > queries. It returns "NotImp" (code 4) for such queries.
> > 
> > The MUSL library (https://www.musl-libc.org/) resolver does not
> > recognize this code and retries the query until the timeout. This
> > causes DNS lookups to take several seconds after which they are
> > eventually successful.
> > 
> > The GLIBC resolver works properly with the same configuration,
> > suggesting that a fix should be made to MUSL to handle the "NotImp"
> > response code.
> > 
> > The root cause is this section of code in musl/src/network/res_msend.c:149 
> > /* Only accept positive or negative responses; 
> > * retry immediately on server failure, and ignore 
> > * all other codes such as refusal. */ 
> > switch (answers[next][3] & 15) { 
> > case 0: 
> > case 3: 
> > break; 
> > case 2: 
> > if (servfail_retry && servfail_retry--) 
> > sendto(fd, queries[i], 
> > qlens[i], MSG_NOSIGNAL, 
> > (void *)&ns[j], sl); 
> > default: 
> > continue; 
> > } 
> > 
> > If "case 4" is added after "case 3" and before "break", the NotImp
> > code is treated as a positive or negative response and the name
> > resolution loop completes immediately.
> > 
> > Can the patch for this be included in MUSL 1.1.21 ?   
> 
> No, this is specifically wrong. If one buggy nameserver is responding
> with "NotImp", the correct behavior is waiting for a response from a
> different one that's not broken. It's possible that we could try to
> remember such errors for each nameserver, and abort the lookup early
> with an error (not a negative result, since this is not a result) if
> *all* of them have failed, but it's not clear that that's the right
> thing to do if there might be multiple actual servers behind each
> logical one (ip address), which is probably the case for things like
> 8.8.8.8; in that case an error from one should not result in aborting
> the query. Note also that treating it as an error would not help with
> the practical need, since then the whole query would fail and you
> wouldn't get the IPv4 results either.
> 
> The real fix here is just making VirtualBox's nameserver do the right
> thing, or bypassing it and querying a real nameserver. Apparently
> there's some reason it's desirable for use with certain NAT setups,
> but I'm not clear on what this is. If it's returning real results, it
> should just support AAAA and pass it through. If it's returning faked
> results for some reason, and doesn't use IPv6 for them, it should just
> return NxDomain for AAAA queries rather than an error. I'm happy to
> help in explaining to upstream why the current behavior is problematic
> if needed.

For the record, here is a good explanation:
https://nlnetlabs.nl/pipermail/unbound-users/2017-August/004866.html

RCODE 4 means "Not Implemented - The name server does not support the
requested kind of query." where "kind of query" is specified in OPCODE[1]
field (eg query or notify) and is not the RR type.

-nc

[1]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-5

Re: DNS resolver patch

[Florian Weimer]

* Tarun Johar:

> The VirtualBox --natdnsresolver does not support IPv6 AAAA address
> queries.  It returns "NotImp" (code 4) for such queries.

I think that's not the only bug, and glibc fails to work around all of
them.  We occasionally get bug reports about DNS resolution issues under
VirtualBox, too.  Oracle really needs to fix this properly.

Thanks,
Florian

Re: DNS resolver patch

[Natanael Copa]

On Thu, 06 Dec 2018 15:53:43 +0100
Florian Weimer <fweimer@redhat.com> wrote:

> * Tarun Johar:
> 
> > The VirtualBox --natdnsresolver does not support IPv6 AAAA address
> > queries.  It returns "NotImp" (code 4) for such queries.  
> 
> I think that's not the only bug, and glibc fails to work around all of
> them.  We occasionally get bug reports about DNS resolution issues under
> VirtualBox, too.  Oracle really needs to fix this properly.
> 
> Thanks,
> Florian

Problem is here:
https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Network/slirp/hostres.c?rev=59202#L408

402	    if (   qtype != Type_A
403	        && qtype != Type_CNAME
404	        && qtype != Type_PTR
405	        && qtype != Type_ANY)
406	    {
407	        LogErr(("NAT: hostres: unsupported qtype %d\n", qtype));
408	        return refuse(pData, m, RCode_NotImp);
409	    }


They should return RCode_NXDomain instead of RCode_NotImp. Seems like
they also have more of those invalid use of NotImp.

-nc

Re: DNS resolver patch

[Florian Weimer]

* Natanael Copa:

> On Thu, 06 Dec 2018 15:53:43 +0100
> Florian Weimer <fweimer@redhat.com> wrote:
>
>> * Tarun Johar:
>> 
>> > The VirtualBox --natdnsresolver does not support IPv6 AAAA address
>> > queries.  It returns "NotImp" (code 4) for such queries.  
>> 
>> I think that's not the only bug, and glibc fails to work around all of
>> them.  We occasionally get bug reports about DNS resolution issues under
>> VirtualBox, too.  Oracle really needs to fix this properly.
>> 
>> Thanks,
>> Florian
>
> Problem is here:
> https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Network/slirp/hostres.c?rev=59202#L408
>
> 402	    if (   qtype != Type_A
> 403	        && qtype != Type_CNAME
> 404	        && qtype != Type_PTR
> 405	        && qtype != Type_ANY)
> 406	    {
> 407	        LogErr(("NAT: hostres: unsupported qtype %d\n", qtype));
> 408	        return refuse(pData, m, RCode_NotImp);
> 409	    }
>
>
> They should return RCode_NXDomain instead of RCode_NotImp. Seems like
> they also have more of those invalid use of NotImp.

I think that's probably worse because NXDOMAIN says that there is no
data at that name, so there's no A record either.  It will confuse some
DNS resolvers.

The alternative, using a NOERROR/NODATA response, confuses musl search
processing.  In order to fix this properly, you need to pass through the
AAAA records (even if there's no actual IPv6 networking support in the
code; I haven't checked this and it does not matter for name
resolution).

Thanks,
Florian

Re: DNS resolver patch

[A. Wilcox]

[-- Attachment #1.1: Type: text/plain, Size: 623 bytes --]

On 12/06/18 12:18, Florian Weimer wrote:
> The alternative, using a NOERROR/NODATA response, confuses musl search
> processing.

???

The musl resolver should be able to handle a resolver returning NODATA.
That is popular for having a separate extranet infrastructure - your
extranet DNS only contains records for your local domain and returns
NODATA for requests outside that domain.

If you are correct that such a response "confuses musl search
processing", that's a bug in musl that needs to be fixed.

Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: DNS resolver patch

[Laurent Bercot]

>The musl resolver should be able to handle a resolver returning NODATA.
>That is popular for having a separate extranet infrastructure - your
>extranet DNS only contains records for your local domain and returns
>NODATA for requests outside that domain.

No, you are talking about servers containing data. The musl client
(which is not a resolver, because it only performs recursive queries)
should not contact those directly. It should contact a real resolver,
a.k.a. cache, and the cache will contact the servers containing data.
If the domain has been configured properly, the servers are never asked
for data that are outside that domain.

It is the single most annoying, most bug-prone, and most confusing
flaw of DNS to have "communication between the DNS client and the DNS
cache" (recursive queries) and "communication between the DNS cache
and the DNS server" (non-recursive queries) happen on the same port.
I'd even take a different _protocol_ if it could stop people from
misconfiguring DNS.

The default usage of BIND, which was "one single daemon is both a
cache and a server and we entertain the confusion", did a lot of harm
to the Internet. As your post illustrates, this harm pertains to this
day.

--
Laurent

Re: DNS resolver patch

[Rich Felker]

On Thu, Dec 06, 2018 at 07:46:02PM +0000, Laurent Bercot wrote:
> >The musl resolver should be able to handle a resolver returning NODATA.
> >That is popular for having a separate extranet infrastructure - your
> >extranet DNS only contains records for your local domain and returns
> >NODATA for requests outside that domain.
> 
> No, you are talking about servers containing data. The musl client
> (which is not a resolver, because it only performs recursive queries)
> should not contact those directly. It should contact a real resolver,
> a.k.a. cache, and the cache will contact the servers containing data.
> If the domain has been configured properly, the servers are never asked
> for data that are outside that domain.
> 
> It is the single most annoying, most bug-prone, and most confusing
> flaw of DNS to have "communication between the DNS client and the DNS
> cache" (recursive queries) and "communication between the DNS cache
> and the DNS server" (non-recursive queries) happen on the same port.
> I'd even take a different _protocol_ if it could stop people from
> misconfiguring DNS.
> 
> The default usage of BIND, which was "one single daemon is both a
> cache and a server and we entertain the confusion", did a lot of harm
> to the Internet. As your post illustrates, this harm pertains to this
> day.

I'm not sure what the relation to the confusion between querying an
authoritative server and a recursive server is here, but the quoted
interpretation of NODATA above is wrong independent of any such
confusion. NODATA does not indicate that the server you asked doesn't
know about the queried name. It indicates that that queried name
exists but has no records of the requested type.

Rich

Re: DNS resolver patch

[Florian Weimer]

* Rich Felker:

> On Thu, Dec 06, 2018 at 07:46:02PM +0000, Laurent Bercot wrote:
>> >The musl resolver should be able to handle a resolver returning NODATA.
>> >That is popular for having a separate extranet infrastructure - your
>> >extranet DNS only contains records for your local domain and returns
>> >NODATA for requests outside that domain.
>> 
>> No, you are talking about servers containing data. The musl client
>> (which is not a resolver, because it only performs recursive queries)
>> should not contact those directly. It should contact a real resolver,
>> a.k.a. cache, and the cache will contact the servers containing data.
>> If the domain has been configured properly, the servers are never asked
>> for data that are outside that domain.
>> 
>> It is the single most annoying, most bug-prone, and most confusing
>> flaw of DNS to have "communication between the DNS client and the DNS
>> cache" (recursive queries) and "communication between the DNS cache
>> and the DNS server" (non-recursive queries) happen on the same port.
>> I'd even take a different _protocol_ if it could stop people from
>> misconfiguring DNS.
>> 
>> The default usage of BIND, which was "one single daemon is both a
>> cache and a server and we entertain the confusion", did a lot of harm
>> to the Internet. As your post illustrates, this harm pertains to this
>> day.
>
> I'm not sure what the relation to the confusion between querying an
> authoritative server and a recursive server is here, but the quoted
> interpretation of NODATA above is wrong independent of any such
> confusion. NODATA does not indicate that the server you asked doesn't
> know about the queried name. It indicates that that queried name
> exists but has no records of the requested type.

Maybe a referral looks like a NODATA response upon cursory inspection?

glibc has code which switches to the next configured nameserver upon
encountering what looks like a referral:

		if (anhp->rcode == NOERROR && anhp->ancount == 0
		    && anhp->aa == 0 && anhp->ra == 0 && anhp->arcount == 0) {
			goto next_ns;
		}

(Oops: When EDNS support is enabled, this check is buggy because
anhp->arcount is not necessarily zero due to the OPT record.)

REFUSED is handled the same way, so I think this enables the
misconfiguration A. Wilcox described.  Fortunately, we still only
support three name servers, so there is a limit to what people can do
with this.

Curiously this isn't something that was part of the original BIND stub
resolver code.  It's a fairly recent addition to the glibc stub
resolver, dating back to 2005 only.

Recognizing referrals reliably is quite hard; I wouldn't immediately
know how to implement that in a stub resolver.  (Back in 2005,
referrals with a non-empty answer section were still common, I think.)
It's easier in a recursive resolver because you can just follow the
referral (with some safeguards to deal with loops and other
nastiness).  And you can do a lameness check if you know that the
sever should be authoritative.

Re: DNS resolver patch

[Rich Felker]

On Thu, Dec 27, 2018 at 08:18:16PM +0100, Florian Weimer wrote:
> * Rich Felker:
> 
> > On Thu, Dec 06, 2018 at 07:46:02PM +0000, Laurent Bercot wrote:
> >> >The musl resolver should be able to handle a resolver returning NODATA.
> >> >That is popular for having a separate extranet infrastructure - your
> >> >extranet DNS only contains records for your local domain and returns
> >> >NODATA for requests outside that domain.
> >> 
> >> No, you are talking about servers containing data. The musl client
> >> (which is not a resolver, because it only performs recursive queries)
> >> should not contact those directly. It should contact a real resolver,
> >> a.k.a. cache, and the cache will contact the servers containing data.
> >> If the domain has been configured properly, the servers are never asked
> >> for data that are outside that domain.
> >> 
> >> It is the single most annoying, most bug-prone, and most confusing
> >> flaw of DNS to have "communication between the DNS client and the DNS
> >> cache" (recursive queries) and "communication between the DNS cache
> >> and the DNS server" (non-recursive queries) happen on the same port.
> >> I'd even take a different _protocol_ if it could stop people from
> >> misconfiguring DNS.
> >> 
> >> The default usage of BIND, which was "one single daemon is both a
> >> cache and a server and we entertain the confusion", did a lot of harm
> >> to the Internet. As your post illustrates, this harm pertains to this
> >> day.
> >
> > I'm not sure what the relation to the confusion between querying an
> > authoritative server and a recursive server is here, but the quoted
> > interpretation of NODATA above is wrong independent of any such
> > confusion. NODATA does not indicate that the server you asked doesn't
> > know about the queried name. It indicates that that queried name
> > exists but has no records of the requested type.
> 
> Maybe a referral looks like a NODATA response upon cursory inspection?
> 
> glibc has code which switches to the next configured nameserver upon
> encountering what looks like a referral:
> 
> 		if (anhp->rcode == NOERROR && anhp->ancount == 0
> 		    && anhp->aa == 0 && anhp->ra == 0 && anhp->arcount == 0) {
> 			goto next_ns;
> 		}

Can you elaborate or provide a citation on how this "looks like a
referral"? I don't see any obvious difference between this and a
nodata response except possibly RA==0, which would only happen when
you have an auth-only nameserver listed in your resolv.conf. This
would not be useful for unioning in musl because it depends on an
ordering between the nameservers rather than providing a true union;
at least one of the servers is going to be recursive and return an
nxdomain or nodata which could be seen before the auth-only local
server responds.

> (Oops: When EDNS support is enabled, this check is buggy because
> anhp->arcount is not necessarily zero due to the OPT record.)

FTR, also not an issue for musl since we intentionally don't do EDNS.

> REFUSED is handled the same way, so I think this enables the
> misconfiguration A. Wilcox described.  Fortunately, we still only
> support three name servers, so there is a limit to what people can do
> with this.

Refused and other errors are pretty much ignored in musl; they're at
least not conclusive unless all nameservers have responded with an
error, since another one could still succeed.

Rich

Re: DNS resolver patch

[Florian Weimer]

* Rich Felker:

> On Thu, Dec 27, 2018 at 08:18:16PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>> 
>> > On Thu, Dec 06, 2018 at 07:46:02PM +0000, Laurent Bercot wrote:
>> >> >The musl resolver should be able to handle a resolver returning NODATA.
>> >> >That is popular for having a separate extranet infrastructure - your
>> >> >extranet DNS only contains records for your local domain and returns
>> >> >NODATA for requests outside that domain.
>> >> 
>> >> No, you are talking about servers containing data. The musl client
>> >> (which is not a resolver, because it only performs recursive queries)
>> >> should not contact those directly. It should contact a real resolver,
>> >> a.k.a. cache, and the cache will contact the servers containing data.
>> >> If the domain has been configured properly, the servers are never asked
>> >> for data that are outside that domain.
>> >> 
>> >> It is the single most annoying, most bug-prone, and most confusing
>> >> flaw of DNS to have "communication between the DNS client and the DNS
>> >> cache" (recursive queries) and "communication between the DNS cache
>> >> and the DNS server" (non-recursive queries) happen on the same port.
>> >> I'd even take a different _protocol_ if it could stop people from
>> >> misconfiguring DNS.
>> >> 
>> >> The default usage of BIND, which was "one single daemon is both a
>> >> cache and a server and we entertain the confusion", did a lot of harm
>> >> to the Internet. As your post illustrates, this harm pertains to this
>> >> day.
>> >
>> > I'm not sure what the relation to the confusion between querying an
>> > authoritative server and a recursive server is here, but the quoted
>> > interpretation of NODATA above is wrong independent of any such
>> > confusion. NODATA does not indicate that the server you asked doesn't
>> > know about the queried name. It indicates that that queried name
>> > exists but has no records of the requested type.
>> 
>> Maybe a referral looks like a NODATA response upon cursory inspection?
>> 
>> glibc has code which switches to the next configured nameserver upon
>> encountering what looks like a referral:
>> 
>> 		if (anhp->rcode == NOERROR && anhp->ancount == 0
>> 		    && anhp->aa == 0 && anhp->ra == 0 && anhp->arcount == 0) {
>> 			goto next_ns;
>> 		}
>
> Can you elaborate or provide a citation on how this "looks like a
> referral"? I don't see any obvious difference between this and a
> nodata response except possibly RA==0, which would only happen when
> you have an auth-only nameserver listed in your resolv.conf.

But that's exactly the scenario when people want to ignore referrals.
A name server which provides recursive service will never send a
referral, after all.  If it cannot complete the recursion, it will
respond with SERVFAIL instead.

> This would not be useful for unioning in musl because it depends on
> an ordering between the nameservers rather than providing a true
> union; at least one of the servers is going to be recursive and
> return an nxdomain or nodata which could be seen before the
> auth-only local server responds.

I expect that the authoritative-only server is put first in this case.

My position is that this is not really worth supporting, though.  It's
easy enough to run a local caching resolver which can implement such
policies, including forwarding queries for certain zones to certain
authoritative servers.  Then there's no need to resort to search path
hacks and listing non-recursive name servers in etc/resolv.conf.

Re: DNS resolver patch

[Rich Felker]

On Thu, May 30, 2019 at 10:50:22AM +0200, Florian Weimer wrote:
> * Rich Felker:
> > On Thu, Dec 27, 2018 at 08:18:16PM +0100, Florian Weimer wrote:
> >> glibc has code which switches to the next configured nameserver upon
> >> encountering what looks like a referral:
> >> 
> >> 		if (anhp->rcode == NOERROR && anhp->ancount == 0
> >> 		    && anhp->aa == 0 && anhp->ra == 0 && anhp->arcount == 0) {
> >> 			goto next_ns;
> >> 		}
> >
> > Can you elaborate or provide a citation on how this "looks like a
> > referral"? I don't see any obvious difference between this and a
> > nodata response except possibly RA==0, which would only happen when
> > you have an auth-only nameserver listed in your resolv.conf.
> 
> But that's exactly the scenario when people want to ignore referrals.
> A name server which provides recursive service will never send a
> referral, after all.  If it cannot complete the recursion, it will
> respond with SERVFAIL instead.

Yes, I just wasn't clear how to interpret that combination of bits. I
should re-read the spec I guess.

> > This would not be useful for unioning in musl because it depends on
> > an ordering between the nameservers rather than providing a true
> > union; at least one of the servers is going to be recursive and
> > return an nxdomain or nodata which could be seen before the
> > auth-only local server responds.
> 
> I expect that the authoritative-only server is put first in this case.

Note that musl does not have a concept of an order between the
nameservers; they're just treated as alternative sources for the same
data.

> My position is that this is not really worth supporting, though.  It's
> easy enough to run a local caching resolver which can implement such
> policies, including forwarding queries for certain zones to certain
> authoritative servers.  Then there's no need to resort to search path
> hacks and listing non-recursive name servers in etc/resolv.conf.

I agree completely. Fancy policy things like unioning and remapping
are best done in an external process. Moreover, with DNS privacy and
integrity becoming such a critical issue in the future (or perhaps the
present), it's going to be mandatory to run a (proxy, at least)
nameserver on localhost anyway to perform DNSSEC validation and/or
DNS-over-HTTPS.

Rich

Re: DNS resolver patch

[Florian Weimer]

* A. Wilcox:

> On 12/06/18 12:18, Florian Weimer wrote:
>> The alternative, using a NOERROR/NODATA response, confuses musl search
>> processing.
>
> ???
>
> The musl resolver should be able to handle a resolver returning NODATA.
> That is popular for having a separate extranet infrastructure - your
> extranet DNS only contains records for your local domain and returns
> NODATA for requests outside that domain.
>
> If you are correct that such a response "confuses musl search
> processing", that's a bug in musl that needs to be fixed.

<https://www.openwall.com/lists/musl/2018/03/31/2>

I don't know if it was merged.

Florian

Re: DNS resolver patch

[Rich Felker]

On Thu, Dec 06, 2018 at 09:36:01PM +0100, Florian Weimer wrote:
> * A. Wilcox:
> 
> > On 12/06/18 12:18, Florian Weimer wrote:
> >> The alternative, using a NOERROR/NODATA response, confuses musl search
> >> processing.
> >
> > ???
> >
> > The musl resolver should be able to handle a resolver returning NODATA.
> > That is popular for having a separate extranet infrastructure - your
> > extranet DNS only contains records for your local domain and returns
> > NODATA for requests outside that domain.
> >
> > If you are correct that such a response "confuses musl search
> > processing", that's a bug in musl that needs to be fixed.
> 
> <https://www.openwall.com/lists/musl/2018/03/31/2>
> 
> I don't know if it was merged.

That patch didn't (and fundamentally can't) produce fully-consistent
results (consistent with non-A/AAAA queries). Something similar (with
configurable opt-in) might be sufficient if there were a need, but
supposedly the underlying issue with Cloudflare was fixed. So in
summary, it hasn't been merged.

Rich

Re: DNS resolver patch

[Tarun Johar]

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

Hi Natanael/Florian, 

A couple of solutions for this are stated below. 

The code is in src/VBox/Devices/Network/slirp/hostres.c :517 

if ( qtype != Type_A 
&& qtype != Type_CNAME 
&& qtype != Type_PTR 
&& qtype != Type_ANY) 
{ 
LogErr(("NAT: hostres: unsupported qtype %d\n", qtype)); 
return refuse(res, RCode_NotImp); 
} 

There are two possible fixes: 

- Add a conditional above this code for Type_AAAA where the resolver returns RCode_NXDomain instead of RCode_NotImp: 

if (qtype == Type_AAAA) { 
LogErr(("NAT: hostres: cannot resolve qtype %d\n", qtype)); 
return refuse(res, RCode_NXDomain); 
} 

- Implement IPv6 resolution for AAAA records. The resolve() function at line 574 would need to be updated. 

I just came across ticket filed by Natanael with Virtual box at https://www.virtualbox.org/ticket/18171 . Since one of us is already talking with them, could you propose the above solutions to them (and add me to the loop at well). 

Thanks, 
Tarun 

----- Original Message -----

From: "Natanael Copa" <ncopa@alpinelinux.org> 
To: "Florian Weimer" <fweimer@redhat.com> 
Cc: musl@lists.openwall.com, "Tarun Johar" <tjohar@totalphase.com> 
Sent: Thursday, December 6, 2018 9:18:20 PM 
Subject: Re: [musl] DNS resolver patch 

On Thu, 06 Dec 2018 15:53:43 +0100 
Florian Weimer <fweimer@redhat.com> wrote: 



* Tarun Johar: 

> The VirtualBox --natdnsresolver does not support IPv6 AAAA address 
> queries. It returns "NotImp" (code 4) for such queries. 

I think that's not the only bug, and glibc fails to work around all of 
them. We occasionally get bug reports about DNS resolution issues under 
VirtualBox, too. Oracle really needs to fix this properly. 

Thanks, 
Florian 

Problem is here: 



https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Network/slirp/hostres.c?rev=59202#L408 

402 if ( qtype != Type_A 
403 && qtype != Type_CNAME 
404 && qtype != Type_PTR 
405 && qtype != Type_ANY) 
406 { 
407 LogErr(("NAT: hostres: unsupported qtype %d\n", qtype)); 
408 return refuse(pData, m, RCode_NotImp); 
409 } 


They should return RCode_NXDomain instead of RCode_NotImp. Seems like 
they also have more of those invalid use of NotImp. 

-nc 

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

Re: DNS resolver patch

[Tarun Johar]

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

I managed to add the proposed fixes to https://www.virtualbox.org/ticket/18171 as comment. Hopefully, this helps our cause. 

Thanks, 
Tarun 

----- Original Message -----

From: "Tarun Johar" <tjohar@totalphase.com> 
To: "Natanael Copa" <ncopa@alpinelinux.org>, "Florian Weimer" <fweimer@redhat.com> 
Cc: musl@lists.openwall.com 
Sent: Friday, December 7, 2018 12:20:24 AM 
Subject: Re: [musl] DNS resolver patch 

Hi Natanael/Florian, 

A couple of solutions for this are stated below. 

The code is in src/VBox/Devices/Network/slirp/hostres.c :517 

if ( qtype != Type_A 
&& qtype != Type_CNAME 
&& qtype != Type_PTR 
&& qtype != Type_ANY) 
{ 
LogErr(("NAT: hostres: unsupported qtype %d\n", qtype)); 
return refuse(res, RCode_NotImp); 
} 

There are two possible fixes: 

- Add a conditional above this code for Type_AAAA where the resolver returns RCode_NXDomain instead of RCode_NotImp: 

if (qtype == Type_AAAA) { 
LogErr(("NAT: hostres: cannot resolve qtype %d\n", qtype)); 
return refuse(res, RCode_NXDomain); 
} 

- Implement IPv6 resolution for AAAA records. The resolve() function at line 574 would need to be updated. 

I just came across ticket filed by Natanael with Virtual box at https://www.virtualbox.org/ticket/18171 . Since one of us is already talking with them, could you propose the above solutions to them (and add me to the loop at well). 

Thanks, 
Tarun 

----- Original Message -----

From: "Natanael Copa" <ncopa@alpinelinux.org> 
To: "Florian Weimer" <fweimer@redhat.com> 
Cc: musl@lists.openwall.com, "Tarun Johar" <tjohar@totalphase.com> 
Sent: Thursday, December 6, 2018 9:18:20 PM 
Subject: Re: [musl] DNS resolver patch 

On Thu, 06 Dec 2018 15:53:43 +0100 
Florian Weimer <fweimer@redhat.com> wrote: 



* Tarun Johar: 

> The VirtualBox --natdnsresolver does not support IPv6 AAAA address 
> queries. It returns "NotImp" (code 4) for such queries. 

I think that's not the only bug, and glibc fails to work around all of 
them. We occasionally get bug reports about DNS resolution issues under 
VirtualBox, too. Oracle really needs to fix this properly. 

Thanks, 
Florian 

Problem is here: 



https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Network/slirp/hostres.c?rev=59202#L408 

402 if ( qtype != Type_A 
403 && qtype != Type_CNAME 
404 && qtype != Type_PTR 
405 && qtype != Type_ANY) 
406 { 
407 LogErr(("NAT: hostres: unsupported qtype %d\n", qtype)); 
408 return refuse(pData, m, RCode_NotImp); 
409 } 


They should return RCode_NXDomain instead of RCode_NotImp. Seems like 
they also have more of those invalid use of NotImp. 

-nc 


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