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

[Daniel Migault <[e-mail]>]

Hi Brian,

Thanks for the feedback. I do think that it is relevant to add the proposed
text to the document. I have published a PR, feel free to let me know if
the text and recommendations are fine to you and feel free to update the PR.

[1]
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/pull/9/commits/5177f1b460db5a6db89b4c73032838441de1840b

Yours,
Daniel

On Wed, Oct 19, 2022 at 5:21 PM Brian Dickson <[e-mail]>
wrote:

>
>
> 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
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Daniel Migault
Ericsson