Thanks Mark for responding.
Whenever we have broken delegation as domain owners didn't follow proper RFC,
the default behaviour of the query hits " _.<label-sequence>" which doesn’t
exist.? And we get NXDOMAIN or SERVFAIL response.
Is my understanding correct ?
--
Thanks
Prasanna
On 14/12/20, 6:51 AM, "Mark Andrews" <ma...@isc.org> wrote:
> On 12 Dec 2020, at 20:36, Prasanna Mathivanan (pmathiva) via bind-users
<bind-users@lists.isc.org> wrote:
>
> Hi everyone,
>
> I have an issue in resolving a domain, from logs I see its timing out.
> And from dig output we are getting SERV fail response.
> The bind version we are using 9.14.10, same domain resolves in bind
version 9.11 and lower.
>
> Example domain:- a.b.c.eample.com
> When we took tcpdump and saw what’s happening when we do a dig, we see
its querying the wrong domain“_.b.c.example.com” , and it’s not able to query
the NS for this domain and we get timeout in logs.
> Adding to that we get SERVFAIL response when doing dig.
If you are getting a timeout then the server for _.b.c.example.com is
broken or it is unreachable.
“_” is a legal label in the DNS. If the server for b.c.example.com
responds to b.c.example.com but
does not respond to _.b.c.example.com then the server is broken or there is
a broken firewall in
front of it.
> We don’t see this behaviour for bind version 9.11 or lower and works with
+trace as well.
>
> If anyone can explain why this behaviour is happening, it will be very
helpful in understanding the issue.
>
> After looking into the problem, it appears that bind 9.14 ships with
Query Name Minimisation feature as defined by RFC 7816 enabled by default.
> few have experienced this behaviour and solution was to disable QNAME
minimization.
>
> How does QNAME Minimisation alter this behaviour? To quote from RFC 7816:
> Instead of sending the full QNAME and the original QTYPE upstream, a
resolver that implements QNAME minimisation and does not already have the
answer in its cache sends a request to the name server authoritative for the
closest known ancestor of the original QNAME. The request is done with:
> • the QTYPE NS
> • the QNAME that is the original QNAME, stripped to just one label more
than the zone for which the server is authoritative
> A resolver using QNAME Minimisation implicitly assumes that each label in
the query name corresponds to a zone cut. The resolver queries a parent zone
server, using an abbreviated query name that is truncated after the name of the
immediate child label and uses a query type of NS.
>
>
> Am adding the following links to justify this behaviour, but just wanted
a suggestion if we are good with doing this.
> https://datatracker.ietf.org/doc/rfc7816/?include_text=1
> https://blog.apnic.net/2019/08/12/dns-query-privacy/
>
https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-with-qname-minimisation
> https://github.com/iagox86/dnscat2/issues/144
>
> Disabling QMIN does fix the issue, but I would like to understand why
delegation breaks if there are more labels.
> And why the query goes to underscore domain even though it doesn’t exist.
Because people deploy non-RFC compliant nameservers. If you find one
complain to the operator of it.
_.<label-sequence> is chosen so that the resulting NXDOMAINs are not being
cached for <label-sequence>.
The initial QMIN implementation used NS queries but that caused problems
when servers returned NXDOMAIN
to NS queries but there were really records there. Querying for A / AAAA
at <label-sequence> also distorts
QTYPE statistics for <label-sequence>. Prepending “_” prevents that by
using a QNAME that almost never
exists.
> --
> Thanks
> Prasanna
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
>
> ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
