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

Jason Roysdon dns-operations.20100813 at jason.roysdon.net
Sat Aug 14 21:49:59 UTC 2010

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.xhtml
>> 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

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).

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.

Jason Roysdon

More information about the dns-operations mailing list