2

I'm interested in getting NSEC3 support for my domain getvalid.com, so that I can prevent name traversal.

DYN doesn't seem to support NSEC3, and it's clear that BIND and the DNS server require the ability to support NSEC3... but I'm unsure if the underlying registrar has any influence on NSEC3 support.

Do I need to do anything with a registrar for NSEC3?

makerofthings7
  • 8,821
  • 28
  • 115
  • 196

2 Answers2

3

In DNSSEC, the role of the root and intermediate nameservers are to provide a chain of trust until an authoritative nameserver for your zone is reached. Aside from hosting the public DS key associated with your signed zone, they have no role in NSEC3 validation.

For NSEC3 to function, you need to sign your zone using an algorithm that mandates support for the feature. Older algorithms are supported via variants that contain a -NSEC3- identifier. Resolvers will not attempt to utilize the newer functionality unless the support is advertised in this fashion. If the zone has been signed correctly, all you should need to do is follow the usual steps for getting the DS key digest published to the nameserver immediately before yours in the delegation chain.

From RFC5155:

In order to aid deployment, this specification uses a signaling technique to prevent NSEC3-unaware resolvers from attempting to validate responses from NSEC3-signed zones.

This specification allocates two new DNSKEY algorithm identifiers for this purpose. Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, RSASHA1. These are not new algorithms, they are additional identifiers for the existing algorithms.

Zones signed according to this specification MUST only use these algorithm identifiers for their DNSKEY RRs. Because these new identifiers will be unknown algorithms to existing, NSEC3-unaware resolvers, those resolvers will then treat responses from the NSEC3 signed zone as insecure, as detailed in Section 5.2 of [RFC4035].

Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • It's really only the original set of algorithms that were duplicated with `-NSEC3-` in the name to indicate NSEC3 support for compatibility reasons. New algorithms that have been introduced do not make such a distinction, such as the now very common `RSASHA256` (algorithm 8) which [supports both NSEC3 as well as NSEC](https://tools.ietf.org/html/rfc5702). – Håkan Lindqvist Apr 10 '15 at 17:15
  • @Håkan You're right. I've updated the answer to make this distinction. – Andrew B Apr 10 '15 at 17:31
2

As long as the registrar allows you to add any valid DS record that you want to the delegation of your zone, the registrar will not be a factor.

Some things that a registrar could do that would cause a problem is:

  • if they do not allow you to add DS records whatsoever you simply cannot have a signed delegation at all (with DLV as a potential workaround), not a problem for NSEC3 specifically but for DNSSEC in general

  • if they impose limits on the value of the DS record (specifically the algorithm field) that could force you to use an algorithm which predates NSEC3.


The limitation of algorithms is not something I have encountered but it's at least theoretically possible that someone could have outdated validation code in place or something like that.

Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90