Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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.
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.
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.