[RZERC] Recommendations Regarding Signing Root Zone Name Server Data

Peter Koch pk at DENIC.DE
Tue Jan 19 18:28:43 UTC 2021


Dear all,

in pereparation of today's meeting:

On Fri, Jan 08, 2021 at 12:41:24AM +0000, Wessels, Duane via RZERC wrote:

> It sounds like this is still a concern of yours even after the removal of the recommendation?

I do not have any concerns with the text as shared on 15 Dec 2020.  I must admit, though,
that I failed to circulate the draft, lacking a 'closed list'.

> I'm not sure that our document makes a claim that the root zone is special.  If I correctly understood what our GNSO representative says, there is now already a requirement for new gTLDs to have signed name server data.  It wasn't always that way, but this requirement was added at some point. I tried spending a little time going through the applicant guidebook to see if I could find the requirement, but I was not successful.

It doesn't make it explicitly, but it suggests that the 'root delegation' (the NS RRSet plus
glue) for the root is more valuable than any other parent side information or even the addresses
of the NS RRs at the child apex).

> For what it's worth, I don't think of this as "signing the delegation" but rather as adding signatures to the authoritative data of the name server names and addresses.  

Fair enough.  However, since the parent NS RRset isn't signed (and thus the delegation
response is spoofable), the attacker wouldn't need to just spoof the address records,
wouldn't he?

> If not signing the delegation is truly considered a feature, is there something we can reference to support that?

Not sure it was an explicit non-requirement, but IMHO follows from not signing
the parent NS RRSet, which was a feature due to the non-auth nature of that NS RRSet
(and wanting to avoid competing signatures over the NS RRSet). A DoS attack by sending
the queries the wrong way (another assumption: forgery would be detected by ubiquituous
DNSSEC) wasn't among the requirements, was it? Anyway, all this might already
be part of the research we're going to recommend.

Best,
  Peter


More information about the RZERC mailing list