dnsbundled BoF ============== 2016-11-16 https://datatracker.ietf.org/meeting/97/agenda/dnsbundled/ Jim Galvin \ Ning Kong Administrivia (5 min) - chairs ============================== Berlin Bar BoF Introduction (3 min) – Ning Kong =============================================== Problem Statement (10 min) – John Levine ======================================== Paul Hoffman: Forgot the option "Don't do anything in the protocol but add something to the master file. John Levine: Close to CLONE. Paul Hoffman: Well, that is on the wire. There are changes without any on-the-wire changes. * * * * * Ondřej Surý: I have a security case. When looking in the problem space, you must avoid anything that costs a DNS lookup on connection. That's the CNAME/DNAME/BNAME problem. If you need a lookup than you can easily DoS a server. John Levine: For web I agree, but maybe not for mail. Ondřej Surý: Even for mail you can overflow stuff. Pass a wildcard and ask for random domains and stuff like that. * * * * * Ray Bellis: The client side needs to know about things. Same origin problem. John Levine: Agree. I am implicitly agreeing that any DNS magic that you need to do on the server you also need to do on the client. Use Cases ========= .CN & .GR cases (4 min) – Jiankang Yao -------------------------------------- ... slides ... .TW cases (4 min) – Naiwen Hsu ------------------------------ ... slides ... .CZ cases (4 min) – Ondřej Surý ------------------------------- Diacritics can change meaning. Interesting example:\ nic - nothing\ nič - destroy (IMP) Registrar cases (5 min) – Richard Merdinger ------------------------------------------- ... slides ... Indian use cases – Harish Chowdhary ----------------------------------- ... slides ... John Levine: 22 languages is a lot. Does .IN really want 22 equivalent for every name in .IN? Or up to 22 depending on registrant choice? Harish Chowdhary: Depending on the geographic location. Important to do this easily. John Levine: So a small company may only want 1 or 2, but a national company may want all 22. Wesley Wang: Will help registrars deploy DNS resolution. Bundled relationship should be a reflection of requirements from the registrant/end-user. EPP protocol or some other method was considered? Jim Galvin: Short answer is "yes". John Klensin (via MeetEcho): With up to 20-odd names under .IN, a fairly large number of TLD for each language. Does this make it worse or simplify things? Harish Chowdhary: Easier for people to manage since there are several geographic locations. Open Discussion (50 min) ======================== Andrew Sullivan: This is not a WG-forming BoF. I am less concerned whether things are implementable. Concerned about restrictions placed on this. More concerned about whether the problem is clear. Discussions happened in Maastrict and before that. People say "I just want the two things to be the same!", we know that they want that. The problem is intractable. Richard's presentation is interesting, because it says "I want things to work the same way depending on context". A flattening of the naming convention in DNS, which is different. I thought people wanted DNS to work the same in two trees. But this case is actually different, "I want THIS name to work the same as THAT URI". That says naming is no longer directed graphs on the Internet, but naming of individual resources to be convenient. Then we need to ignore "MUST NOT change the DNS protocol" and instead try "invent a new naming system for the Internet". One other thing, we tried to do this in one other working group (DBOUND), and it was a complete failure for lack of interest. * * * * * Davey Song: Offer example with Chinese. Some improved method in app or computer use traditional Chinese. Young people have been trained to use traditional Chinese to chat. How to solve the problem? Solve at the application layer or in the DNS? Similar to RFC 4343, which tells us about case-insensitive. We can use this as common-sense that capital and lower case are the same. I just tried "GOOGLE.COM" and it is interpreted as "google.com". I think this is a real problem and we really need to think how to solve it. * * * * * Ted Hardie: This exact conversation happened at the Salt Lake City IETF. It was pointed out that a lot of these are one-way transforms. When I read the description of this and when I wrote the document. I can reduce this problem to a previously unsolved old problem. I want to make this in terms of DNS entries; the reality is that we have some Internet names which are on the DNS - .ONION for example. People want to use Internet names in all of these other contexts like URIs. If you say that what I want is an Internet name that has other heuristics in other resolution characteristics. I think we have to back up and take this up a step. Do we really want Internet naming that is not in the DNS? If true, then we have to take the "MUST NOT change the DNS protocol" requirement off. MUCH BIGGER SCOPE than bundling, but may be worth it. Paul Hoffman: [ asks about some other proposal ] Ted Hardie: Treats portions of the URI as outside the naming structure. Mine does this differently. * * * * * Jim Galvin: In general we just want to hear from the community and not reply. This problem space could be much larger than what we are trying to do here. We are trying to take two labels in the DNS and make them behave the same. A limited numbers of labels that we want to behave the same within the DNS protocol. * * * * * Jeff Hodges: Andrew mentioned DBOUND. Work that Andrew and I did there would arguably solve this. This is a sub-case of this. I don't know how this would work. It seems odd that we are shutting down DBOUND and discussing a subset of the overall problem space. * * * * * Yoshiro Yoneya: Question over scope. Need to make more clear which scope we are going to solve. * * * * * Mark Andrews: Thing that has been totally ignored, is that applications ignore CNAME. With bundled name we are looking where names are re-written with CNAME. For HTTP we don't do that, but we can create a record like MX or use SRV to point at a server. A fair bit of the problem is the application. * * * * * Stéphane Bortyzmeyer: I would like to go back to the first requirement, "MUST NOT change the DNS protocol". This is too fuzzy... if we add a new RR type we haven't changed the protocol, but we have to change software. Should "MUST NOT" mean "work with unmodified name server", which is very strict. Maybe the first requirement should be more detailed about what we expect and do not expect. Jim Galvin: The intent is that we want backwards compatibility. The installed base of servers & software should work. Ignored if did not understand. * * * * * Wesley Wang: About 40% of our customers have more than 1 domain name, with same labels under 2 TLD. We are interested in this, but the only worry is about DNS support. * * * * * Ed Lewis: A question about where we are going there. I thought it was not just registry, but general. "2 domain names that behave the same way". I thought that was a good problem statement for DBOUND. This is more than just a registry thing. What is it that you are after here? Looking at something more short term than re-architecting the name issue. What is the short term? A hack into DNS? Under a single registry? General purpose? * * * * * Peter Koch: Jim said we want domain names to behave the same in the DNS, "resolve to same result". We heard problem statements that the behavior was more about user experience. This would involve other systems reacting to this, the web server knowing what it has to serve, mail servers working, certificates being current, and so on. Are these out of scope? To be handled elsewhere (manually or automatically?)? * * * * * Paul Hoffman: Problem clear? Absolutely not. As we clarify we will get closer to saying "this is impossible!". I think that the problem being clear... the problem is clear to individuals and their problems do not map to each other. * * * * * Suzanne Woolf: I don't think there is a single problem. There are inter-related problems. The question is how the use cases relate. It turns out to be very superficial. Where previous efforts have foundered is that it is difficult to create a problem statement so that you will know when you have solved the problem to the satisfaction of the people that have it. Jim Galvin: Try to create a clear problem statement. Might be a solution here. I understand that the general problem is quite broad. We want to make a clear problem statement that we can solve. We have been using "two DNS labels that are the same and are substitutable. Trying to stay away from "equivalence" as it has too much baggage. Want the response to be the same regardless of which label. Important part is a signaling mechanism. Ning Kong: I have similar comments with Jim. The problem could be very broad but we want to focus on the DNS layer. Now the DNS protocol is lacking tools to help the registrant to set up a backpack of domain names. * * * * * Shane Kerr: Is there work in other areas? Is there work in other areas outside of the IETF that might move forward in less compatible or more inelegant ways? Jim Galvin: These would not be compatible, as there would be no signaling. * * * * * David Conrad: Not a DNS problem. Re-map the entire name space in ways that DNS doesn't support. So we end up in a pretzel shape, because this is far outside of the DNS. We have to deal with application and presentation layer issues. Jim Galvin: I agree. But I don't know what other lens to look through. The DNS is the identifier infrastructure that we have today. * * * * * John Levine: If we were better at writing provisioning software then we wouldn't have problem. The combinatorial explosion that I showed on one slide might be difficult to address, but other than that... I'm thinking that even though we have gone around and around, the problem really is not really a problem. I would really like to implement CLONE and do it in subtrees and see if I can make it work. That would be more likely to get us to a conclusion than yet another round like BNAME. * * * * * John Klensin: I am troubled because most of the use cases that I know of have the property of talking about what the users are going to do with it. This is not about labels. It is a problem about making FQDN match where each level may do different things. I'm wondering if we solve the problem being described here, whether that actually solves the problem people are interested in or whether we are going to end up with a different set of complexity down the road. The other thing I want to mention is that there was a large effort around 2002 to look at alternatives that would sit on top of DNS and was called by applications and provide more flexibility with spelling variations and IDN issues. That effort fizzled out, which is people decided they wanted to do it in the DNS. What we have tried to do ever since is make the DNS do things that it was never designed to do. * * * * * Jim Reid: I think this problem is too complicated and there may not be solutions. We are trying to solve things in the DNS that are at the application layer. Maybe we need to start from scratch. Maybe throw something out there. * * * * * Richard Merdinger: As we have looked to solve some of this. Everything we try to accomplish can be handled with orchestration between registry and registrar. At the bundling bar BoF the solution was narrow, if we expand a little then we can have a revolution in the way that content works over time. The intent is not to slow it down and make it a huge problem, but solve it within the context of what we can solve more broadly. * * * * * Davey Song: I partially agree with David in that it is not a protocol solution. It's not our problem, it's your problem. But it is a real problem for people who use variants. Provide some sort of mapping for people who use a domain. * * * * * Alex Mayrhofer: Looking at the DNS side it seems like minor problem. But the main complexity is in all the applications. So, I am coming more and more to the conclusion we can never actually have a 100% solution, therefore I like what John had said that lets try to do an experiment. * * * * * Jiankang Yao: I think this very complex. But the city from Seoul, but we can transfer at some other city. So maybe a 2 or 3-step solution. But we should do the 1st step. First step in DNS layer, then we can move to the application layer. * * * * * Warren Kumari: What does "All names in a bundle MUST be in the same context" mean? Jim Galvin: No information needed other than a DNS name. No primary or secondary. Open Questions (5 min) ====================== Closing ======= Jim Galvin: Please join the mailing list. We need more discussion. Work for us is to find words for a problem statement. Figure out on the list if we have properly scoped the problem and if there is a solvable problem. Jim Reid: Will the slides and minutes be published on the IETF web site? Jim Galvin: Yes! Slides are already online.