|
Bugzilla – Full Text Bug Listing |
| Summary: | NSD does not return closest provable encloser NSEC3 on wildcard queries | ||
|---|---|---|---|
| Product: | NSD | Reporter: | John Barnitz <john_barnitz> |
| Component: | NSD Code | Assignee: | NSD team <nsd-team> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | matthijs, peter.van.dijk |
| Priority: | P5 | ||
| Version: | other | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Attachments: |
Zone files used to test.
Patch that returns a superfluous NSEC3 RR on wildcard queries Patch that returns a superfluous NSEC3 RR on wildcard queries |
||
Hi, I might be misunderstanding the bugreport, but I think NSD gives the correct response. According to RFC 5155, wildcard answer responses only need a NSEC3 RR covering the next closer name. The existence of the closest encloser is proven by the presence of the expanded wildcard in the response. See section 7.2.6, : If there is a wildcard match for QNAME and QTYPE, then, in addition to the expanded wildcard RRSet returned in the answer section of the response, proof that the wildcard match was valid must be returned. This proof is accomplished by proving that both QNAME does not exist and that the closest encloser of the QNAME and the immediate ancestor of the wildcard are the same (i.e., the correct wildcard matched). To this end, *the NSEC3 RR that covers the "next closer" name of the immediate ancestor of the wildcard MUST be returned*. *It is not necessary to return an NSEC3 RR that matches the closest encloser, as the existence of this closest encloser is proven by the presence of the expanded wildcard in the response.* Created attachment 189 [details]
Patch that returns a superfluous NSEC3 RR on wildcard queries
This patch exists because there is a bug in the Bind9 resolver. Bind9 cannot validate NSEC3 wildcard answer responses, it needs a superfluous NSEC3 RR. This patch will make NSD provide that NSEC3 RR.
Created attachment 190 [details]
Patch that returns a superfluous NSEC3 RR on wildcard queries
This patch exists because there is a bug in the Bind9 resolver. Bind9 cannot
validate NSEC3 wildcard answer responses, it needs a superfluous NSEC3 RR. This
patch will make NSD provide that NSEC3 RR.
As said earlier, this is a bug in Bind9. As we have been told, a fix is on the way. For those who want to provide the superfluous NSEC3 RR in wildcard answer responses, we provide a custom patch (attached). From the BIND 9.9.0 release notes (https://kb.isc.org/article/AA-00631/0/BIND-9.9.0-Release-Notes.html): named now correctly validates DNSSEC positive wildcard responses from NSEC3 signed zones. [RT #26200] |
Created attachment 169 [details] Zone files used to test. Successfull wildcard queries should return the closest provable encloser NSEC3 and the next closer NSEC3. NSD only returns the next closer NSEC3, which causes BIND to fail to validate the record. Here is an example response from NSD $ dig +dnssec synthesizedname.lab.example.com @10.253.173.108 ; <<>> DiG 9.7.2-P3 <<>> +dnssec synthesizedname.lab.example.com @10.253.173.108 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18192 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;synthesizedname.lab.example.com. IN A ;; ANSWER SECTION: synthesizedname.lab.example.com. 600 IN A 10.11.11.11 synthesizedname.lab.example.com. 600 IN RRSIG A 7 3 600 20110619183704 20110520183704 26075 lab.example.com. EjdOQ0MBAG0HjyXv30Hz7+VEbzUY7J/TeDRaA4ovVO6aqZ/eBA2sdCpR 9/n0QxHBLzfw5PMVbZWrDB0/82zzcSwHEHM3f0PT3qqQqgf3DP7C4ZTe n6PYmLk5qISxZnBTshyITf0h9QTzR9H6//rTjkZK1VRoAsyGGfw3Tnrn VuE= ;; AUTHORITY SECTION: c4bcdbnc8koun4vnnhudd704kh17lpgj.lab.example.com. 600 IN NSEC3 1 0 10 BBBB IS9AQMPEC2O0RKITJVUL6RAL45SLC5RJ A RRSIG c4bcdbnc8koun4vnnhudd704kh17lpgj.lab.example.com. 600 IN RRSIG NSEC3 7 4 600 20110619183704 20110520183704 26075 lab.example.com. jd/mzEZo99M74UJ8qFQbaQouMTPg3FR7Cg53MLYugjnX4hK9LDm54kT4 bMmeAJhH/AAeu4d41uY2mhVztsbsAueDxWzBHekK0HshXXbsGoaBP5pl FpDwVeRxO1x3OiiaFwXaPSNU+l+bMpx0GHW6IL4H1QqL47kywMUvrlHU yfM= lab.example.com. 600 IN NS dns1.lab.example.com. lab.example.com. 600 IN RRSIG NS 7 3 600 20110619183704 20110520183704 26075 lab.example.com. NxAEXkc3QSpAujR57a1BWHu3Ng/XJn79vZI6qflDiAxz99QxujnYuvT6 50iICElw63jSzgr37Vs9unwJKCi6KTYRTfNsvtXawBy5Rzvrv0f/bzCO EbNfxQU7fdmMtWptTSES8WH8ue6ECJ4+xTdDAmdVclFbLY6is0nxPPVR O0s= ;; ADDITIONAL SECTION: dns1.lab.example.com. 600 IN A 10.253.173.108 dns1.lab.example.com. 600 IN RRSIG A 7 4 600 20110619183704 20110520183704 26075 lab.example.com. aaStbY9xeGVtmlhsScIy3soGi9Qn0Dqf2ARKDpq83kL8djImNCky3mFu IyHw7TVFxPvstFmOBjiO89dH1l0WQ25Z9g+3nFDfoyiZtaFHkqOvb29A AjedJJPAdWl/Dn3Mt3W7a94kRYqjjGno4mtnBJyaoQTrUTmye6sLe+X/ Nmc= ;; Query time: 12 msec ;; SERVER: 10.253.173.108#53(10.253.173.108) ;; WHEN: Thu May 26 10:54:31 2011 ;; MSG SIZE rcvd: 892 Here is an example response from BIND using the same zone data. $ dig +dnssec synthesizedname.lab.example.com @10.253.173.108 ; <<>> DiG 9.7.2-P3 <<>> +dnssec synthesizedname.lab.example.com @10.253.173.108 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54018 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;synthesizedname.lab.example.com. IN A ;; ANSWER SECTION: synthesizedname.lab.example.com. 600 IN A 10.11.11.11 synthesizedname.lab.example.com. 600 IN RRSIG A 7 3 600 20110619183704 20110520183704 26075 lab.example.com. EjdOQ0MBAG0HjyXv30Hz7+VEbzUY7J/TeDRaA4ovVO6aqZ/eBA2sdCpR 9/n0QxHBLzfw5PMVbZWrDB0/82zzcSwHEHM3f0PT3qqQqgf3DP7C4ZTe n6PYmLk5qISxZnBTshyITf0h9QTzR9H6//rTjkZK1VRoAsyGGfw3Tnrn VuE= ;; AUTHORITY SECTION: lab.example.com. 600 IN NS dns1.lab.example.com. lab.example.com. 600 IN RRSIG NS 7 3 600 20110619183704 20110520183704 26075 lab.example.com. NxAEXkc3QSpAujR57a1BWHu3Ng/XJn79vZI6qflDiAxz99QxujnYuvT6 50iICElw63jSzgr37Vs9unwJKCi6KTYRTfNsvtXawBy5Rzvrv0f/bzCO EbNfxQU7fdmMtWptTSES8WH8ue6ECJ4+xTdDAmdVclFbLY6is0nxPPVR O0s= SF0LEIPFDOA42U4LAR87T7O2VU6MQK6F.lab.example.com. 600 IN NSEC3 1 0 10 BBBB VAT6G0LCDJ6EIVUNH3HFTC1MKN5E0LAL NS SOA RRSIG DNSKEY NSEC3PARAM SF0LEIPFDOA42U4LAR87T7O2VU6MQK6F.lab.example.com. 600 IN RRSIG NSEC3 7 4 600 20110619183704 20110520183704 26075 lab.example.com. O3A5dKvIrqNWI6VFFh5jFlbZuXMRjuSKT8DkkGJRShUpX+3lP6ieawAI T4qxSASGkdsiijzKCNbD6WjYR1orB2O5Z1RPCw1DGBDYN77ksNd/31mG nCJF7ovoP6Ue7WGx6q8eVw8hVSLHCxUWQb5EWrfu75NiTqfEvYRBF1Bt eWU= C4BCDBNC8KOUN4VNNHUDD704KH17LPGJ.lab.example.com. 600 IN NSEC3 1 0 10 BBBB IS9AQMPEC2O0RKITJVUL6RAL45SLC5RJ A RRSIG C4BCDBNC8KOUN4VNNHUDD704KH17LPGJ.lab.example.com. 600 IN RRSIG NSEC3 7 4 600 20110619183704 20110520183704 26075 lab.example.com. jd/mzEZo99M74UJ8qFQbaQouMTPg3FR7Cg53MLYugjnX4hK9LDm54kT4 bMmeAJhH/AAeu4d41uY2mhVztsbsAueDxWzBHekK0HshXXbsGoaBP5pl FpDwVeRxO1x3OiiaFwXaPSNU+l+bMpx0GHW6IL4H1QqL47kywMUvrlHU yfM= ;; ADDITIONAL SECTION: dns1.lab.example.com. 600 IN A 10.253.173.108 dns1.lab.example.com. 600 IN RRSIG A 7 4 600 20110619183704 20110520183704 26075 lab.example.com. aaStbY9xeGVtmlhsScIy3soGi9Qn0Dqf2ARKDpq83kL8djImNCky3mFu IyHw7TVFxPvstFmOBjiO89dH1l0WQ25Z9g+3nFDfoyiZtaFHkqOvb29A AjedJJPAdWl/Dn3Mt3W7a94kRYqjjGno4mtnBJyaoQTrUTmye6sLe+X/ Nmc= ;; Query time: 12 msec ;; SERVER: 10.253.173.108#53(10.253.173.108) ;; WHEN: Thu May 26 11:10:34 2011 ;; MSG SIZE rcvd: 1149 Notice that BIND includes the SF0LEIPFDOA42U4LAR87T7O2VU6MQK6F NSEC3 record which matches the zone. I have attached the zone files I used to test.