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
