In message <cab23998.b2f4%ray.wal...@nau.edu>, Raymond Drew Walker writes: > -----Original Message----- > > From: Tony Finch <d...@dotat.at> > Date: Tue, 4 Oct 2011 20:30:43 +0100 > To: Raymond Walker <ray.wal...@nau.edu> > Cc: "bind-users@lists.isc.org" <bind-users@lists.isc.org> > Subject: Re: DNSSEC not populating parent zone files with DS records > > >Raymond Drew Walker <ray.wal...@nau.edu> wrote: > > > >> In testing, this pipe sets up the following for nsupdate which fails: > > > >Sorry, I forgot the TTL command. Adjust its value as you require... > > > > dig +noall +answer dnskey $child | > > dnssec-dsfromkey -f /dev/stdin $child | > > (echo "zone $parent"; echo "ttl 3600"; sed 's/^/update add /'; echo > >"send") | > > nsupdate -l > > Thanks much, this makes much more sense. > > > > >> Am I also missing somewhere in the RFC where NS records of children > >>zones > >> need be populated in the parent? Is this something that has changed with > >> the addition of DNSSEC? > > > >No, it has always been an error. See RFC 2181 section 6. DNSSEC just makes > >the breakage more obvious. > > > After reading this, RFC1034, and conferring with the original implementor > of DNS at our institution, I have a better wrangle on the NS issue. Child > zone NS records were never populated in the parent because all zones were > under the same name servers, and "it just worked" (circa the early 90's.) > I mistakenly inherited on this understanding... until now. > > As for better automation of DNSSEC, my research lends little to no > information on proper child/parent DS record population. I am curious > about how to properly deploy in the future. > > My assumptions are the following: > -Sign a zone, then insert it's corresponding DS data into it's parent by > hand (nsupdate). > -Keep track of & update DS record data on a regular schedule. Potentially > via nsupdate, by deleting all DS record data in the parent zone for said > child, then inserting new DS records. > > Yikes, I was hoping auto-dnssec would handle these tasks. ;) Am I missing > any elegant solutions?
The really stumbling block is getting something to work with the registrar/registry model that everyone can agree on. Once that is sorted out we well see the key managers start to use it. > Much thanks to the list for their insightful comments... > > Raymond Walker > Software Systems Engineer Sr. > ITS Northern Arizona University > > > _______________________________________________ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ 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