I know this is late in the process but why is DNS COOKIE not suggested as it is much better than source port randomisation for eliminating spoofed responses? It even works when NATs that de-randomise source ports are in the path.
Additionally I don’t know why all the root servers are not implementing DNS COOKIE today. Yes, I’ve complained internally about some F instances not implementing DNS COOKIE yet. Mark > On 20 Aug 2024, at 04:22, Orie Steele via Datatracker <nore...@ietf.org> > wrote: > > Orie Steele has entered the following ballot position for > draft-ietf-dnsop-rfc8109bis-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Orie Steele, ART AD, comments for draft-ietf-dnsop-rfc8109bis-06 > CC @OR13 > > * line numbers: > - > > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8109bis-06.txt&submitcheck=True > > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md > > * "Handling Ballot Positions": > - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > Keep in mind, I am not a DNS expert. > > Most of my comments are of the form "Why not MUST"... sorry. > > ## Comments > > ### Source Port Randomization > > ``` > 223 either UDP or TCP. If the query is sent over UDP, the source port > 224 SHOULD be randomly selected (see [RFC5452]). The Recursion Desired > 225 (RD) bit MAY be set to 0 or 1, although the meaning of it being set > 226 to 1 is undefined for priming queries. > ``` > > I'm not sure how to interpret this SHOULD in the context of: > > https://datatracker.ietf.org/doc/html/rfc5452#section-10 > > Seems like there might be some security impact if this SHOULD is ignored. > > Can this be rephrased as MUST/SHOULD as described in RFC5452 ... unless ... ? > > ### When should EDNS0 not be used? > > ``` > 228 The recursive resolver SHOULD use EDNS0 [RFC6891] for priming > queries > 229 and SHOULD announce and handle a reassembly size of at least 1024 > 230 octets [RFC3226]. Doing so allows responses that cover the size > of a > 231 full priming response (see Section 4.2) for the current set of root > 232 servers. See Section 3.3 for discussion of setting the DNSSEC OK > 233 (DO) bit (defined in [RFC4033]). > ``` > > Why not MUST? When can this recommendation be ignored? > > ### Why not MUST prime when expired? > > ``` > 237 The recursive resolver SHOULD send a priming query only when it is > 238 needed, such as when the resolver starts with an empty cache or > when > 239 the NS RRset for the root zone has expired. Because the NS records > ``` > > Why not MUST, unless the resolver starts with a none empty cache? > > Am I correct in reading the the priming query MUST be sent when the NS RRset > is > expired? > > Does this lead to an ability to distinguish priming queries? > > ### Good example of when to use a SHOULD > > ``` > 264 Note that this recommended method is not the only way to choose > from > 265 the list in a recursive resolver's configuration. Two other common > 266 methods include picking the first from the list, and remembering > 267 which address in the list gave the fastest response earlier and > using > 268 that one. There are probably other methods in use today. However, > 269 the random method listed above SHOULD be used for priming. > ``` > > I like that you have highlighted the alternatives to the recommendation here, > it makes it clear why SHOULD is appropriate... and that the recommendation is > known to be safely ignored in some cases. > > ### Cost of naming scheme > > ``` > 310 DNSSEC validation for the priming queries might be valuable. The > 311 benefits and costs of resolvers validating the responses will > depend > 312 heavily on the naming scheme used. > ``` > > An example could be helpful here, I don't have intuition on naming schemes > that > are "worth it", and Section 6 implies this is the only mitigation the document > offers. > > ### Indistinguishability > > ``` > 316 A priming query is a normal DNS query. Thus, a root server cannot > 317 distinguish a priming query from any other query for the root NS > 318 RRset. Thus, the root server's response will also be a normal DNS > 319 response. > ``` > > Would it be better to state that: > > "A priming query SHOULD be indistinguishable from a normal DNS query." ? > > Is there some risk of duplicity when relying on additional metadata to > distinguish queries? > > Based on section 6, my intuition is that an on-path attacker prefers the > ability to distinguish queries. > > ``` > 331 Resolver software SHOULD treat the response to the priming query > as a > 332 normal DNS response, just as it would use any other data fed to its > 333 cache. Resolver software SHOULD NOT expect 13 NS RRs because, > 334 historically, some root servers have returned fewer. > ``` > > Why not MUST? > > ### Zero is acceptable? > > ``` > 368 There are no requirements on the number of root server addresses > that > 369 a root server must include in a priming response. > ``` > > > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
