dnsop-wg-materials/interim-2021-dnsop-01/interim-2021-dnsop-01-minutes.txt

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 soMUST 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