Minutes IETF99: dnsop
minutes-99-dnsop-05

dnsop-ietf99-minutes-1.txt

DNSOP WG
Tuesday 18 July 2017, 15:50-17:50 CEST (UTC+2)
Congress Hall II
Tim Wicinski <tjw.ietf@gmail.com>, Suzanne Woolf <suzworldwide@gmail.com>
Minutes taken by Paul Hoffman
Text from the slides is not reproduced here

Updates of Old Work
    Lot in the queue

TSIG vulnerability
    DNS vendors got together on Sunday to talk informally
    Decided that there needed to update RFC 2845
    RFC 2845 doesn't cover all the cases
    Will start on a -bis version

draft-ietf-dnsop-terminology-bis; Paul Hoffman
    No slides
    Will be bringing up topics that were punted in RFC 7719
    Wants lots more review
    Please open issues on the GitHub repo (but Paul will endter them if they
        come from the mailing list)

draft-ietf-dnsop-dns-capture-format: Jim Hague
    Paul: What is the reason for things being mandatory?
        Jim H: To make reconstruction possible
            That's the only one
    Jim Reid: Any news on IPR?
        Jim H: Copyright is from ICANN, talk to Terry Manderson
    Stephane Bortzmeyer: Maybe have two profiles, one with mandatory one with
        nothing mandatory
        Jim H: Maybe need more than two, but we can't know that now
            Need to handle optional data in some other means
    Roy Arends: Happy user of the format
        Is there a mailing list?
        Jim H: Use the dns-stats mailing list
        Sara Dickenson: Wants to see more traffic on the DNSOP mailing list of
            specific use cases

draft-ietf-dnsop-rfc5011-security-considerations: Wes Hardaker
    Mike St. Johns: "30 days" is used twice in RFC 5011 for different things
    Mike: The sum of a wall clock time and an interval is a wall clock time
    Warren KUmari: We are not "adding" anything
    Olafur Gudmundsson: This is worst case times
    Tim: Used interval times in an earlier RFC
    Suzanne: This could be ready for WG Last Call

draft-ietf-dnsop-aname: Peter van Dijk
    Ondrej Sury: Finds the draft confusing
        Peter: Agrees that the draft has grown in bad ways, and will fix
    Stephane: This is just for HTTP, but supports the draft anyway
    Benno Overeinder: Has a concern that when the zone owner is not the zone operator
        Wants a security consideration about online signing because of the difference
        Peter: We are stretching the definition of "offline", should be fixed
    John Levine: Never wants to do online signing, hopes that this can settle it
        Has a concern that people will want SRV records and/or MX and would
            want to sweep them in as well
        Peter: That would take the draft further from the current
    Ondrej ?: Doesn't like the idea of online signing for everything
        Would prefer draft was more explicit that you don't need to do it
    Andrew Sullivan: Concerned that people are saying that it is too complex
        Document should say why this is hard
        This will help explain the tradeoffs that were chosen, get quicker
            convergence

draft-ietf-dnsop-session-signal: Sara Dickinson
    Christian Huitema: QUIC does not guaranee the order, but neither does UDP
    Stuart Cheshire: There may be operations that create state that must be
        done before following ones
    Christian: Can do this in different ways
    Stuart: Push notification need ordering
        If we use a transport that gives ordering
        Christian: You are mandating a sequencing transport
    Ted Lemon: Session signally carries state
        You either have order, or not
        Sara: We need to make this clearer
    Andrew: There were other uses for this
        Maybe use DNS Update type ordering
    Petr Špaček: Current session signaling draft creates DNS v2 and uses
        original DNS v1 as a transport. Clean break would be better.
    Ondrej S: Torn about the new format
        People who are not here won't know about the new format
        But breaking this barrier would let us fix things that we did wrong in the past
        Doesn't like breaking all extensions by "I'll do it as a TLV as well"
    Ted: Duplication is a real issue
        EDNS0 sucks, it is hard to work with, it is an RR
        This is for representing things not an RR
        Totally flexible format
        You would have to be really broken if you tried to parse this as DNS
    Matt Pounsett: TLVs separate the control plane from data plane, which is good
        Concerned with embedding DNS messages in TLVs
        Sort of a layer violation
    Stuart: Thought we were embracing this document, not changing it
        An EDN0 is neither an RR nor not an RR
        The Wireshark decoder has to display different things for that record
            Caches need to know not to use the TTL
    Francis Dupont: This is a totally new protocol, and start from scratch
        So don't reuse anything
    Tom Pusiteri: Likes the TLV format because it makes you think separately
    Suzanne: Good fodder for an interim
    Tim: We want to make sure that people see that we're making breakage

draft-woodworth-bulk-rr: David Lawrence
    Peter vD: BULK doesn't work for secondaries
    Ralf Weber: This has some odd side-effects
    Paul Wouters: Can you see the difference between PTR records and
    John L: This is less horrible than previous version
        There are other things like this that no one asked to standardize
        Why don't you just write this for yourselves?
        If you do this, you have to do online signing, don't ask people
    Ondrej S: Agrees with John
        Maybe add a new DNSKEY type that is for online/offline key
    Andrew: The reason not to "just do this with all your friends" is to make
        more competition and have a better ecosystem
        David: My employer can do this already, but multi-vendor would be better


draft-tale-dnsop-serve-stale: David Lawrence
    Ralf Weber: Huge deviation was what the protocol was supposed to be doing
        Write more up on the requirements
        Far too detailed for deployment
        Maybe not be standards track, should be experimental
        This is just one approach
        Warren: If other implementations want to describe how to do this, that's great
        Ralf: Let implementors do it different ways
        David: Maybe lay out at least one way
    Benno: Similar questions about IPR
        OpenDNS has some
        Warren: Not clear if it applies
    Ondrej S: Agrees with Ralf
        Doesn't think hard timers are correct
            Should be derived from original TTL
            Should not stretch a 30-second TTL to a week
    Giovani Moura: This seems useful after some changes

draft-muks-dnsop-dns-opportunistic-refresh: Stephen Morris
    Suzanne: We need reviewers
    Lars-Johan Liman: This is only relevant when you're talking to authoritative
    Ondrej S: Only marginally useful
    Roy Arends: Loves the idea
    Matt: Seems like it might be useful
        Worried about extending TTL on NS records or RRSIG
    Warren: This is really cool
        Not sure if it all that useful because you have to look into the zone
    Alex: Finds this interesting
        Could you simulate this
        Maybe have an EDNS that returns the timestamp
    Shane: Can look at authoritative server log and estimate the value this would have had
        If you have access to large authoritative logs, talk to me so we can
        do more measurements
    Jim R: Maybe use a timestamp
    Ralf: There are servers that have no idea of serial or last update
        Stephen: This is completely optional