dnsop-ietf99-minutes-1.txt DNSOP WG Tuesday 18 July 2017, 15:50-17:50 CEST (UTC+2) Congress Hall II Tim Wicinski , Suzanne Woolf 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