All Thanks to those who attended the Interim, and thanks Paul for putting these together for us. Here are the draft minutes:
https://datatracker.ietf.org/doc/minutes-interim-2021-dnsop-01-202109150100/ As usual, if you spot something which you feel needs correcting, let us know. The chairs are going to sit down with the authors and come up with questions we'll ask the working group for consensus. thanks tim
DNS Operations (DNSOP) Working Group Interim-2021-dnsop-01 Chairs: Tim Wicinski, Suzanne Woolf, Benno Overeinder Minutes taken by Paul Hoffman Text from slides not included draft-ietf-dnsop-avoid-fragmentation https://datatracker.ietf.org/doc/slides-interim-2021-dnsop-01-sessa-dnsop-avoid-fragmentation/ Kazunori Fujiwara Brian Dickson: Maybe look at differences between stub-to-recursive and recursive-to-auth Paul Hoffman: Maybe have this be an informational document because it is not a single practice Warren Kumari: Informational is OK Brian: Could be a BCP if we have a must-not-exceed value Being a BCP will have people realize "this is really important" Peter Koch: Could live with a single value for developers, but need configurations for operators BCP could be "apply these considerations for good reasons" Tim: Would need logic for each choice Warren: It makes more sense to ask for a BCP, but let it be downgraded to informational by the IESG Mark Andrews: Has an expired draft about well-known TSIG Will defeat all fragmentation attacks, rather than saying "do not fragment on UDP" Current proposal leads to black holes in routers Can do what we want at the DNS layer instead of the IP layer Wants the WG to look at his proposal https://www.ietf.org/archive/id/draft-andrews-dnsop-defeat-frag-attack-00.txt Don't switch to TCP too early Brian: Thinks 1452 is a resonable number Likely to get through even the biggest tunnels What should auth servers set its buffer size? PaulH: The author's preferred value needs to be justified, not just stated Suzanne Woolf: Might be looking at this backwards The BCP is "don't just blindly pick a number, choose your use case and compare them to what's listed" Tim: Maybe breaking out the roles to make more obvious draft-ietf-dnsop-glue-is-not-optional https://datatracker.ietf.org/doc/slides-interim-2021-dnsop-01-sessa-glue-is-not-optional/ Duane Wessels Brian: Intent should be if you don't include sibling glue, must set TC=1 Must include it if over TCP Wants a MUST with refined wording Make it more clear Ben Schwartz: Would prefer zone operators must not construct sibling glue loops Authoritative servers can ignore zones with loops This is not a performance optimization Mark: This is not meant as an optimization, it is to make sure the resolver can make the next query You might succeed, but if there is a loop there, the resolution will fail Ben: Make it fail Paul: Would need to change the wording for RFC 1034 if we go to SHOULD John Levine: Clarify the new sentence for 1034 Agrees with Ben on MUST NOT for sibling loops Worth adding more words Duane: Please send text Warren: There should be an example of a sibling glue loop "Don't do this" Brian: Sympathetic to the concept of getting rid of sibling glue loops Could be arbitrarily deep in the DNS tree Not feasible to look too far down Ben: Don't create a loop, but auth servers MAY configure not to serve them The behavior has to be compatible Paul: Restated the need to change the 1034 wording if we differentiate sibling glue from classic glue Ben: Doesn't feel that the portability of zones with sibling glue loops is a priority Brian: Interoperability, not portability Depends where the sibling glue lives, particularly down the tree Duane: Hearing both opinions Most current authoritative implementations fit as much glue as they can, don't truncate This draft changes the "some but not all fit" situation Things will continue to work, but will see more TCP traffic Suzanne: Maybe corner cases Need to resolver these issues, but primary message needs to be clear Brian: Third case: if the auth server is configured to be narrow glue policy, that's different than today Should be permissable, TC=1 must be set Ben: Two questions: what is the glue policy, and what happens when the glue doesn't fit Separate out the glue policy Permit a range of behaviors Brian: Behavior over TCP is not affecteb by the glue policy Tim: need more from the mailing list
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
