Weird DNS behaviour resolution issues when more labels are present in a zone

[Prasanna Mathivanan (pmathiva)]

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" <marka at isc.org> wrote:



    > On 12 Dec 2020, at 20:36, Prasanna Mathivanan (pmathiva) via bind-users <bind-users at 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 at 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: marka at isc.org