> 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
