DNSOP WG IETF 104 26 March 2019, 13:50-15:50 local time Chairs: Tim Wicinski, Suzanne Woolf, Benno Overeinder Minutes: Paul Hoffman Text from slides not reproduced here Session 1 Administrivia See slides ANAME authors may be reducing scope of document DNS-SD Document Updates; Stewart Chesire Will take more things to the WG list, wants more review from DNSOP folks IETF Hackathon: Everything DNS; Sara Dickinson Paul: Encourages people to come because it helps you when you are doing code Suzanne: Because the DNS lives in the real world, the hackathon is especially important draft-ietf-dnsop-multi-provider-dnssec; Pallavi Aras and Shumon Huque Shumon: Not ready for WG last call because there is a bunch of pending issues Jan Vcelak: Definitely looking for more input Shumon: Would like new draft to be ready for next meeting Willem Toorop: What are the colors of the keys? Blue is private key John Reed: Is this intended for steady-state, or transitioning? Shumon: Was for steady-state, but now moving to transitioning John: Will this help get rid of 6761 and non-cooperating operators Christian Grothoff: Have you thought about threshold signatures Shumon: Will do Tim: REGEXT is looking at registry handoff, also a side meeting on registry lock Mike StJohns: What if different providers are signing different parts? Shumon: Each provider is signing the whole zone Pallavi: Each signer needs to do NSEC or NSEC3, but not different Shumon: What about response size? Only changes DNSKEY records Petr Špaček: Does this affect aggressive NSEC? Jan: yes draft-ietf-dnsop-7706bis; Paul Hoffman Wes Hardaker: Why is the root special? Paul: Root is not special Wes: Seems useful to do pre-caching for any zone. Paul: Examples in Appendix showing how to do for other zones Wes: Root Zone List not correct Paul: Please send email Andreas Schulze: Anyone can try and see if it works. Paul: Should be for zone administrators who want this served this way. Matt Pounsett: Listing non-ICANN or ICANN projects, side projects come and go. Perhaps discuss these projects are ephemeral. Paul: Off-boarding is really important for this. Chairs: HyperLocal date? Paul: I don't predict well Paul: Knowing when a service stops working is really important draft-ietf-dnsop-dns-tcp-requirements; Duane Wessels Slides were originally for tcpm WG (TCP Maintenance) Sara: There are also privacy concerns with TFO Yes to promoting TLS Do you want to talk about DSO? Will send text Wes: 7706 code snippets Petr: From flag day, operators said this was not Internet Standard Suzanne: Chairs will follow up on that Suzanne: Have people tested this? Sara: DNS Privacy web site has some data on that for open source implementations draft-livingood-dnsop-dont-switch-resolvers; Jason Livingood draft-livingood-dnsop-auth-dnssec-mistakes; Jason Livingood George Michaelson: When the signalling mechanism is SERVFAIL, how do I know? Have to have extended errors Tim: Can they be combined into one? Jason: Yes Jim Reid: Supports Validating resolvers that will soft-fail: needs wording Matthijs Mekking: One document Ralf Weber: Could be split into different sections Warren Kumari: Who is the actual audience? Jason: Lots of people outside the IETF read RFCs Stéphane Bortzmeyer: Lots of people who talk to users read these documents Tim: Audience is network operations people who aren't obsessed with DNS like we are Matt Pounsett: Should work on it. Peter Koch: RFCs don't reach the right audience Paul: IETF Blog helps Joe Abley: Old RFCs get use Petr: Supports draft Dan York: Likes these kind of drafts We can point to RFCs Tim: We can bring this to NANOG Suz: Customer Support folks at operator shops care about these Dan: You want a small number of best practices documents Matthijs: Would prefer one document because they are intertwined Benno: Go for one document, then call on mailing list draft-lhotka-dnsop-iana-class-type-yang; Ladislav Lhotka and Petr Špaček Andrew Sullivan: Has opinions on IANA registries Do not get out of sync with IANA registry You will run into things that are deprecated Everything that is marked as "obsolete" is treated as "deprecated" You don't have to care about these Draft will be reviewed by YANG doctors Wes: Did you consider RFC 6168? Ladislav: This can be a difficult process This is just types that can be used in other places Wes: Think about TSIG keys Session 2 "New work day" draft-moura-dnsop-authoritative-recommendations; Giovane Moura George: R2: Disagrees that the study is representative because uses RIPE Atlas Wes: Asks whether we should bring to the WG, or remove some recommendations Lars-Johan Liman: What status do you want? Giovane: Informational, not BCP Liman: Suggestions or things to think about; not recommendations Customers will insist that "we much have this" and lose diversity Giovane: Reproducing the recommendations Liman: Not buying into that; needs to be observations Wes: Will think about it Stéphane: Thought it was good research Concern that this is only for big authoritative servers, not even medium-sized zone Wants title changed to make the scope narrow Giovane: Will change Peter van Dijk: Question about R5 Joe: Has read four of these papers Really about anycast, not about DNS Quite nuanced and subtle observations that are in context, but this document makes broad claims Don't think it is sensible to expand the papers Would prefer that this was a "literature review" These are too broad and across the board Peter Koch: 15 years ago, Lixia had a draft on TTLs WG could not agree on this Drop R5 from the document Open to making papers more accessible, but not to be recommendations or observations Wants more diversity of papers Benno: Wants more discussion on mailing list draft-sury-toorop-dns-cookies-algorithms; Willem Paul: Why SipHash? Ondřej Surý: Already used everywhere even though new Peter Lexis: License is public domain Benno: Will send out call for adoption, feels positive vibes Warren: Make sure security groups and CFRG know draft-stw-6761ext; Suzanne Woolf Warren: Would be nice if we could avoid the .onion discussion again Wants to work on this so we only do it once Jim: Good to not use DNSOP in the review, but needs a review process Expert review panel? Would be good to have some visibility Need to think about liason with ICANN Worried about double-dipping or gaming of ICANN process Doesn't want people coming to IETF to circumvent ICANN process Paul Wouters: Froze 6761 with selectively allowing others If we do not update 6761, we must move it to historic Suzanne: Want the process to not look arbitrary Christian Grothoff: Has proposal to overwrite root zone Has done usabilty studies to show that this works Wes: How to have input from ICANN is important Note to chairs: don't let this drop, critical to solve PeterK: Missing a recommendation: makes the name special, doesn't allocate the name If you have a name, you can make it special Doubts that DNSOP is the right venue, but doesn't have a better one IETF and ICANN have tried hard to coordinate Example of corp/home/mail Stéphane: Doesn't solve the real problem When people from outside to reserve TLDs We can talk to ICANN Draft doesn't solve the problem: it gives advice to people who already know about it Suzanne: "single label names" or not Are people asking for the name to be delegated in the DNS with specific behavior, or that the name be instantiated Distinct cases Other approaches are welcome Warren will decide how to move forward Warren: Would the WG please consider working on it? draft-brotman-rdbd; Stephen Farrell and Alex Brotman Brian Dickinson: Explicit declaration of non-mapping vs. missing declaration of mapping Defensive records saying that there are no other zones Alexander Mayrhofer: How can this work without semantics? There are other mechanisms, such as meta-tags Stephen: Trying to not do semantics Alexander: Makes this useless Jim: Not sure the DNS is the place for this kind of semantics How is this different than DNAME? Joe: Thinks the cesspool is fine The current mechanisms are terrible and inaccurate What incentive does the domain name holder to have to publish these? Alex: When people want to look legitimate Matt: Hard time seeing use cases Boils down to interpretation by anti-abuse researchers What will the absence of records mean? Could be messy More semantics John Reed: Which direction should it be? Lists can get real big real fast How to make sure it's gone on both ends when the relationship ends Murray Kucherawy: Need to address unidirectional cases may be attacks Sam Weiler: First party sets proposals Signing is crazy Warren: Not sure if it should be in the DNS Would like to disavow: more useful Dan York: Thanks for bringing it here Have you spoken other vendors who might implement this? What prevents less ethical people from claiming Murray: Has application in DBOUND ANAME discussion; Matthijs Mekking Wants discussion to be about current draft, or maybe a reduced scope Willem: Likes current draft, wants to implement it Brian: Issues that authoritatives must act in a way that resolvers used to do Won't scale, is an existential threat to authoritative servers Interferes with geo-ip that they have implemented Recursives scale by queries, authoritatives scale by zone Changes business model in a bad way Matthijs: New document would need to deal with authoritative aspects Similar to DNSSEC for geoip Shane Kerr: People have implemented things just like this, it scales Matt: This sort of thing does work Had to do ramp-up and back-off strategies Did simulations up to 10m zones Petr: Two documents: how to do zone transfer, rest Allow people to use multiple providers Olli Vannoja: Doesn't think it breaks DNSSEC Brian: Being offered by vertical integration suppliers, not authoritatives Matt: No Benno: Easier for two documents, but wants to hear more on the list Tim: Brian is incorrect One document is OK This scales, everybody does it Tony Finch: Would like more comments on the list from people who are already do this