Bug 1129389 - bind returns inconsistent and incorrect results from cache for DS records
Summary: bind returns inconsistent and incorrect results from cache for DS records
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bind
Version: 6.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Tomáš Hozza 🤓
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1075802
TreeView+ depends on / blocked
 
Reported: 2014-08-12 15:55 UTC by Martin Poole
Modified: 2018-12-09 18:20 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-27 11:19:14 UTC


Attachments (Terms of Use)
variable results capture (10.36 KB, application/octet-stream)
2014-08-12 16:00 UTC, Martin Poole
no flags Details
stable results capture (10.30 KB, application/octet-stream)
2014-08-12 16:01 UTC, Martin Poole
no flags Details

Description Martin Poole 2014-08-12 15:55:55 UTC
Description of problem:

bind operating as a caching server returns the wrong values for DS records when operating with "dnssec-validation auto" and it caches a CD lookup for an A which returns CNAMEs.

Background:

Customer has a pair of bind name servers, one with world access, one acting in forwarding mode for a particular network.  The aim is to be able to use the forwarding server in validating mode.


Version-Release number of selected component (if applicable):

    bind-9.8.2-0.23.rc1.el6_5.1.x86_64

How reproducible:

    Always.

Steps to Reproduce:

The problem can be illustrated with single server with world access.

Take standard config bind and set the following

        dnssec-enable yes;
        dnssec-validation auto;
        dnssec-lookaside no;      // disable for traffic clarity

then run

    rndc flush
    dig jsonformat.com @127.0.0.1 +dnssec -t A +cdflag
    dig jsonformat.com @127.0.0.1 +dnssec -t DS +cdflag
    dig jsonformat.com @127.0.0.1 +dnssec -t DS +nocdflag


Actual results:

    $ rndc flush
    $ dig jsonformat.com @127.0.0.1 +dnssec -t A +cdflag

    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> jsonformat.com @127.0.0.1 +dnssec -t A +cdflag
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64475
    ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 5

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;jsonformat.com.                    IN      A

    ;; ANSWER SECTION:
    jsonformat.com.             1800    IN      CNAME   ghs.google.com.
    ghs.google.com.             604800  IN      CNAME   ghs.l.google.com.
    ghs.l.google.com.   300     IN      A       64.233.166.121

    ;; AUTHORITY SECTION:
    google.com.         172800  IN      NS      ns3.google.com.
    google.com.         172800  IN      NS      ns2.google.com.
    google.com.         172800  IN      NS      ns1.google.com.
    google.com.         172800  IN      NS      ns4.google.com.

    ;; ADDITIONAL SECTION:
    ns2.google.com.             172800  IN      A       216.239.34.10
    ns1.google.com.             172800  IN      A       216.239.32.10
    ns3.google.com.             172800  IN      A       216.239.36.10
    ns4.google.com.             172800  IN      A       216.239.38.10

    ;; Query time: 468 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Tue Aug 12 16:26:22 2014
    ;; MSG SIZE  rcvd: 240

    $ dig jsonformat.com @127.0.0.1 +dnssec -t DS +cdflag

    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> jsonformat.com @127.0.0.1 +dnssec -t DS +cdflag
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33918
    ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;jsonformat.com.                    IN      DS

    ;; ANSWER SECTION:
    jsonformat.com.             1799    IN      CNAME   ghs.google.com.
    ghs.google.com.             604800  IN      CNAME   ghs.l.google.com.

    ;; AUTHORITY SECTION:
    l.google.com.               60      IN      SOA     ns4.google.com. dns-admin.google.com. 1564285 900 900 1800 60

    ;; Query time: 24 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Tue Aug 12 16:26:22 2014
    ;; MSG SIZE  rcvd: 138

    $ dig jsonformat.com @127.0.0.1 +dnssec -t DS +nocdflag

    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> jsonformat.com @127.0.0.1 +dnssec -t DS +nocdflag
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19057
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;jsonformat.com.                    IN      DS

    ;; AUTHORITY SECTION:
    com.                        900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1407857184 1800 900 604800 86400
    com.                        900     IN      RRSIG   SOA 8 1 900 20140819152624 20140812141624 6122 com. Xcd5tqDhzba9+rF4vpPYRkVDgSLXrDy5dHaGRmZHvxCurWpkXO2edkkA cQTG58bIa+yH/iMZFL0kTfFqwTF487snCs7OYFBFrA6Em8gtj+3Xoi2r OxLmd4HDvgZKFSJFhSdS7sPV839aXZCNwA5neLsRUnWAQ0O9EIdR2PBF gI8=
    CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 8 2 86400 20140817044928 20140810033928 6122 com. nRRWRcvwjfwkMy8xdRNws3/BABNDYI+9DrZzXY7DCuWM7oMXbHwHUftW dpg04hJ8X1VvABkWw+KY0sUzIRcoj4jnFad+vHzvOQWLlC5AeLkU9OxW Ma5i1ZKBdihSrJnQ3pGCj2TjIrAG/ydJp4PokVDeY8uG0X94yfb1DnwO BXM=
    CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
    I201QNKKJ39KAF1JFRN4IN04018EI32I.com. 900 IN RRSIG NSEC3 8 2 86400 20140819043509 20140812032509 6122 com. oXZYhawmSlKMtVLJaH+vBea8n5zXs185bzaWytcDoJSKPI/vrNbN4wJt Ir3DmWyHTPBc1y1L8EJurJvLbAuTgXVhWKsQqbqNxcw4EFnu/4SNNvC4 InhVCpKKhv7ojaWV5k4LRfCzYN7dKsyABI0AhywSKcj6/7vZvvhIKJDB OGY=
    I201QNKKJ39KAF1JFRN4IN04018EI32I.com. 900 IN NSEC3 1 1 0 - I209KAN5BQAMVEQ1PHAUP8CTGFP16FA2 NS DS RRSIG

    ;; Query time: 500 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Tue Aug 12 16:26:22 2014
    ;; MSG SIZE  rcvd: 764




