Draft Minutes: 2011-03-31 15:57 DNSEXT WG Monday afternoon, 2011-03-28 Chairs: Andrew Sullivan and Olafur Gudmundsson Minutes taken by Paul Hoffman Start: 15:21 Summary since last meeting was sent to the mailing list Action Items: from meeting: work hard on "finish" Aliased Names Requirements, soon. ask for WG to adopt Resimprove Discussions: Problem Statement: DNS Resolution of Aliased Names http://tools.ietf.org/html/draft-ietf-dnsext-aliasing-requirements-01 slides: http://tools.ietf.org/agenda/80/slides/dnsext-1.pdf Presenter: Suzanne Woolf The requirements list is not lengthy, but we have to be sure that they are the right ones Andrew: ICANN had a meeting two weeks ago Goal was to increase communication between the policy folks and the "technical geeks over there" Both sides understand that there are open policy and technical issues The meeting was "not unsuccessful" Big news from the meeting: ICANN is seriously persuing their policy for IDN variants We should have potential input to what they will do We should ready for last call; is there pretty good consensus "Does this sound like a reasonable set of limitations?" Then we put it on the back burner while the ICANN style of working goes on Phill Hallam-Baker: There are ways to deploy things quickly Could add web redirects with interstitials People will do this anyway even if we don't want it Will cause middleboxes to make decisions to kill you Think about the interstitials when you design the long-term solution Suzanne: The "long term to deploy" is not about deployment but protocol development Ted Hardie: Mailing list discussion converging on how to know what the canonicalized form would be Has a niggling fear: what they get out of their provisioning is that all are the same Not getting the canonical version from it Worry is that we will asked to give a presentation layer for the entire Internet Might have variants point to a meta-record, and none of the variants are any more important than the other Peter Koch: Is it acceptable to have an aliasing method? Suzanne: Did people want equivalence or just a correspondence? Should we be exposing to applications that there is a canonical version? If the requirement exists for strict equivalent in a real-world use case, we haven't seen it yet. Niall O'Reily: Ted: the IRI WG could use some energy Harald Alvestrand: Worried that we are not deploying into a greenfield Is worried that the term "canonical name" is not well-defined CNAME is used in many odd places What do the proposed mechanisms do to the current mechanisms? Worried that we haven't figured out all of the harms Suzanne: a requirement is that all things can be optionally deployed Andrew: Are you suggesting that people are using CNAME in a way that are not defined? Harald: Web hosting turns out to be a complex business Paul Vixie: Generally in support of moving the draft forward Asked why MX and NS records could not point to CNAME? Considered to be a lightweight, temporary copy of the "old name" for redirections If we layer our solutions on top of CNAME, we will be constrained by CNAME's limitations Andrew: Lots of people have read the draft Small number thing it is close to ready to go Small number think that there things deeply wrong in the draft Medium number think there are gaps in the text Few think that Andrew's idea of putting it into stasis Ted: If our answer is "no magic here", we should tell ICANN sooner Suzanne: if we don't get additional input, we should wait Jaap Akkerhuis: ICANN is going to do a five-phase(?) study on specific language variants The study is pretty undefined Not optimistic that we will get anything useful from the discussions Harald: Waiting for ICANN to finish is not a good move Paul Hoffman: Now that he heard Jaap's description, would say "don't wait" Thomas Narten (IETF liaison to ICANN): Both should go on in parallel We need to think about the best way to communicate with ICANN Suzanne: We are making good progress and we need more input Resolver Improvements http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 slides: http://tools.ietf.org/agenda/80/slides/dnsext-1.pdf Presenter: Paul Vixie Intended to be non-controversial and non-wire-effecting Got input that turned out to be editorial -01 coming soon There are counterexamples Mailing list thread is inconclusive Thinks it is a restatement of clarification John Levine: RBLDNSD will be fixed TinyDNS should be fixed John will start a mailing list to update Peter: 1034/1035/2308 didn't have any idea of aggressive negative caching Need to make the operational side-effect Paul: used for spamming Mark Andrews: there were DNSSEC RFCs that got it wrong Duane Wessels: wants lists how current implementations work with the other sections Paul: no operational experience Tony Finch: risk of DoS if you co-host mail server with DNS server Phill: suggest EDNS extenstion for conformance validation Peter: worries about the accumulated resolver behavior Wants the same level of care here as we applied to IDN Olafur: Lots of people have read this draft Will ask whether to make this an WG doc Will be listed as udpating 1034 End: 16:19