WG: DNS Operations (dnsop) Meeting: IETF 89, London Chairs: Tim Wicinski Suzanne Woolf Session 1: Special Meeting to discuss DNS Privacy Location: Hilton Metropole, Sovereign Date: Thursday, 6 March 2014 Time: 1840-1940 GMT 1) Introduction * Summarize problem statement Stephane Bortzmeyer: DNS privacy problem statement (as presented to DNSE) 1. What relevant data is in the clear? - Who is requesting (querying) - QNAME (you might use https, but the DNS request is in the clear - on the path to the DNS server, not in path of https) e.g. might reveal names of individuals, or the software that is being run. 2. Where is the data revealed? - Nameservers - on the wire (sniffed) 3. Two cases: - Client talking to full resolver (but usually not many of these) - sees all queries - Resolver communicating with auth servers - don't see the client details, but see the qname - sees a subset of queries Mic: John Klensin: Assume resolver is not in the control of the client? Stephane: Recommend run resolver on your own machine Mic: Russ Mundy: Is there already a conclusion that we're going to try to protect as much as we can, irrespective of what it is we're protecting? Security not free - need to tell people why/what Stephane: Suggestions already on classifying data in the DNS - sensitive/not - but very complicated to do this - easier not to try. Concur that not all DNS data/queries are sensitive. Mic: L. Aaron Kaplan: Make sense to document which (DNS) names should not be documented in the DNS because they're sensitive? Stephane: DNS is public. The fact that you query it/visit sites is not public. E.g. internal site names that are queried unintentionally when outside the corporate network. Mic: L. Aaron Kaplan: what can leak and what should not leak. mDNS leaks Mic: Doug Otis: (wasn't at BOF). UDP/TCP - assumes mean go to Secure TCP - but big overhead from this. Mic: Peter Koch: In DNS you need to know what to ask for - if you don't know what to ask, it's hidden. E.g. hashed names - not exposed unless you share them (e.g. in email) Happy to discuss cost (financial and operational) as well as loss of monitoring facilities, latency, cache sizes etc.. Mic: Erik Nordmark: One of things not discussed is what level of security expected - something easy to get started, but once have talked to that resolver first time, ramp up to higher level of security? Stephane: Need first to determine which are the realistic problems - and then later talk about solutions (which includes trade-offs) Suzanne: Do we need a requirements document as possible output ? Mic: Andrew Sullivan: When you frame a problem statement - need to include the boundaries; also need to pay lot of attention to 'must not leak to ... whom?' Who are we trying to prevent seeing this info. Also can't just be stuff about what can't be leaked - better to find out what your protecting against, and whom. Mic: Barry Leiba: What Andrew and Stephane said... Please do not do a requirements document and publish it - just use it as part of working process. Barry Answering Andrew: What needs to be protected? The entire query and response. Mic: Russ Mundy: Because DNS is a ubiquitous service - can be a problem for some users, but we don't know who they are - need to protect all Mic: L. Aaron Kaplan: responding to Peter Koch - depends on the TLD - what kind of information we want to protect; which threat actors; ensure privacy when needed. Mic: Joe Abley: For some users there is a tradeoff between privacy and performance. Sometimes the client wants their IP/source address to be revealed for CDN-based perf improveents. Some people may WANT to opt-out of privacy. Mic: Ted Hardie: Some people at the mics are asssuming the properties of the solution; We are trying to ensure privacy and confidentially - ensure we cannot learn from the DNS what people are doing in their secure pipe. Have object integrity for some parts of the DNS already and a confidential channel. Don't rule out other classes of solutions because they're not part of what we think of as DNS Stephane: You can also have data revealed in the servers. Mic: Brian Dickson: Boundaries based on registration - what is secure, what isn't Mic: Peter Koch responding to Ted Hardie: Agree need to focus on the threat model - haven't seen raised how to deal with an active attacker who isn't planning to forge a response Mic: Ralf Weber: If we protect the wire, we don't solve the problem entirely - need also to look at the resolvers themselves. need to make sure we look at what we want to solve. Mic: John Klensin: Argue against moving too quickly to solutions that are currently popular - e.g. encryption everywhere. E.g. look at resolvers at boundaries of local networks rather than in ISPs big server farm. Unclear if this will solve the problem - need to back up a bit - but don't assume that encryption is the solution - need really to properly define 'the problem' Mic: Phillip Halam Baker : +1 to John. If don't look at architecture and who you get your resolution from first, then you're failing. Need to make choices about trusting resolvers. Not just encryption - also need authenticity. DNSSEC isn't fully deployed already - probably won't be in 10 years... if going to do this, then should spend the extra to do the auth as well Mic: Antoin Verschuren: Don't believe that just securing the wire and not all the boxes in the middle is enough. Suppose can get privacy end-end client - server for DNS protocol. Thinks this will clutter the DNS service. Thinks this will lead to giant DNS servers in order to ensure privacy. Thinks this is bad. Mic: Joel Jaeggli: Doesn't think there's any danger of us doing anything too quickly. Can we use the momentum we have to sketch it out pretty well - don't have to solve the problems today. Tim: Already have some docs that will help us along (Dan etc..) Tim: Don't want a requirements doc, but do want to capture the big requirements. Also need to understand that DNS needs to work before we tack on the privacy pieces - it's not an application. Suz: Call of adoption of the problem statement - as a reasonable starting place - Bit of hum Suz: Call of adoption of the problem statement - off base - Bit of hum Suz: Non-problem? - No hum Mic: John Klensin: Not specific enough to go forward - risk that we don't get the problem well-enough defined Mic: Dan York: while we can adopt this document for a place to start, I don't think we're clear on the problem yet Mic: Andrew Sullivan: : One of the things to protect against is being sniffed on the wire; other people thought it was the resolvers. Scope issue? Mic: Peter Koch: List of items - deterine which should be progressed here - and some maybe elsewhere. BUT don't yet have a valid thread model Mic: Jelte Jansen: We don't get know what the problem(s) are. It's not just one problem Mic: Brian Dickson: Look at a bingo table - rows and columns - problems and solutions. Need to look at what threat models potential solutions address; maybe break into a few sub-sections (possible *ACTION*: look at creating bingo table) Tim: Do 'here's what works for these situations' and then move on Mic: Brian Dickson: Systematic eval of good/bad points of solutions by ... doing this Tim: Is there enough of a problem statement for its own working group? Doesn't have a sense that we have this yet. Not structured enough to give ADs guidance on this Mic: Dan York: Absolutely right - need to scope this out. Two (potentially three) diff problems/avenues before we know if this belongs in DNSOP or somewhere else. Mic: Jon Dickinson: Could talk ourselves out of doing anything - should do more and talk less!! Mic: Olafur Gudmundsson: Multiple problems - some easy, some hard. May want to prioritise the low-hanging fruit - e.g. the long query names - is a no-op - write an RFC Mic: Warren Kumari: don't think WG - can't figure out the charter. Could have another place to discuss - mailing list? Tim: DNSE mailing list? *ACTION* Mic: Peter Koch: Share concern on solutions on quick win/no brainers. Qname trunction is attractive, but need to do proper research first. Same for other psaudo-quick wins Mic: Stephen Farrel : There are some HARD issues too - but doesn't think that the problem is not clear Mic: Stephane Bortzmeyer: Not sure that the problem is a non-problem. Would it help if the privacy problem statement was written up for review? Not room for a lot of discussion re some of the facts - e.g. that the auth servers see the full qname. Maybe a more noteful document - e.g. DNS Privacy Review. Document the privacy properties of the DNS - would it help? Mic: Matthijs Mekking: Yes, many problems/issues. Document is already there. Tackle them one by one. Don't overthink them. Step by step Mic: Antoin Verschuren : Violently disagree - why tackle the low-hanging fruit? Why do we want to do this? The data has economic value. If we encrypt the wire and not the resolvers, then the resolvers hold valuable data - they will have financial disinsentive to implement protection. Mic: Phillip Halam Baker: There is a pathology in WGs. We have a solution, but can't propose that until we have requirements - so have to write those first (narrow enough to fit the solution. Rush this through (the 'scope' phase) and we end up with someone's half-baked idea with 2-3 years of trying to make this work. Don't measure the solution against the scope - instead, look at how complex it is, and what it provides/solves Mic: L. Aaron Kaplan: when make list of privacy issues - need not just x&y - also need to add practical, other considerations - it's more complicated, needs more structured discussion. (will help with comments) Mic: Dan York: Responds to Stephane. Have multiple problems and people who would like to work on different parts/solutions. As a group, to get direction, have several pieces, and trying to figure out: Which problems do we want to work on AND who wants to work on each Mic: Ted Hardie: In danger of getting out the foot gun and loading it very carefully. First principles. IETF has made decision that we are going to worry about confidentiality. Is going to be working its way through all of our WGs (in addition to other goals). Trying to establish confidentiality on the wire as part 1. Working through the first principles will take us to the second step. Mic: Linus Nordberg: I've heard we need to fix this, in agreement that let's not be stupid Mic: Stephen Farrell: don't need to teach ourselves how to code again Mic: Brian Dickson: Holistic solution - maybe we don't just look at the individual pieces - big brainstorm? Tim: General sense is more work to do. - Get another mailing list set up (don't interrupt DNSOP flow) - Mailing list about DNS privacy Mic: Moved this to tonight to avoid conflicts - big thankyou Formal adoption, anointing of reviewers Session 2: Full DNSOP Meeting Location: Hilton Metropole, Sovereign Date: Friday, 7 March 2014 Time: 0900-1130 GMT 0) Introduction 1) Administrivia, Blue Sheets, etc. (10min) Overview of meeting structure (chairs) 2) Status Updates (35 minutes) (Business we need to move along) 2.1) DNSSEC Key Exchanges, Hardaker, Kumari, et. al (10 min) draft-ietf-dnsop-child-syncronization draft-ietf-dnsop-delegation-trust-maintainance Followup: Working Group Last Call? Tim: Both the above adopted and shaken out. Any vigorous objections; any final comments? (none) Mic: Dan York: clarify which slideset.. (the AS112 seems not to be on the site - will be sorted. Fixed) Mic: Mark Andrews: before AS112 - meta issue on how we proceeed - room to adopt another one (his) Mic: Wes Hardaker : The three drafts don't conflict. Is the market the deciding factor? Mic: Andrew Sullivan: DNSOP has nasty history of revisiting the same decisions over and over again - why are we revisiting this again - just move on and publish! Tim: in agreement Mic: Paul: We did this in Vancounver - there were hums to adopt etc.. Re Mark's input - why are we responding to this now? (Tim: Mark's draft wasn't brought up in Vancouver - it got short shrift - needs some more exposure - don't want to stop the other one for this - but need to give this one some space Mic: Dan York: Wanted to add another tool to our toolbox 2.2) AS112 updates, Abley (10 min) draft-ietf-dnsop-as112-dname draft-jabley-dnsop-rfc6304bis Followup: Next Steps? *Reviewers Needed* Joe Abley: we know about this. Have it already. Is inflexible. Think DNAME is worth trying. Update the advice to operators (RFC6304). Support both old and new. Don't need new nodes to do this. Two styles. DNAME draft has some speculative advice to IANA, not sure if it would work. Got informal advice and made some changes - informal view is that rev 2 will work for IANA. 6304bis also needs adoption. Last call both? ?? Has anyone read 6304bis? (smatter of hands) Adopt? (medium hum for (all asleep?) none against) ?? AS112 ready to move forward? (good hum) ?? Needs to go back to another edit cycle? (no hum) (*ACTION* Send out email on both drafts) Mic: Warren Kumari: Go into a bundle, or deal with both together? Mic: Andrew Sullivan: They cross-reference each other - need to do them together or they'll stall on the other one Mic: Joel Jaggli: Can't have one taking eons. Doesn't think there will be any consideration of one without the other... (all seem to be in agreement) 2.2a) Updating Parent Zones, Andrews (5 min) draft-andrews-dnsop-update-parent-zones Followup: does the WG adopt? Tim/Mark: Spot of discussion about updating slides post-Vancouver. Mark Andrews: Have whole pile of things above and beyond updating DS records. Need process that works not just with RRs but also signed and unsigned. Intends to have solution that works for all possible cases (operationally, e.g. with DS records or keys). Has been told plenty of times that update can't work with RRR model - so set out to prove it could. <> Mic: (unknown): Have you considered using asymptotic crypt - if registry gets compromised all keys have to be changed. Mark: Nothing precludes using SIG0. Isn't in the draft, could be done, could be worked out. Mic: Paul Hofmann: Draft does two things - describes how RRR works with this & is an update to include discover via SRV records where to send the updates. Mark: Just slightly different from using SOA Mic: Paul H: Nothing needed in the draft bar these two updates - nice to have, but don't need to consider the rest - it's just descriptive and not necessarily an alternate update method. Mark: Part of the scraping stuff is how the tools update; what the registrar needs to do. This is a push model - really want a single well-defined packet format going there. Paul: Then don't want to be telling the registrars/registries how to operate. Should say 'single' format. Mark: Big disagree because then clients have to have many formats/tools Mic: Wes Hardaker: Thanks to Mark. Question - where would the SRV record be located for ietf.org? Mark: registrar tells registry where this is; registry updates the record. Mark << details of record format>>. Mic: Andrew Sullivan: Doesn't especially care if we publish or not - thinks it will sink anyway because no registries/registrars will implement.But the labels with underscores make him itchy (he hates them). Sees them creeping in all over the show for in-band signalling. (Mark: to remove them from the LDH). Understands 'why', but deplores the blowing apart of the domain name - part is name, part is signalling. Is OK-ish in dnsd - is used for human consumption - but here is machine-machine. Accepts it will work - but hates it. Mark: tcp Is needed Mic: (unknown): Would be happy to remove everything that is about the registrar - won't be used - just keep the protocol stuff Mark: As a nameserver developer, I need to know how to update my parent. Need to know where to do XML, EPP, everything else. Would rather work machine-machine than scraping a web form. nsupdate was designed to be machine-machine. Doesn't want the registrar/registry to make decisions for me - wants to force their hand Tim: We can't force... Mic: Olaf: Need to know where registries live to be able to do this. Is this another requirement to be fed into dbound? Mark: Mistake - know the zone you're updating, can work out the parent from that. Mic: Tony Finch: One advantage is that you can put the SRV record in a subzone of the parent (easier to manage). Mark ... Mic: Warren Kumari: Is clear that technically this will work. But has concerns about user/usability. Users have to keep track of credentials. Users not clever enough - will shoot themselves int the foot? Mark: Expects credentials written to named.conf, tools to manage this. Doesn't think will be a real problem with users. Users deal with passwords all the time - this is one they need to write down. Use just for this. Mic: Warren: expect the users to be able to drive nsupdate? Mark: No - expect this to be built into tools Tim: Technically correct - room feels that this is pointless though. Should we ask the registrars what they think? Has asked Warren to ask at ICANN. Mark: refers to slide 'Server Side - Registrar'. Is sort of thing that *he* would write, is trivial Tim: Just because it's easy... Mic: Alex Mayerhoffer: Likes the concept of updating. Doesn't like the way the discovery is being done. Have we seen new protocol RDAP - maintain this there? Mark: Reason for doing this way, is designed to work with nameservers that are not RRR-enabled Andrew Sullivan: As a registrar (DYN) - we would be very unlikely to use this - the other proposals much more attractive. Mark: Doesn't Dyn already take TSIG-signed updates? Andrew S: Is a different question Tim: ... take this offline... Tim: Need to follow up on some old drafts - may be quite old and out of forefront of people's minds now - might need refreshing? 2.3) DNS Referral Response Size Issues (5 min) draft-ietf-dnsop-respsize Followup: Open Questions need answering *Reviewers Needed* Basically done, misses some impact etc.. Useful advice and probably ready to have some folks read over it. Suz: Authors ready to revise and revive it. Wanted people to read it - take to the mailing list - please read it with fresh eyes. Some of the conditions assumed about a typical referral response may now by outdated. Is good advice to have out there - would be good to get it out there. Looking for a couple of volunteers for reviews in the future. Volunteers: Andrew Sullivan; Peter and Stephane. (*ACTION* Followup on review) Mic: Stephane B: This is a really useful work and it really should be published. Per mailing list, is still too sloppy around truncation and optimization and needs work - but isn't ready. Suz: Have imposed on authors enough - need others involved. 2.4) Initializing a DNS Resolver with Priming Queries, Koch (5) draft-ietf-dnsop-resolver-priming Followup: Address open questions? *Reviewers Needed* Peter Koch: Document was revived with some refs updates. Mostly positive or just neutral feedback. How many have read -04 rev (almost 10 people) Three issues - less about the priming part, more about the content and the priming response. 1. Absent EDNS0 in the priming query (or with small size) currently the root servers have different behaviour in filling 512 bytes. For some they will deliver a complete A and AAAA for each server, but can't deliver all of the root servers. 2. TTLs - currently there is a TTL on the RRset in the root zone, and then another TTL in root-servers.net. Which one prevails depends on the root server implementation 3. Currently IANA oconsiderations - Should the TTLs of the respecting A/AAAA and NS records be aligned? Will start this going on the mailing list - looking for comments. Come to conclusion soon. Mic: Paul Hoffman: Talking to firewall vendors - would love definitive advice on how to do this (built-in nameservers). Also - drop 3 issue entirely - rip it out. Volunteers: Both Pauls volunteer to review/revise Tim: One piece of old news - Peter et. al's key-timing draft - is already expired. There was another draft too on its heels that didn't follow through. Does Anyone remember this discussion (very very tiny show of hands!) Tim: People scared off because of the maths in there? Think the entire discussion needs to be restarted. The original was more complicated, but proposal is to create a new doc that covers the major use cases. Yes, there are some edge cases - but maybe start a new doc for those esoteric cases? Mic: Peter Koch: Revive, AND create new doc?? Decision some time ago had been to move the first doc and then start on second. Reason first didn't move is his (Peter K's) fault. But why not second doc? Mic: Matthijs Meking: Key timing draft a couple of years ago - is very good. His DNSSEC team has also been working on similar - has written down all the various cases. While doing that had some comments and brought them to the WG. Consensus then was ship the document that was already progressed so far - intention was to ship. Second doc was waiting on first doc shipping (?). But now it's two years down the line - perhaps we have new thoughts on it. New thoughts (Dickinson - new draft?) - update the key states etc. Tim: Doesn't think we can take the old document and push it through - things have changed on the Internet in the last two years. There is agreement to slice up/progress the original doc. Matthijs: Only covers about 80% of the use cases Mic: Stephen Morris: Agrees with Matthias - needs to be reviewed. Also is a bit on the complicated side, and given the time since it was last looked at - potentially simplify and split Mic: Tony Finch: Really likes this document - the details have been really helpful. Would be disappointed with the thorough analysis wasn't published. Mic: Andrew Sullivan: Doesn't care which of the two is published. This info/practice is a big gaping wound in the advice on running timings of key management - spends a lot of time advising people what to do - but we NEED this. Mic: Joe Abley: Nobody expects people to manage keys manually with a stopwatch. What he likes is that the doc provides algorithms for people writing tools. World would be better place with tools that follow this advice. Tim: So.. feeling is that there's nothing in there that is out of date? Mic: Paul Hoffman: Has no idea if it's out of date - is too complicated for him to read. But, taking time to get it right before getting it out would be wrong - need to get it out there, and then maybe do a -bis in a year's time. Mic: Andrew Sullivan: just get it out there Mic: Matthijs Mekking: Get it ready for review before next IETF Tim: Will get it updated and sent to list by end of next week (*ACTION*) 3) New Business Tim: Now into the 'freestyle' part of the discussion... 3.2) Special Names (30 min) Suz: DNS namespace is so good, that it's being used for other things... but having multiple processes for deciding which names work where (at least three of them) is hurting. Trying to do here is go over some topic, have high level discussion, set some direction. Suz: NOT doing - specifics of current requests. Can't say 'don't mention them' - but want to focus primarily on whether or not we want to tackle this. Unlikely to take formal action as a result. Suz: NOT making special names a political issue. Care about interoperability. Care about operations (and coexisting multiple scopes working). Suz: Hoping to have offended someone by now... (several 'yes' from the room!) Suz: Also not wanting to fight over history. Now is what matters. Suz: Below - docs represent several use cases and IESG have asked this WG for advice. Mic: Paul Hoffman: What do IESG want advice *on*? What do they want from us? Suz: IESG in the room Mic: Joal Jagli: Speaking as himself along. There is a fair amount of existential on 'we'. Worried about opening floodgates to lots of registrations. As an operator, things that create 'special cases' cause a lot of trouble, esp if he can't anticipate them. There are serious questions as to the breadth of the consensus in the Internet community (not just operation or IETF communities) as to our ability to operate the Internet namespace today. Those are the concerns he understands from the IESG. Not rush to take decision, but some of these are pressing - existence of active drafts is proof of this. They won't 'go away' - we need to deal with them. Mic: John Klensin: Follow up on Joel and a question. Given that there are multiple organisations claiming the auth to assign names, do we have to have a policy on what happens if one of them reserves a name and another organisation challenges that? Suz: Don't know, but sounds like the sort of thing we should be considering Mic: Ralph Droms: Not sure understood - please restate Mic: John K: How to resolve conflicts. Suz: have drafts not just new but revising existing standards. Start with some framing questions. What can we help with? Do we try to suggest modifications to existing (RFC 6761) or get more radical? How can we start to answer some of these questions such as John asked. Chairs’ summary (5 min) Discussion: DNSOP role existing requests/RFC 6761 process: draft-grothoff-iesg-special-use-p2p-names draft-chapin-additional-reserved-tlds new drafts: draft-wkumari-dnsop-alt-tld Warren: Made the slides during DNSE yesterday. What's the problem? There are things called 'pseudo TLDs' - things in the RHS of label that are not DNS names People like naming things. But they're not all DNS names. Get around this with browser plugins that intercept and look up elsewhere, not in DNS. Why? Often it's privacy/confidentiality. Do these actually really exist? There are at least 5 mentioned in the draft. Likely a bunch more coming along (perhaps as result of the new gtlds). Shouldn't be an issue, EXCEPT that these names *do* like. Some of these names are hitting the DNS space - collisions occur. Document - hopes to provide advice to developers. Isn't in there at the mo - but Joe Abley thinks would be good. First suggestion - don't do that - put the names genuinely under DNS Second suggestion - then don't pick a name and squat - choose a name under .alt (will make it possible for local resolvers to have a locally-defined zone). Could also even handle this via the AS112 servers? Why: Provide place to do this 'nicely' Some might use it; some won't. It does at least provide IESG (or whoever) some push-back - can say 'but we told you, don't do that, stick it under .alt'. Also clarifies RFC6761. Open question: IF we do this, do we provide a registry-type thing where people who want to use a name under .alt can go somewhere to 'get' and record it? Suz: While we're not doing any comprehensive survey of thoughts - can we first have clarifying questions, then have Olafur up, then open discussion after. Mic: John Klensin: Observationally, there have been two types of names like this. 1) name that looks like DNS but there is no expectation of using DNS to resolve it. 2) DNS name that doesn't get resolved in the normal DNS route, but which gets resolved using DNS mechanisms - so suggestion is to push it down a level. 3) names that people want to hide? Warren: Not sure quite get the distinction. Some are resolved using DNS-type mechanisms. Some are resolved using hash-type techniques. .alt is not intended to help resolve - just somewhere to put these when DNS sees them. Mic: Paul Hoffman: Why do we need any kind of registry at all? Can't the user do due diligence? IF they're outside of DNS, why does there need to be a registry at all? Warren: Doesn't need to be one - purely so that people wanting to use in their own non-DNS context can.. Suz: Can we help operators via this stuff... eg. help avoid name collisions. Mic: Antoin Verschuren : Reason why some want to do this is privacy. Isn't adding a special TLD exposing these? Warren: Some of these will leak/be logged anyway. One of the properties of adding this (.alt) could be to keep the exposure as local as possible (to resolver). Also stub resolvers could just be written to drop these anyway. Mic: David Conrad: Love the theory have a multitude of disjoint namespaces. But have applications that understand just one (the DNS) namespace. If look at L-root stats, of the two TLDs queries, two are not registered and .local gets ~10K qps, and .home just a few less than that. Isn't offended by use of term 'registry' (ex IANA himself). Warren: Trying not to inflame ICANN by use of terminology Mic: Andrew Sullivan: Talking about the DNS name space and dealing with things that look like DNS and aren't. This is why .local introduced in the first place. Suz: Potential for collisions is one of the reasons for doing this. But not the only. Mic: Jelte Jansen: Add use of label as a protocol identifier to the list of things to deal with Mic: Jonne Soininen: Using a registry one way of going forward. Do we expect that names will be unique - or could there be multiples? Warren: Currently people are just squatting on names - and 'seeing' whether or not they're unique. If there *is* a registry, then doesn't know whether unique matters or not - but plenty of letters - just pick another name? Mic: Jonne Soininen: If we do have a register - then it will need authority and structure Mic: Daniel Migault: Not saying is a perfect solution but it helps the DNS architecture and collisions, especially for those with genuine names (versus squatters). It helps devloppers as well to identify names that are not DNS. Mic: Olaf Kolkman: As response to Jelte - if it smells and looks like a domain name, but is useless as a name... problems. Colleague in Houston said that there could also be IDN issues on this - had those been considered? Warren: Would have liked to be able to choose a name/label that is the same everywhere (e.g. hyphen), but not possible (?) picked on .alt draft-ogud-appsawg-multiple-namespaces Olafur: What is a Domain Name? For many, trad DNS name... Others take it further (name not in general Internet). When people want to do new things, we fix it after the fact. Not good. Implications of meta-TLDs that aren't in DNS is that those names WILL leak, except when underlying libs or resolvers know better. This could be an ongoing process of figuring out what to do with the next meta.. If we keep patching, the libs and resolver get increasingly complicated. If it breaks, people go somewhere else. Also, is allowing meta-TLDs potentially regarded as revenue theft from ICANN? Why aren't we using more/diff classes. Some suggested config in the URI - better idea - add a namespace ID - so that resolver libs can handle it differently. Will be harder/longer to deploy. Could e.g. use different DNS classes. But when implemented on the hostm should not leak: Mic: Wes Hardaker: Good news is that when listening to Warren, was thinking of the ways his slides were wrong. Bad news, now seeing why Olafur's slides are wrong. But, names are used in lots of places that aren't URIs. Likes idea of .alt. Should there be a registry that we run for .alt? We already have a registry - why would we want to do it again? Just declare it free-form. Re applications using protocols for diff URIs - need something documented/specific. Olafur: One requirement kept in mind: Would like to be able to express names that are not US ASCII. But having the space identifier, can represent/handle names that are in different representations. Mic: Paul Hoffman: Clarifying that the extension can be used to indicate URI as well as namespace class. Mic: Richard Barnes: From the application layer (!) Have had discussions about 'what is a name'. From his perspective, a name is a set of dot-separared labels that he has to resolve. Has set of techniques. Which to use. How to prevent non-DNS leaking into DNS. And if he doesn't know and uses DNS anyway, how to have it fail quickly? (*ed note: Think this is important*). Suz: An application guy willing to talk to DNS people - applaud and sign him up! Mic: Warren: Will need work on applications - e.g. changing separators and so on. Long term solution Mic: Richard Barnes: Reason people use domain-name-like people is that people like the syntax Mic: Dan York: Will be challenging to get this deployed Olafur: Recognises that it's not easy - but is it *worth* it? Dan Y: Yes, is valuable to do this. Might not be 'the way', but need to consider this. Also need to bring in more people like Richard Barnes who work in the application arena. Need to get much broader insight into how these will be use. Olafur: his goal is to protect the DNS from this traffic. Mic: Joe Abley: Isn't adding the new name space identifier going to cause even more leaks. Have to change all the software in the world to get this implemented - not sure we're even buying ourselves anything with this. Mic: Peter Koch: Would these new options/classes etc.. go into a registry somewhere? Which IANA? New protocol? Mic: John Klensin: Have resp for protocol that is resposible for LDH rule, which is why this works. As an applications guy, knows something: Observation 1: If we change the rules, we change the rules in other places. If we have these names visible, then people will want to own them. Need to be careful that our solutions to this problem don't become problems somewhere else. 2: If we think that deploying different resolvers is hard, then think about new restrictions/rules for every new device that is https enabled (light bulbs?) Why not have every new name contain two consecutive two ".." in the label. We know to make this work, the crazies won't. Mic: Paul Mockapetris: The IEEE is sponsoring something on Internet history. And people wanting these non-DNS names - they're not going to follow any rulse that we set up - they're going to do what they want to. We can't make them comply. What *we* need to do is to defend the existence of the single name space. We can defend the root - and then give them a place to do their own thing. They are adversaries. We need to think about how we can keep them at bay - that's all. Doesn't matter if it's .alt, or .not-dns. Then leave them to it. And we might not think that we have to, but we *will* need a registry that someone runs: Mic: John Levine (apps guy): Would be useful to have something like .alt to mitigate the damage. Don't think it's worth putting effort into a lot more complex adoption - will not be widely used. Mic: Warren Kumari: Could be useful to look at the other people using these names as adversaries. One reason for the draft is to provide a mechanism for 'push back'. "We told you to do this..." Olafur: We can't force people to comply with the rules, but we need to define the rules. If we don't have rules at all then... 6) New Business 6.1) GetDNS API Release, Wiley (5 min) Glen Wiley: Covered also in App area. Intro - works in Verisign name space. <> Try to define a new API to get access to different/new aspects of the DNS. Opensource. Chose BSD new licence to be least-encumbered. Spec has creative commons licence. Relying on libunbound to do the heavy lifting. First beta release in Feb. Some other dependencies (so that it works with libunbound) Avail on FreeBSD ports and other platforms. Can run both as a stub or a recursive resolver - full DNSSEC validation capability. Would like more community involvement. Mic: Olaf Kolkmann: Not the usual audience for this type of thing - but major use of an API like this one might have operational impact, which is why he's looking for freedback from this group, such as on default settings etc. Therefore would like to request that this WG looks at and provides feedback. Glen: Eg. being able to tell the API that you want to use TCP 6.2) Passive DNS format, Kaplan (10 min) draft-dulaunoy-kaplan-passive-dns-cof Followup: Aaron Kaplan: <> Capture DNS Query replies at the resolver and store the answers in a database. Two ways to do this: pre-recursor passive DNS, store everything (Cisco technique). Strong privacy problems. Second (and original idea) from Florian - only store the public answers (less privacy concerns). Can look at historic data. Can do research. Was interesting look at what happened with DNS with the political issues in Egypt. Also interesting to see what the DNS namespace look like. There are already multiple implementations. Good to keep them under different/distributed control. Data is incomplete/localized - need exists to query multiple passive DNS databases - which implies consistency. There are ~implementations anyway that will ignore these standards. ?? Should we also specify the query format, not just the answer format (Vixie suggested this in another document) ?? Should the WG adopt this? 6.3) DNSSEC Validator Requirements, Migault (5 min) draft-mglt-dnsop-dnssec-validator-requirements Followup: 6.4) DNSSEC/DANE Roadblock Avoidance, Hardaker (5 min) draft-hardaker-dnsop-dnssec-roadblock-avoidance Followup: Wes Hardaker: Validation is not always possible (many reasons). What should the end resolver *do*? - Defines a set of tests (against neighbouring resolvers/network infrastructure). - Document options for what you (the resolver) can do when... - Next steps - gather other opinions/info from libs, applications, people etc. and then publish - Hand show - 10-15 have read it? ?? Who thinks we should adopt (good hum) ?? Who thinks it needs another revision (no hum) Tim: feels minor protocol maintenance OK to do in here (AD will be find with this). Here to frame the discussion. May do the work, but more likely send it somewhere else. Suz: Will put some notes out on the mailing list about what thinking: *ACTION* Tim: Will put out some notes (after giving people 3-4 days to get home). 7) After Meeting Reading 7.1) Optimizing DNS Authority Server Placement (5 min) currently no draft, slides in packet