On Wed, Oct 19, 2022 at 12:22 PM Tim Wicinski <tjw.i...@gmail.com> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
