Bug 390

Summary: NSD does not return closest provable encloser NSEC3 on wildcard queries
Product: NSD Reporter: John Barnitz <john_barnitz>
Component: NSD CodeAssignee: 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

Description John Barnitz 2011-05-26 17:24:41 CEST
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.
Comment 1 Matthijs Mekking 2011-05-27 09:49:20 CEST
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.*
Comment 2 Matthijs Mekking 2011-10-26 10:44:12 CEST
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.
Comment 3 Matthijs Mekking 2011-10-26 10:46:07 CEST
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.
Comment 4 Matthijs Mekking 2011-10-26 10:46:38 CEST
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).
Comment 5 Peter van Dijk 2013-05-16 12:34:10 CEST
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]