named-checkzone error "NSEC node already exists"

[Mark Andrews]

In message <AANLkTikW6pXuf-cZFrX+oGwXDZaAqmec2y3KQ0pxKKbq at mail.gmail.com>, jim 
writes:
> --===============8614228914376772213==
> Content-Type: multipart/alternative; boundary=00163630e869ed2ed50496c3d6e6
> 
> --00163630e869ed2ed50496c3d6e6
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi,
> 
> Running BIND 9.7.0-P2-RedHat-9.7.0-5.P2.el6

Upgrade.
 
> New setup/install and attempting to setup DNSSEC and clean any dirty data.
> Got the zone signed and ran named-checkzone against it and got the following
> (11) times:
>      addnode: NSEC node already exists
> The .signed loads but want to have clean before going live and not sure how
> to narrow down where these eleven duplicates are coming from?
> See these repeated eleven times in debug.log for each start of named,
> running debug of 3
>    06-Dec-2010 14:43:39.266 database: warning: addnode: NSEC node already
> exists

Ignore it.  It's a artifact of the rbt implementation.  The warning has been
removed in newer versions.
 
> Sorry, some more stupid questions on DNSSEC that I'm just confused about.
> 
>  1) Do I sign my n.n.n.in-addr.arpa zone just like my domain.edu?
> 
>    # dnssec-keygen -r /dev/urandom n.n.n.in-addr.arpa
>    # dnssec-keygen -f KSK -r /dev/urandom n.n.n.in-addr.arpa
>    # named-checkzone -t /var/named n.n.n.in-addr.arpa dns.net.domain
>       runs OK
>    # dnssec-signzone -g -k Kn.n.n.in-addr.arpa.+005+33126.key -o
> n.n.n.in-addr.arpa dns.net-iup Kn.n.n.in-addr.arpa.+005+24720.key

Yes.  A zone is a zone.  There is nothing special about "reverse" zones as
far as the DNS is concerned.  It the users of the DNS that treat it as special.
 
> 2) After I have my island of security setup and working, register the KSK
> public key with educause correct?

You register the zones with there parents.  If educause is one of the parents
then yes, for that zone.
 
> 3) After registered with educause should I stop reading in
> /etc/named.iscdlv.key?

Publishing signed zones is independent of validating responses.  I
would stop using dlv when it stops giving a benefit.  At the moment there
are still lots of zones that can only be validated using dlv.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org