Minutes of the DNS Extensions Working Group meetings IETF 78: Maastricht, NL. Meeting dates: 2010-07-26. Minutes prepared by Mark Mcfadden 2010-07-28. Minutes prepared by Paul Hoffman. Chairs' note: These minutes are in radically different styles. The first covers action to come from the meeting and contains less of the discussion. The second covers the discussion and contains few actions to come. This is because the goals of the two meetings were different, so the styles are appropriate. ==== Session I -- 2010-07-26 ===== ==== The chairs thank Mark Mcfaddon ==== Action Items for DNSEXT - 2010 07 26 Existing item: RFC 2671bis Existing item: RFC 2672bis-dname - needs more text and should go back to the list - intent for this to be last-called again. Existing item: dnssec-registry-fixes - a new document will show up soon and thus there is no discussion in the WG - process issue will be dealt with a discussion on the list when there is a new version Existing item: draft-ietf-dnsext-dnssec-bis-updates - small number of hums for the "roll over and die" text is not okay and no hums for the text is okay - observation: few seem to have read the draft - demonstration of the "roll over and die" behaviour was given - CD-bit handling: nobody objected to having a default - unlike the two people on the mailing list - CD-bit handling: propose "Always set" as the default - nobody objected to this proposal - CD-bit handling: this proposal will be taken to the list - CD-bit handling: the intent is to last call this document in short order Proposed new major work item: "aliasing", "synonymy", &c. - BNAME, C+DNAME, other ideas. - discussion: should we do one of these regardless of the situation with IDN? - discussion: is this a solution for an existing problem, or a general approach that might be of use for many problem definitions. - discussion: it is possible to do this through provisioning rather than through protocol changes. - discussion: C+DNAME testing by Ondrej Sury - fundamentally works properly in a test zone; with some known problems - observation: are there are problems that cannot be solved by either of these solutions? There appears to be a list that will be provided to the mailing list - Observation: some resolvers do not support DNAME - Sense of the room: 2/3 of the room had read BNAME, C+DNAME, and Shadow Drafts - Sense of the room: 1/3 of the room had read the Problem Statement draft - Shadow zones o draft-vixie-dnsext-dnsshadow-00 - agreement: shadow does have utility outside of BNAME and C+DNAME - discussion: seems to be some disagreement over whether or not to do this work - action: whether or not to proceed on Shadow Zones will go to the mailing list - Rationale/applicability. o draft-yao-dnsext-identical-resolution-01 - discussion: Suzanne Wolff presented an overview of the probglem statement draft and its goals Proposed new charter. - The proposed charter was posted to the mailing list: http://www.psg.com/lists/namedroppers/namedroppers.2010/msg01836.html - Sense of the room: Could the work be moved earlier? two hands only Could not? two hands only - Discussion: implementation is separate from making decisions about what work to do in the WG - Rough consensus: move the dates up compared to the original draft prepared with the charter - Action Item: chairs will prpoduce another draft and send that to the IESG Returning work items. draft-crocker-dnssec-algo-signal-06 - In Stockholm last year, Patrik Faltstrom determined that this document would be needed if and only if something like draft-ietf-dnsext-dnssec-alg-allocation were published. Since that is about to happen, this document appears to be up for adoption. - Patrik has agreed to be shepherd. - Rough consensus: No objection to the arrangements for moving this document forward Additional work items. IXFR-only: draft-kerr-ixfr-only-01 - Rough consensus: not proceed with this work, replace it with a larger document with more material (15 September or proceed witht the current draft) DNSCURVE draft: draft-dempsky-dnscurve-01 - Supporters of the document need to come up with timelines - Consensus needs to be reached on the objections to adopting the document - Consensus by the 15 of Sepatember or this will default to a WG document URI DNSRR: draft-faltstrom-uri-05 - Don't need to adopt this in the Working Group because it is going through the expert review process ==== Session II -- 2010-07-28 ==== ==== The chairs thank Paul Hoffman ==== DNSEXT Wednesday morning, 2010-07-28 Andrew Sullivan and Olafur Gudmundsson Minutes taken by Paul Hoffman Things from the slides not copied here You must read the slides to get more details Goal of this meeting: see if we are on the right track with the aliasing work we might add to the charter Andrew's introduction to the meeting What we have today CNAME and DNAME Second-class citizens Cannot be the target of an MX record Some people think (wrongly) that we already have aliasing finished Proposals so far CNAME+DNAME Many recursive servers don't do DNAME today BNAME SHADOW Provisioning Currently has deployment and usability issues Many people have said that "just provision" is not viable May not have the same folks administering the two sides Lots of things are out of scope All solutions will have some problems "First class citizen" issues for all of current proposals Purpose: to collect use cases Olaf Kolkman: does the "don't do anything" come under that header John Klensin: user community thinks that it has names that are equivalent Based on Unicode rules that say two spellings are equivalent One needs a pair of names (equal and symmetric) Real aliases Can be at any level Some people wants to ask about both names CNAMEs pointing in both directions: heads explode Andrew: is this about a character-to-character maps? John: that's only part of it: it is really label-to-label Related: changing the matching rules You made these ASCII labels match, make my language match the same way Antoin Verschuren: design of the DNS it self Worried if we are going to design something with aliases for nodes in the system Becomes a web, not a tree: bad Only work if the aliases are for outside the DNS Ondej Sur: which solutions need signalling? BNAME needs signalling, CNAME+DNAME doesn't Andrew: maybe both do Harald Alvestrand: most common use case for "we want these two be the same" is the web If everything is friendly, we don't need the DNS There are lots of ifs Someone owning a higher-level zone want to tell people in lower zones how to do things Maybe easier for the top to do things correctly underneath than having all the bottom pieces do it right Aliases can be helpful, but is neither necessary nor sufficient; makes things a good bit simpler Towards John: I don't have any idea what "equal" means John: if we optimize for the web, we are making a bad decision EAI means we will see a whole new domain of use cases From Phill Hallam-Baker on Jabber: We need to do the shadow approach Same fixes needed for shadow will be needed for the other solutions as well John: making lots of assumptions of what applications need I thought that we were not cutting things off here Doug Barton on Jabber: What is the use cases for equivalence? John: Unicode is a mixture of legacy scripts that made a strange mixture People type on keyboards (input method editors) Easy to get different characters from similar users Can type things the same that look the same on the screen, they might not match Spelling cases of different sorts: color vs. colour Lots of divergence even in one spoken language When normal people look at them, they see the same things Expectation that computers will fix this Suzanne Woolf: we need more examples on the mailing list in order to fully develop the problem statement Ondej: equivalence of two labels doesn't need to be equivalence in the DNS Can make a framework that will work elsewhere, not in the DNS Andrew: can have the underlying DNS layer and a different layer where they are looked up Ondej: you already have that in other layers: Apache handles this Andrew: mail server has this problem Ondej: can relax the rule for mail servers Andrew: the mail specifications are outside our scope Paul Hoffman: you can choose them to be Andrew: there is tension between working groups Ondej: you just need to be careful what your target is pointing to Andrew: see what Harald said earlier: the entire tree issue People down the tree won't know that they are in an alias Suppose we have two input methods: can't know you are inside an aliase tree Ondej: If you are there, you can't change anything anyway This is just one more place where things go wrong if you do them wrong John: when we first looked at IDNs, one conclusion was that we couldn't do this fully in DNS This is a descendent from before Some decided either DNSNG or something else that did mapping Design systems princidple is where you draw the line Instead of keep kludging in the DNS, consider doing one of those options Could have different deployment options between them Maybe say "at this level of DNS abuse, we must stop" Paul: we tried to work on some of these, but there was no user interest John: if we have something that almost works, we can't start work on something that might be better But we might be approaching "the current stuff doesn't work" Andrew: what are the weird effect John: if the user hears "x is equivalent to y", they think "everyplace I use x I can use y" Also "I can find y if I look up x" Pure trees are lousy for human knowledge and queries Have to careful with cross-tree pointers Andrew: send this to Suzanne Olaf: what is the timescales in which we need solutions Different time scales might allow kludges or might force real solutions Adding kludges to a point where you making a promised that it will be a workable solution: You wasted time and energy Yao Jiankang: the problem is that the user says domain a and domain b are equal Thus they want same resolution Harald: domains will be declared equal whether we like it or not Question is: will doing standards work in the IETF make life better or worse Alfred Hönes: the DNS is tree structured You can't have true equivalence in a tree Some points will be first class Only solution is the have replication All examples from Unicode show only the registrant can decide what is equivalent to what they registered We might be able to capture what the registrant wants equivalent We need a canonical form for correctness: DNSSEC We need a canonical form to avoid combinational explosion at multiple levels of the tree Pointers to the canonical form Olafur asks questions: Apps folks: do the proposals help here: not enough information, no one said yes, some said no Timeline: this is in the next few weeks Get your examples to us soon that