WG: DNS Operations (dnsop) Meeting: IETF 87, Berlin Location: Bellvue Date: Thursday, 1 August 2013 Time: 15:20 - 16:50 (UTC +01:00) Chairs: Tim Wicinski (tim.wicinski@teamaol.com) Peter Koch (pk@denic.de) Minutes: Olafur Jabber Scribes: Dan York, Karsten 0) Introduction 1) Administrivia Peter Koch Introduces Tim Wicinski as new co-chair. 10-15 first time attendees Tim mentioned several Last minute additions, so please get them in earlier next time. 2) WG Updates ================================ 2.1) AS112 v2 Joint Discussion draft-wkumari-dnsop-omniscient-as112 draft-jabley-dnsop-as112-dname Slides: http://tools.ietf.org/agenda/87/slides/slides-87-dnsop-0.pdf Warren Kumari, Joe Abley Warren cedes speaking to Joe. Problem statement: Zones are delegated to AS112 servers, but hard to extend as operation is distributed and would create widespread lame delegations. Joe suggested adding DNAME which would fix the downstream requirements, but raises the larger question of whether DNAME is suitable for production? Next Steps: Experiment with DNAME first, then test DNAME in production If this runs into problems, fall back to the Omniscenet-AS112 as Plan B Suggestion is to adopt both documents in the WG, proceed in parallel. Chair asks room for adopting both documents, show of hands confirms WG wants both documents to move forward at this tim. ================================ 2.2) Child Delegation Syncronization draft-kumari-ogud-dnsop-cds draft-hardaker-dnsop-csync Slides: http://tools.ietf.org/agenda/87/slides/slides-87-dnsop-1.pdf Wes Hardaker, Olaf Gudmundsson, Warren Kumari The problem here to solve is to allow child zones to have the ability to handle key handoff. The CDS approach puts all the DS Content into the child, while the CSYNC approach uses bit-pointers to determine what to copy. There are lots of discussion here related to split view DNS and CDS keys. CSYNC is complex to implement but easy to operate. There is discussion about using 'DS' phrasing as it implies one mechanism instead of DNSKEY. Peter asks: Is this a problem worth solving: hum no: silence Question raised: If the group should investigate a single approach or multiple approaches? Both get similar volume, Question is raised: Who is willing to work on this: editors: 20 text: same number reviews: bit more Will need to hold people to this. Question is raised: Who is willing to deploy this at parent: half dozen at child: lots Question raised by Peter Koch: Is this the right working group ? Question raised to presenters: Are they willing to edit a combined document? yes End result will be there two new drafts, but they will have complementary sections. Then the WG will revisit the solutions. ================================ 3.3a) Improving Cache Performance draft-wkumari-dnsop-hammer-00 Slides: http://tools.ietf.org/agenda/87/slides/slides-87-dnsop-2.pdf Warren Kumari Problem here: Sometimes there is spike in resolution time when popular records expire. This is an optimization. Unbound does this using a percentage. Hammer uses a 2sec (guess) timeout. Jaap/Unbound: This is effective. Chair: Tasks Jaap to get measurements done Paul Wouters: Is this worth writing up ? Ondrej: Wants it as Informational JoelJ: Not Important at this time. Shane: Fixed time is better choice than percentage Roy: Is worried about extra traffic, but this as specified will cause minimal extra traffic Olaf: Is this possible problem ? Joe: This is about getting information faster to end users thus it is a good thing GeoffH: Have a second look at the percentage to give parent more control over how often to do this PeterK: Post research to list PeterK: is this ready to be adopted by Group: yes 3.4a) Flushing DNS Caches draft-jabley-dnsop-dns-flush-00 Slides: http://tools.ietf.org/agenda/87/slides/slides-87-dnsop-8.pdf Joe Abley A different take on the cache flushing problem. He mentions some TLDs which published incorrect zone information with long TTLs and caused user outages. Equates this to a "Big Panic Button". Talks about doing this using Notify on resolvers since that behavior has never been defined. Lots of people jumping into line with comments. Antion: How is this scaleable? PaulW: Scary censor ship Warren: Likes Johan: Your worst idea, only helps the bad operators Roy: Wants a button as it is but thinks the problem is complex, and not sure it is this right button Frank Martin: This will happen more often, Dan York: relaying MarkA, Peter Koch poses the questions to the group: 1. Is the problem worth pursuing? yes: strong, no: medium 2. Should we adopt this approach: yes: weak no: stronger Action is to let this fester for now, may revisit. Joe mentions Root Zone KSK Roll