Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Paul Hoffman <[e-mail]>]

Thanks for the support for the doc; I hope others chime in as well.

On Jan 9, 2024, at 08:33, Paul Wouters <[e-mail]> wrote:
> 
>     there are 13 root servers.
> 
> I would really like to see this changed. We keep trying to tell people
> that are not DNS insiders that the world does not depend on just 13
> physical machines. This will cause that confusion to strengthen again.

Good catch; fixed.

>> It is in DNS master file format
>> 
>> Maybe use "zone file presentation format" instead of "master file format"
> 
> This still stands as well.

Agree; fixed.

> Perhaps a recommendation could be to check with ZONEMD and do an AXFR,
> eg recomend implementing RFC 8806 - "Running a Root Server Local to a Resolver".
> Comes with added bonuses on top of a signature on all the root glue.
> 
> I still think this would also still be good to mention.

This would be a very comfusing mention because the resolver isn't really "priming" at that point, it's using a complete root zone. I'll cover this with an addition to the Security Considerations section:

<t>This document does not cover the use of (or the need for) priming when
serving a copy of the full root zone on the same server as the resolver,
such as is described in <xref target="RFC8806"/>.
In such a setup, the resolver never really primes its cache because the
cache is full as soon as the resolver pulls down a new complete root zone.</t>

(Suggestions for better wording are welcome!)

> 
>> [[ This section talks about sending the DO bit, but does not actually
>>    talk about validating the response to the priming query.  This became
>>    important after the root KSK rollover in 2018 because some resolvers
>>    apparently were validating and only had the old KSK, but were still
>>    sending RFC 8145 telemetry even after failing to validate their
>>    priming response. ]]
> 
> I said before:
> 
> Nothing much can be done here other than advising implementers to check
> if the obtained DNSKEY RRset no longer contains any KSK that is
> configured as part of the software, and then doing some kind of
> exponential back-off to slow down the query rate?
> 
> The comment was removed but no text was added for this ? Should there be?

I'm not seeing what adding this would solve. The only possible attack is that the old key was compromised by the machine-in-the-middle attacker, but that is a completely separate issue from priming because the priming response is not (currently) signed.

> I also wrote before:
> 
> So now I do think the document is ready, but I think it would be nice to
> mention ZONEMD and local root configurations as methods to protect
> against spoofed glue.

See above.

--Paul Hoffman