DNSSEC not populating parent zone files with DS records

Jeff Reasoner jeff.reasoner at mail.hccanet.org
Sat Oct 1 00:48:56 UTC 2011


Hmm, I see an A record using the same query:

[foo at dns1 ~]$ dig +dnssec extended.nau.edu a

; <<>> DiG 9.8.1 <<>> +dnssec extended.nau.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13732
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;extended.nau.edu. IN A

;; ANSWER SECTION:
extended.nau.edu. 86349 IN A 134.114.104.140
extended.nau.edu. 86349 IN RRSIG A 5 3 86400 20111019233054
20110919230651 36030 extended.nau.edu.
Oa5g4Nla0O4T2yUIwsKU17VacHWDGLg1ElTKxunftZDcXhiRhH4jwoe8
IWcLdKQ/6VRE9JikTo5MOqV/PbXH+6yzBSzfzmJKP0+KAW6KnNRhETmL
B60UHJmqpWZC8VoV1FOZ2Ma54dSXsw0HKaTksJ1ubGILeWMNb5C1TTrK bzc=

;; AUTHORITY SECTION:
extended.nau.edu. 86349 IN NS ns3.nau.edu.
extended.nau.edu. 86349 IN NS ns2.nau.edu.
extended.nau.edu. 86349 IN NS ns1.nau.edu.
extended.nau.edu. 86349 IN RRSIG NS 5 3 86400 20111019233054
20110919230651 36030 extended.nau.edu.
E8Q9Db8ncNOVdw0cdlHT2iY3SYkdBtPsGP2Xmacn95Br8pxe0Y5Hq3fZ
k0b/v6D872DcmELDcVliOGbNPNLxm2rtl3CG3QjcOr4qUZjQDTqnApgZ KfJ
+V2RUEd0LqcF1PAPmHOn8c/TkBq1m9ir29N77k/x5WW8seRwyRvcD iEU=

;; Query time: 1 msec
;; SERVER: 10.241.0.10#53(10.241.0.10)
;; WHEN: Fri Sep 30 20:42:38 2011
;; MSG SIZE  rcvd: 467


On Fri, 2011-09-30 at 19:56 -0400, Bill Owens wrote: 
> On Fri, Sep 30, 2011 at 10:26:34PM +0000, Raymond Drew Walker wrote:
> > In our initial implementation of DNSSEC, we chose to try out the "auto"
> > functionalities in version 9.8.0 P4 ie. using "auto-dnssec maintain" in
> > all master zones.
> > 
> > When going live, we found that though all zones that we are acting as
> > master for would populate their own DS records, but there would be no
> > population of a child zone's DS record in the corresponding parent master
> > zone file. 
> > 
> > This means upon go-live, any DNSSEC validation of our children zones
> > (X.nau.edu, Y.X.nau.edu etc.) would fail, though our root master zone
> > (nau.edu) would validate fine.
> > 
> > We have since backed out DNSSEC until we can get a resolution of the issue.
> > 
> > After much research, I'm not sure why this is happening... Any suggestions
> > or ideas?
> 
> I think there's something else going on here. If you have DNSKEY records in the child but no DS in the parent, everything should still be okay - there's no chain of trust, but there's also no assertion from the parent that there *should be* a chain of trust (that's what the DS record does).
> 
> However, in this case I believe your problem is the lack of NS records in nau.edu for extended.nau.edu. It's difficult to know for sure, but it appears that the only signature for the NS RRSET is using the ZSK for extended.nau.edu, not the ZSK for nau.edu. 
> 
> In the olden days you could get away with that since the same servers are authoritative for both zones, and they'd answer correctly. In the new world of DNSSEC, if you ask for extended.nau.edu, you get this:
> 
> paperboy {owens}% dig +dnssec extended.nau.edu a
> 
> ; <<>> DiG 9.9.0a2 <<>> +dnssec extended.nau.edu a
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60942
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;extended.nau.edu.		IN	A
> 
> ;; AUTHORITY SECTION:
> ewb.nau.edu.		10199	IN	RRSIG	NSEC 5 3 86400 20111019222812 20110919220129 7485 nau.edu. SfCIx42kzjbTV5sDH/OwIKGRRxfJaM8EgaX74/RbD+BJjJhP7o28dR1U VHRuO6arK8FXF0vCIZ5lpqaWFRkaCwEftrjX3ktdWUNfhRlD9qqHF+cV 00icFXkasql9f8Yk9XgTeZ63CkH/8H9acjTuVlunqZDL1CVtaKTJfKKq uMs=
> ewb.nau.edu.		10199	IN	NSEC	facdevnet.nau.edu. CNAME RRSIG NSEC
> nau.edu.		10199	IN	SOA	ns3.nau.edu. DNS-Contact.nau.edu. 4779 1800 900 604800 86400
> nau.edu.		10199	IN	RRSIG	SOA 5 2 86400 20111030191258 20110930181258 7485 nau.edu. xoY5c8d+UnJfXA0ZZDv2Zz5tht4ZspTOeGvEGcQr+XIOMH39krpWR6T9 fUy5O/XnURz5nDGWR4QIKQMgAu+qfyGzA9Yzb5S5CkAWd4IDjKmznrXI G3beth9Dcr/fJxusMxGuhZWZftQBrHBn14Wqx8YKOOIwQZx/PSm8XONA tHc=
> nau.edu.		10199	IN	RRSIG	NSEC 5 2 86400 20111020001752 20110919233312 7485 nau.edu. GizWBgmH1B7n0TuBjRgUEiu0XOCvrncyKR1iSSWJIrWKn4aZ9djBazdP /JEWGY73IIZ4j/i3yO6MSw1gJRe0ane3lZjpHFnFdaPPEcYHVWy3h7Zk UccnBd0ggkkLrHoG/CbRoVrF+90CDJymeAnYcWDycKQW84cNibj/tXxb CRk=
> nau.edu.		10199	IN	NSEC	_tcp.nau.edu. A NS SOA MX TXT RRSIG NSEC DNSKEY TYPE65534
> 
> No records, so no delegation, so nowhere to go to get the A record (which is actually configured).
> 
> As for BIND automatically populating DS records, I don't even know whether that's a feature. Is it in the docs? I don't remember seeing it, but it's a big manual and I might have missed that reference. . .
> 
> Bill.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users





More information about the bind-users mailing list