# DNSOP ## Chairs: Suzanne Woolf, Tim Wicinski, Benno Overeinder ## Minutes taken by Paul Hoffman and Benno Overeinder, Tomek Mrugalski Text on slides is not reproduced here ## Updates of Old Work, Chairs, 10 min 5 documents completed WGLC: kskroll, terminology-bis attrlead, attrleaf-fix, ip6rdns. Shepherd write-up ready for end of Friday for completed WGLC documents. *Lack of feedback for capture-format, please send to the list.* * draft-ietf-dnsop-rfc5011-security-considerations Mike St. John: There is no list consensus Wes Hardaker: Should the document move forward? Please speak up on the list Is it benefitial to the RFC Series? Warren Kumari (as author): Happy to change the document name, if needed Suzanne Woolf: It is the chairs' job to judge consensus Wes: Silence is a fail Mike: Agrees. Has a problem with the content of the document In current form, more harmful than useful ### Working group has to speak out support or no support on the mailing list ## Current Working Group Business * draft-ietf-dnsop-algorithm-update, Ondrej Sury Lots of people have read Tim: Any pushback from the vendors for the curves? Ondrej: No, they're in plenty of adoption in libraries John Levine: Does this match what the implementers are doing? Ondrej: Yes Mark Andrews: Should do the same thing for SIG(0) Ondrej: This should be a new document Geoff Huston: Wants RECOMMENDED to be SHOULD Ondrej: Thinks that it closer to natural language Olaf Kolkman: Reads from RFC 2119 Paul Wouters: Should be more conservative for SIG(0) Marco Davids: Suggests to change MUST to REQUIRED Jim Fenton: Just for implementions, not for actions Suzanne: Can you add implementation section Warren: Add more text above and below the table about implementations David Lawrence: Wants a hum on 2119 words ### Hum: Leave the wording alone ### Add implementation status/details and then Working Group Last Call * DNS Cookies and their Operational Impacts, Ondrej Sury and Willem Toorop Paul Woulters: mandatory algorithms, but some optional? Ondrej: Need to work on this Francis Dupont: There are some questions on which is faster? Ask cryptographers Don Eastlake: Has been revving the draft, will join authors ?: What the response in the anycast goes to a different instance Dan York: Have to go back to the audience who is writing Don't give too many options OK to have more than one, but not choices within Olafur Gudmundsson: With TCP we don't need cookies. This is extra work Kill cookies Just use TCP Ondrej: Has a real world problem with cookies Paul Woulters: There are other drafts that mention cookies Tariq Saraj: What about privacy? Ondrej: It's in the draft Lorenzo Colitti: Instead of just using TCP, you can also use TFO Ted Lemon: In TCP, there is a suggestion to not use fragmentations This also goes to don't use cookies Ondrej: If we want to kill cookies, do this actively Have the conversation first Ray Bellis: There are operators who want to deploy cookies Mark Andrews: You are "literally" saying kill DNS over UDP Ted: Not personally arguing for this Cookies have many features I don't want to open a new socket for every request Managing a lot of sockets is hard Warren: Leaving things like this is dangerous Jan ?: Doesn't implement cookies on server, and doesn't intend to add them Generally down on cookies Paul Wouters: If the only goal of cookies to help accidentally make open resolvers not become part of botnets Please do not kill the cookies. Olafur: Let's write a kill cookies draft Ben Schwartz: Would like to hear from stub resolver developers about what their experience has been Willem Toorop: Already in getdns library and with it in Stubby stub resolver David: Already a mess, against TCP everywhere Skeptical that the BIND code could be made good enough Questions about speed of DNS Dan: Understands what Olafur wants to do How successful have we been on massive update to the DNS infrastructure? Takes ages. ### Working group must speak out on DNS cookies, its value, interop between implementation and how to proceed, or write another draft Kill DNS Cookies. We cannot do nothing, because as of now things break. * Let's Talk CNAME at the Apex, Willem Toorop and Ondrej Sury and Tim Wicinski (( Tim speaks from slides )) Lars-Johan Liman: Can we have a clear problem description? Tim: We need to be able to say something at the top of the zone Ray: Amazon's solution only works if it is hosted on Amazon Stéphane Bortzmeyer: Doesn't agree with the definition of problem Want a match between the name and the server Knows it won't be easy Problem is not "CNAME at apex" Likes SRV Tony Finch: This also needs to support alias-plus-MX Dan: Need to deal with the "not using www" problem Needs to use proprietary solutions Tim: Wants to be able to move between vendors easily Liman: Please don't overload CNAME Likes SRV solution Mark: Had productive discussion yesterday Should have a combined DNS/HTTP meeting, lock us in a room Wes: Keeps falling on both sides of the fence We are being asked to be solving a problem (Lot's of yelling "no") Joel Jaggli: Rejects notion that this is driven by another protocol *Driven by meat bags in front of keyboards* Wes: It was not the protocols' fault Roy Arends: Locally host CNAME at parent It still works, but is a horrible hack We need to solve this Wants a list of what breaks with CNAME at apex Jared Mauch: There is lots of history of how this is handled in email Many applications have such a hack Assign some record types for these protocols Tony Finch: We need a better fix than RFC 976(?) Dan: How can we make something that people will use Wants to meet business goals that push towards proprietary Murray Kucherawy: Nervous about making changes to protocol that is really for a change in users Liman: Willing to look at new record type Maybe do in software tools to configure DNS (( Willem and Ondrej speak from slides )) John Levine: This looks like BNAME Worth writing up, please do not progress it .cat uses DNAME Nearly zero web servers were configured correctly for this This is a code path that probably no one has tested Suzanne: How the world works vs. how the world ought to work Ray: The meeting last night was going to set up a mailing list ### Chairs will look into setting up a seperate mailing list for this discussion Ben: Quad9 uses PowerDNS Ondrej: Quad9 uses both PowerDNS and Unbound, and does see inconsistent answers Suzanne: Encouragment for people who wanted to do work Shane Kerr: Wants to know how to document how the work from last night should be documented Suzanne: Out of scope (( Shane's notes from last night's meeting can be found at https://www.ietf.org/mail-archive/web/dnsop/current/msg23419.html )) ## Previously Discussed Work * draft-huque-dnsop-multi-provider-dnssec, Shumon Huque How in the modern age do we get an operational document through DNSOP WG? Tim: Asking for more feedback. Sara Dickinson: Should go forward. Dislikes companies needing to decided between multi-vendor and deploying DNSSEC Does this model make it harder for someone using DNSSEC to migrate from one vendor to another? ### Call for adoption is on the mailing list and ends by Friday * draft-woodworth-bulk-rr, John Woodworth Dozen people have read the document David: a lot of relevant operators are not here There is an interesting issue: if you have an RRtype that will change authoritative behavior, we don't know how to signal to secondaries Mike: It sort of intends to break DNSSEC in interesting ways Would be a more baked statement on that Need such a statement before knowing if it would be ready for adoption Shane: Doesn't think that not knowing the DNSSEC changes should prevent adoption Paul Wouters: Confused about "informational", why isn't this experimental? Suzanne: It probably needs to not be informational Warren: Needs to explain what the experiment is John: Can people figure out how to implement this without breaking DNSSEC What sort of expansions do people actually do? Ray: This cannot just use Expert Review *Will* not go to expert review Peter van Dijk: What does this solve? Allows ability to transfer zones that are eally large from one server to another Jared: Generate large reverse zones for IPv6 takes long and makes large zone John: Thinks this is not a problem that should not be solved John: Has seen large zone transfer fails Peter: Kill GENERATE Tony: Doesn't need GENERATE Mark: ISPs weren't willing to delegate the reverse zones to their customers Use UPDATE This is solvable without BULK Takes client request John: A lot of times the customer is not technical enough to do this Use SIG(0) for forward Lorenzo: Need a document saying how to do this Send it to v6ops David: We are not cowards in this space There are other use cases There are many problems that GENERATE creates Ted Lemon: There are a lot drafts in HOMENET and DNSSD about updates Tobias Fiebig: About 15% of zones do dynamic zone updates Dan: Thank you for bringing this here This is the reality of operators John: There is number of vendors who are deploying something like this ### Chairs will discuss with AD (Warren) about status of the draft (EXPERIMENTAL?) ## New Working Group Business * draft-pwouters-powerbind, Paul Wouters Shortened version of what was given at ICANN IDS meeting last Friday Stuart Cheshire: Delegation only just one level down, not any depth? Paul: Correct George Michaelson: This helps with the hunting the zone cut problem Paul: To some extent, but you have to follow up This is better than web PKI Peter: All parents above me cannot skip me should be done today Roy: .co.uk is not an ENT Need clarification of how many levels down it A parent could still be coerced to delegate just one level down, then the next Paul: This is why we need DNSSEC Transparency Helps limit the logging needed for DT Seems a bit similar to label counter in DNSSEC Matt Pounsett: How does interact with delegation data in real zones? Paul: This would make orphaned glue rejected This could be a deployment problem Ben: Big supporter of DT Why does the commitment need to be in the DNS? Paul: That's only for top level Wes: If you don't signal it in protocol, don't know what can't be logged Equivalent to "we allow logging at this point of the tree" This bounds the problem for the log Ben: It is sufficient for the root to say it won't do this, and can tell the TLDs what to do Paul: ICANN can't tell ccTLDs what to do Shumon: This sort of assumes that most zones are delegation-only Would need to sign at each level Wes: Wants more feedback about what should go into the document How complex should the signaling be? Giovane Moura: Should go to see presentation in MAPRG tomorrow ### Chairs Action: Needs More Review ------- [[ Day 2 starts here ]] * draft-song-atr-large-resp, Davey Song Dozen people have read the draft Geoff Huston: We are not confusing one If you are on infrastructure that drops frags, this is great If signed with DNSSEC, bigger respons Ondřej: Implementer's report Doesn't like the idea Doesn't intend to implement unless there is a lot of interest Shane: The extra packet is pretty small In the worst case, it's 50% more packets and they are small Likes the idea Doesn't have to be implemented in the server, could be a daemon Mark: Likes this Whether bit or option is another matter Not a big negative at all JINMEI, Tatuya (神明達哉): Clever idea Worth discussing Makes UDP request stateful Peter van Dijk: ATR changes a best case from 2 packets into 5 packets APNIC research is useless We are making amplification attacks worse We have no intent to implement and is against adoption ### Chairs Action: Some interest but not enough for adoption at this time draft-tariq-dnsop-iviptr, Tariq Saraj Mark: Zero interest in implementing with this Why not just start with names? Doesn't think enough people will use these records Ondřej: This is about IDR Pushing provisioning problems into the DNS Should not be implemented ### Chairs Action: No Interest draft-wessels-dns-zone-digest, Wes Hardaker George: Remove "Merkle trees" On the list, asked for PGP; now likes this proposal Ondřej: Likes the idea Should be adopted Maybe distribute by a torrent Davey: Why not just use a checksum outside the zone Wes: Same as PGP slide Don't need to keep two file copies Encourage more widespread of zone Instead just add copyright on zone file itself Wes: allows the checksum Gain is that you get unmodified zone Paul Wouters: Signature is over the wireformat? Wes: Yes Glue and child NS are not signed Paul Wouters: Seems like rsync or whatever would be better Warren: Could only update this when you want to write this to disk or transfer Jim: Sign the rest of the zone first? Wes: Yes Mark: It is possible to do something similar: hash just the delegation points Will work with dynamic updates Also can loose RRSIGs ### Chairs Action: Interest in continuing, multiple implementations. draft-kh-dnsop-7706bis, Paul Hoffman-Kumari Geoff: Imagine I'm on a server on a host, I'm multi-homed, and forwards from IP to the other. Am I breaking the rules? Paul: Question for the doc. Geoff: What if I have 3 IPs? You're trying to constrain the moment. You can't apply constraint. Paul: We should discuss this in the document. Shane: Aggressive NSEC now published, should reduce temptation... Paul: Why? Shane: All cache misses will be handled Locally... Paul: One reason of 7706 is to preserve privacy. If you pull the root and pre-loading, nothing leaks. Shane: Will send text on performance Andrew: If people do weird things, no protocol police... Paul: Fairies but not police Wes: IETF document what people do on the internet. We should adopt Ray: Don't care on restrictions, local mirror of root zone is more important. Ondrej: Feel more Strongly than Ray and Andrew, don't understand why its wrong. Peter (via Dan): All Major Resolvers decided not to 7706 directly, so update is necessary. adopt Lars: Can change the keys. ### Chairs Action: Interest in adoption ### Chairs Action: Sounds like Interest in Contuining