Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Brian Dickson <[e-mail]>]

On Wed, Oct 19, 2022 at 12:22 PM Tim Wicinski <[e-mail]> wrote:

>
>
> This starts a Working Group Last Call for
> draft-ietf-dnsop-dnssec-validator-requirements
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/
>
> The Current Intended Status of this document is: Informational
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  2
> November 2022
>
>
Here are some suggested additions to the document, both general, and where
appropriate, more specific in nature.

It may seem obvious to those familiar with operating DNS servers (resolvers
and authority servers), especially in the context of DNSSEC, but given
recent operation experience, I think the following need to be highlighted
explicitly, possibly in a new section (e.g. immediately after section 12 in
the document):

DNSSEC validation requires that the validator is able to reliably obtain
necessary records, especially DNSKEY records. This should be done at
initial configuration, and tested periodically.

This means the validator MUST ensure it is configured so that the UDP and
TCP transports, and DNS resolver components, are compatible with the
network paths that the majority of DNS queries traverse.

In other words, make sure that:

   - DNS UDP bufsize (EDNS parameter) is set to a value compatible with
   network MTUs the queries and responses will encounter.
      - If the validator advertises a bufsize >> MTU, responses with the DF
      bit set and response size R where MTU < R <= bufsize will be
dropped by any
      router with MTU < R.
   - The validator's OS TCP configuration has its advertised MSS set to a
   value compatible with network MTUs the queries and responses will encounter.
      - Having an advertised MSS set to a value < MTU ensures that Path MTU
      Discovery is not required
      - If PMTUD fails for any reason, or if the server responding does not
      maintain or use PMTUD, and advertised MSS > MTU at any point in the path,
      TCP may encounter problems caused by IP fragmentation and reassembly.
      - This is particularly relevant if there are any NAT type devices in
      the path, as those may not properly handle fragmentation and reassembly
      - If all TCP segments are smaller than the path MTU, TCP will work
      reliably.

We (GoDaddy) recently investigated a number of problems where the root
cause was one or more of the above situations.
While we have adjusted some of the server-side parameters, those can only
accommodate clients within an acceptable range of MTUs that we anticipate
will occur.
The avoidance of fragmentation in order to address known
fragmentation-related security issues with DNS (leading to cache poisoning,
for example) has resulted in the need to set the DF bit on UDP.
Validators will need to ensure their local environment can reliably get any
critical DNSSEC records (notably DNSKEY) over UDP, or reliably get
responses with TC=1 if overly large responses cannot be sent over UDP due
to answers not fitting within the advertised bufsize payload.
Validators also need to ensure TCP works if it is needed, for the same
situations.

Brian