[dns-operations] DNSSEC DS record generation for DOT-US from NSEC3 signed-zone

[Mark Andrews]

In message <4C670F87.7070206 at jason.roysdon.net>, Jason Roysdon writes:
> On 08/14/2010 02:22 PM, bmanning at vacation.karoshi.com wrote:
> > On Fri, Aug 13, 2010 at 05:58:06PM -0700, Jason Roysdon wrote:
> >> I am working on getting my DS record added to the DOT-US zone with
> >> Neustar.  In doing so, I found out they have a limitation of only
> >> supporting algorithm 3, which is DSA/SHA1, or algorithm 5, which is
> >> RSA/SHA1:
> >> http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xh
> tml
> >>
> >> They do not support algorithm 7, which is RSASHA1-NSEC3-SHA1.  So when I
> >> sent them my DS keys, they added them as algorithm 3, which of course
> >> didn't work and reported bogus DS records, so they pulled the record
> >> back out (thanks, Andrew).
> >>
> >> The problem I have is that my zone is using an NSEC3 and when BIND's
> >> dnssec-signzone generates dsset files, it does so with algorithm 7.  How
> >> can I generate DS records with NSEC3 keys, for algorithm 3 or 5 (NSEC)
> >> as Neustar requires?
> >>
> >> Thanks,
> >>
> >> Jason Roysdon
> > 
> > 	Don't ask Neustar to support something they don't.
> > 	Don't compromise your zone with tricks (it might look
> > 	like it works, but it won't)
> > 
> > 	Tell folks that want to validate your delegation to use the
> > 	DS record you publish - you can self publish or use a
> > 	reputation service like the ISC DLV.
> > 
> > 	A word of caution on the use of reputation services or self
> > 	publication.  Once your DS "escapes"... its virtually impossible
> > 	to erradicate it - which leads to all kinds of weird failures
> > 	down the road... ones that you can't fix on your own.
> > 
> > 
> > --bill
> > 
> 
> Bill,
> I just wanted to clarify a few things that you had assumed incorrectly:
> 
> I didn't ask Neustar to support NSEC3.  I asked if they supported DS
> records in dot-US, and they said yes.  They said I just needed to email
> it to them, so I did.  They didn't specify the requirements.  My DS
> record showed it was algorithm 7.  At that point they should have
> responded it was not supported, and they should have not pasted the
> record into their system using algorithm 3.
> 
> Someone on BIND-USERS suggested adding an NSEC KSK in addition to my
> NSEC3 KSK.  I get this error when trying to do so:
> dnssec-signzone: NSEC3 generation requested with NSEC only DNSKEY
> 
> As someone else pointed out, you cannot mix the two algorithms within
> the same zone, so it just isn't an option.  As I believe you're pointing
> out, you cannot just hack off the record and put it on a different DS
> algorithm (which I was never attempting to do, but Neustar did).

All the NSEC3 capable algorithms are also NSEC capable.  You can choose
whether to generate NSEC or NSEC3 chains.  The tools just stop you doing
both at once.  They also stop you adding a NSEC only DNSKEY when you are
currently using or request a NSEC3 chains.

> I am already in the ISC DLV, but just trying to get support all the way
> up to the root, as dot-US is now signed by the root, and dot-US is
> accepting DS records as of August 1st.
> 
> As a work-around, I had this thought:
> 
> Create a child zone, say cloaked.mydomain.us, and sign it with NSEC3
> and put the NSEC3 DS record for the child zone in the mydomain.us zone.
>  Re-sign mydomain.us with NSEC and send the DS off to Neustar.  The NSEC
> mydomain.us zone could be enumerated, but not the NSEC3
> cloaked.mydomain.us child zone.  Anything I don't want enumerated could
> go in the cloaked zone.  Very ugly work-around of a hack, but I believe
> it is technically a "solution" for implementing NSEC3 with a dot-US zone
> and the current limitations they have of only NSEC DS records.
> 
> Regarding DS records "escaping": Folks will have to come to terms with
> DS records being something that should not be hard-coded, or at least
> not without some automated warning/notification tracking system if
> they're going to do that.  KSKs will be updated, which will invalidate
> DS records.   But that's a great point to keep in mind for troubleshooting.
> 
> Thanks,
> Jason Roysdon
> http://jason.roysdon.net/
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org