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 <brian.peter.dick...@gmail.com> wrote: > > > 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 > -- Daniel Migault Ericsson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
