Minutes interim-2021-dnsop-01: Wed 01:00
minutes-interim-2021-dnsop-01-202109150100-01

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