Bug 1129389
| Summary: | bind returns inconsistent and incorrect results from cache for DS records | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Martin Poole <mpoole> | ||||||
| Component: | bind | Assignee: | Tomáš Hozza <thozza> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-daemons | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6.5 | CC: | mpoole | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-10-27 11:19:14 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1075802 | ||||||||
| Attachments: |
|
||||||||
Created attachment 926156 [details]
variable results capture
Created attachment 926157 [details]
stable results capture
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. Reported upstream [ISC-Bugs #36907]. I'll update the bug when I have some new information - from Upstream or myself. 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.
Thank you for the information! |
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.