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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bind-Users forum mailing list

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.

 

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.

 

-- 

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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Mark Andrews


> On 12 Dec 2020, at 20:36, Prasanna Mathivanan (pmathiva) via bind-users <[hidden email]> 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
> [hidden email]
> 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: [hidden email]

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Bind-Users forum mailing list
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" <[hidden email]> wrote:



    > On 12 Dec 2020, at 20:36, Prasanna Mathivanan (pmathiva) via bind-users <[hidden email]> 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
    > [hidden email]
    > 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: [hidden email]


_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Bind-Users forum mailing list
On Wed, Dec 16, 2020 at 3:48 AM Prasanna Mathivanan (pmathiva) via
bind-users <[hidden email]> wrote:
> 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.

Going back to your original example, a.b.c.example.com, qname
minimisation first identifies that there is a delegation at .com for
example.com, and then asks the example.com namesevers for
_.c.example.com.   Typically this _.c.example.com query would come
back with either an NXDOMAIN answer, which means that the queried
nameserver believes it is authoritative for all names within
c.example.com, or it comes back with a NOERROR answer that lists a
delegation in the authority section.

In the first case (NXDOMAIN), the resolver knows it can ask the same
servers about _.b.c.example.com and the cycle repeats.  In the latter
case, the resolver is able to distinguish between whether there was a
delegation for c.example.com (and ask the new nameservers about
_.b.c.example.com) or a delegation that's actually at _.c.example.com
(highly unusual, in which case, ask the original example.com
nameservers about _.b.c.example.com).

Getting a SERVFAIL throws a wrench in all this.  It's the
authoritative server basically saying, "I'm badly broken and can't
tell you how."  Generally this means the resolver should ask the next
server in the authoritative list.  If they're all giving SERVFAIL then
the resolver can either try to work around the brokenness (for
example, by querying the full name at its closest enclosing
delegation) or just give up on the SERVFAIL.

--
tale

PS: While thinking about this I realized a weird case, which is if
only a subset of the parent nameservers are authoritative for a
subdomain.  That is, imagine example.com is served by the four servers
ns{1,2,34}.example.com, but c.example.com is delegated only to
ns{1,2}.example.com.  If you ask ns1 or ns2 about _.c.example.com,
they'll give an authoritative answer and the fact that a delegation
exists wouldn't be identified (absent DNSSEC), but asking ns3 or ns4
would give the delegation to ns1 and ns2.  I can't think of how this
might be a real problem for future queries though, outside of the
usual type of brokenness that can happen even with full name queries
(eg, a parent has a subdomain configured that it isn't actually
delegated to it).
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Bind-Users forum mailing list
Hi Tale,

Thanks for explaining
We can close this query now.
Thanks team for helping me understand the issue.

--

Thanks
Prasanna

On 17/12/20, 1:13 AM, "tale" <[hidden email]> wrote:

    On Wed, Dec 16, 2020 at 3:48 AM Prasanna Mathivanan (pmathiva) via
    bind-users <[hidden email]> wrote:
    > 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.

    Going back to your original example, a.b.c.example.com, qname
    minimisation first identifies that there is a delegation at .com for
    example.com, and then asks the example.com namesevers for
    _.c.example.com.   Typically this _.c.example.com query would come
    back with either an NXDOMAIN answer, which means that the queried
    nameserver believes it is authoritative for all names within
    c.example.com, or it comes back with a NOERROR answer that lists a
    delegation in the authority section.

    In the first case (NXDOMAIN), the resolver knows it can ask the same
    servers about _.b.c.example.com and the cycle repeats.  In the latter
    case, the resolver is able to distinguish between whether there was a
    delegation for c.example.com (and ask the new nameservers about
    _.b.c.example.com) or a delegation that's actually at _.c.example.com
    (highly unusual, in which case, ask the original example.com
    nameservers about _.b.c.example.com).

    Getting a SERVFAIL throws a wrench in all this.  It's the
    authoritative server basically saying, "I'm badly broken and can't
    tell you how."  Generally this means the resolver should ask the next
    server in the authoritative list.  If they're all giving SERVFAIL then
    the resolver can either try to work around the brokenness (for
    example, by querying the full name at its closest enclosing
    delegation) or just give up on the SERVFAIL.

    --
    tale

    PS: While thinking about this I realized a weird case, which is if
    only a subset of the parent nameservers are authoritative for a
    subdomain.  That is, imagine example.com is served by the four servers
    ns{1,2,34}.example.com, but c.example.com is delegated only to
    ns{1,2}.example.com.  If you ask ns1 or ns2 about _.c.example.com,
    they'll give an authoritative answer and the fact that a delegation
    exists wouldn't be identified (absent DNSSEC), but asking ns3 or ns4
    would give the delegation to ns1 and ns2.  I can't think of how this
    might be a real problem for future queries though, outside of the
    usual type of brokenness that can happen even with full name queries
    (eg, a parent has a subdomain configured that it isn't actually
    delegated to it).

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users