Hmm, I see an A record using the same query: [foo@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users