Expected results:

The results from

    dig jsonformat.com @127.0.0.1 +dnssec -t DS +cdflag

should match those of

    dig jsonformat.com @127.0.0.1 +dnssec -t DS +nocdflag


Additional info:

The reason it needs to match is due to the way the server performs lookups against the outside world.

If the server is originally queried for a checked address

    rndc flush
    dig jsonformat.com @127.0.0.1 +dnssec -t A +nocdflag

then it resolves this as a set of lookups with +cdflag and then validates the results and caches those.  At this point the DS lookups return the same, correct data.

But if the server is queried for the A with +cdflag then the subsequent DS lookups appear to come from 2 distinct cache entries.

Comment 2 Martin Poole 2014-08-12 16:00:49 UTC
Created attachment 926156 [details]
variable results capture

Comment 3 Martin Poole 2014-08-12 16:01:29 UTC
Created attachment 926157 [details]
stable results capture

Comment 5 Tomáš Hozza 🤓 2014-08-18 14:16:38 UTC
Hello. It seems that also newer version in Fedora (9.9.4) has the same issue. I'm going to investigate the cause of this behavior and discuss it with upstream.

Comment 6 Tomáš Hozza 🤓 2014-08-19 11:08:21 UTC
Reported upstream [ISC-Bugs #36907].

I'll update the bug when I have some new information - from Upstream or myself.

Comment 7 Tomáš Hozza 🤓 2014-08-20 08:27:14 UTC
I got a response from upstream. The bottom line is that BIND behavior is correct and jsonformat.com is misconfigured.

The problem is that NS or SOA queries for jsonformat.com always returns NS or SOA records. However any other queries (A, DS, ...) returns CNAME.

This is a violation of a protocol.

Specifically

RFC1034 (section 3.6.2):
"If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different."

RFC1912 (section 2.4):
"A CNAME record is not allowed to coexist with any other data.  In
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
can't also have an MX record for suzy.podunk.edu, or an A record, or
even a TXT record.  Especially do not try to combine CNAMEs and NS
records like this!:


        podunk.xx.      IN      NS      ns1
                        IN      NS      ns2
                        IN      CNAME   mary
        mary            IN      A       1.2.3.4
"

BIND behavior explanation from upstream:
"The nonvalidating query for A put the CNAME record into the
cache, and the nonvalidating query for DS found it -- the cache doesn't
know there's a zone cut there, so it doesn't know the CNAME shouldn't be
used to answer the DS query."


I'm afraid there is nothing that can be fixed in BIND.

Comment 9 Tomáš Hozza 🤓 2014-10-29 07:55:47 UTC
Thank you for the information!


Note You need to log in before you can comment on or make changes to this bug.