DNSOP ===== Tim opens the meeting - Notes that Suzanne Woolf has her birthday today Note well is shown on the screen. Agenda review ------------- Will be a virtual interim meeting on 6167 issues List of documents is in the SVN, Paul Hoffman is tracking those. Please review documents if you volunteered! Thanks for the reviews. Client Subnet - Possible discuss whether to get a new code point in EDNS0 Cookies - ready for WGLC once issue between Mark and ? is clarified 5966bis - not everybody happy, but it's the job of the chairs to clear discussions Stephane - QNAME minimization (15:25) ------------------------------------- Wants feedback about certain issues: - Negative Consequences - should we add more text around this (that less data is being collected)? - Should we hide the QTYPE or not? - - Keep optimizations - aggressive algorithm vs. lazy one (lazy one is underspecified!) - should we keep both algorithms? - Other possible optimizations - eg. treat root and TLDs in a special way? - Even necessary since resolver can optimize at will? Paul Hoffmann: Benefit is on privacy of people making queries - tradeoff is hence "less privacy vs. less data" Notes that "we" get the value of more data, rather than users. Stephane notes: lazy algorithm is fasters - slight advantage for user Matthjis: If the goal is to give more privacy for users, then we should keep the aggressive one ?: Agree with this - focus is on creating more privacy Alexander zouk (?) (Ukraine): Does is treat IDN domains as a special case? Are there any special optimizations? Stephane: Don't understand why it should be special Alexander: eg. left side email does not work. More broader than this draft Stephane: Currently no special considerations for IDN. We need more information Tim: conclusion seems that people choose privacy over more data. Some vocal agreement from the room. Tim: Continue discussion on list Suzanne: Got enough input? Stephane: Yes draft-ietf-dnsop-root-loopback (Paul Hoffman, 15:34) ---------------------------------------------------- Paul explains history of document - latest version -01 released in January Major change is we say "No, this is not a recommended practice - This is what you can do if you want to have that result". More text on failure cases. Is meant informational - some want it to be a BCP - probably "Best" doesn't apply? Some feedback about "can also be set up so that other devices locally can use it" - this will not go into the document. To be discussed: Informational vs Best Practice, and agree on any wording changes Geoff: Why instantiating two instances of resolvers? What was the design consideration Paul: Didn't want to say "use BIND" Warren: Stops DNSSEC validation when root is configured locally (Tim: Yadifa?) Bill Manning: Informational, certainly not BCP. Some downsides, please enumerate the caveats? Paul: Have that already, what are you missing? Please let the list know what you miss. Bill: Way to quarantaine the doc with a big red bar? Paul: Nope, not in new RFC format. And red is out of the question for color blindness Terminology (15:42) ------------------- We should document every term that is used in at least two slightly different ways. This doc is not going to change the standards definitions. Maybe publish it now, even if it's not complete - and update in eg. one years time Bill Manning: Make an IANA registry out of it? Paul: Hearing a lot of "no" even from the chairs Andrew Sullivan: Explicit No. Please look at this - if smth is controversial, remove them, publish it, and work on another revision. Tim: Chairs have discussed, would adopt it and immediately do WGLC. How to Refuse Queries (15:49) ----------------------------- Olafur: There are times when we do not want to answer a query - no value, privacy, security, extra work Desire to do that in an uniform way Options: - Drop query (today) - sometimes NOERROR, TC bit set - but what to do on TCP - REFUSED - NOTIMP - NOERROR, empty - NOERROR, ANS=1, RTYPE=NULL - or new RTYPE Suzanne: We're here for documentation operational practices, but go ahead Paul Wouters: Doesn't that break DNSSEC Evan Hunter: Reason i objected from no data would be indistinguishable from empty non-terminal Paul Hoffman: Is not ready for adoption. Motivation section is wrong - last two should actually be signed, becuase otherwise would be an unsigned entry in a signed zone. World has very vew online signers. Prepoluation would be fine Evan: Last two things only possible in unsigned zones. If signed, respond with the covering NSEC/NSEC3 record Ralf: Last one is the way to go Peter: Not sure the problem is well specified - variety of problems - boundary of policy and protocol? Make motivation much clearer Not convinced it's the IETFs role to tip off on policy decisions. Doesn't like the "lying" on the data Joe Abley: Happens today that people block QTYPES. Document is here to explain what they should do Peter: Document how to "do brokenness"? "Standardizing Drunk Driving on the Internet" - recommended reasing Marcos: according to 1035, it should be "REFUSED" Ed Lewis: Seen services that respond to A only. Question is - do you go to a different server in case of REFUSED or NOTIMP? eg. AXFR - go to a different server. What is the expected action of the receiver in those cases? We want to say "Don't even try".. Olafur: Most clients try another server when they don'T get RCODE0 or RCODE3 Steward Cheshire: Agree with Peter, understanding motivation is helpful. My vote is REFUSED. RTYPE=null is wrong, means "no type", not "no content" Mark: Thought about this for years. Currently return NOTIMP - this is a hard question, and no good answer. New type that says "all servers for this name will refuse it, and preferrably cached, together with SOA" - similar to NXDOMAIN. Joe: What happens when an unknown RCODE is received? Mark: Will return a SERVFAIL. We want something cache-able, with TTL. Ralf: New RCODE not in our charter, document what is operational practice. Document what we and a number of large players are thinking. Suzanne: Got a call for adoption already on list - this will be considered additional input Olafur: We are willing to write down what the group thinks is the right content Matthjis: Minimal IXFR (MIXFR) - 16:10 -------------------------------------- History: AXFR -> IXFR - with DNSSEC IXFR is not so small anymore. Draft contains proposals to make IXFRs smaller. Another drawback is "lots of connections" - do multiple zones over one TCP connection. Proposal 1: MIXFR adds DNSSEC logic to IXFR, implicit RRSIG deletion, Proposal #2 - multiplexed zone transfer protocol Alternatives: Packet compression, RRSIGs don't compress well - rsync: No discovery mechanism.. Tim: Could create a narrowly focused WG if there is interest in this. Quick hum: Is is applicable to the WG Matthjis: Rather ask whether people think it's useful Hum: More hums on that this is useful Hum whether in charter: more hums on that Tim: Ok, we will issue a call for adoption on list. Andrew Sullivan: Think that this is in charter, but notes that WG cannot decide whether we should spin up another WG RFC6761 & special names (16:18) ------------------------------- Suzanne Woolf: How can we engage in this successfully without having a WG alive - Will consider a virtual interim meeting on 6761 .onion has time concern draft-cahpin was wating to recharter .alt is an attempt at a meta-solution trying to develop the conversation for the interim meeting. * Richard Barnes - .onion Onion names label hidden Tor services (since 2004) - [hash-of-public-key].onion - ~30k names, traffic to them about 1% of bandwidth (facebookcorewwwi.onion - hash mining example...) Drawing from ".test" Users and applications shouldn't treat it differently, but treated differently by nameservers .onion is special that it cannot be resolved in the DNS Every rfc6761 criteria applies for .onion timeliness: eg. HTTPS certificates not available currently.. Various other protocol options / projects (email, mesaging, SOCKS compatible services) HTTP over Tor with .onion is vulnerable - handful of sites have managed to get certificates through "local names" exception - not sustainable - but because as of Oct 1st certs need to be revoked (name collision..) Steward Cheshire: Think this is appropriate use. "Shares the address bar" and hence this is a perfect use case for 6761 Mark McFadden - .mail, .home, .corp (16:33) ----------------------------------- think the draft complies with 6761 - chapin-additional-tlds. Strings are "mail", "home", "corp" - came out of "name collision" research. No disagreement that these names should be reserved. Lots of research that they consitute a problem. Warren Kumari - .alt (16:38) ---------------------------------------- Explains ICANN new gTLD program Lots of policy issues - IETF does definitely not want to become an ICANN meeting. Currently ~40 requests unter 6761 - many for names in non-DNS context TLDs are not a place for experiments .alt: proposes that .alt always returns NXDOMAIN, can be a space for experiments or permanent homes. Peter Koch: "people like TLDs", and you are giving them a 2nd-level domain Warren: No, not neccessarily a structure under .alt Peter: Acceptance test? Warren: Yes, some .onion people said they would move.. Brian Dickson: AS112... should 6761 imply AS112? Should dnsop recommend that some names are delegated as secured DNAMES to AS112? Warren: Saying that recursos should drop it, and AS112 sounds like a good solution Brian: Would delegation of .onion to AS112 help to meet the "deadline" before Oct 1? Would the IAB agree? Richard: Either way it would require IETF action John Levine: 30 years ago we did the same for usenet.. and it worked.. ??, Microsoft: Did .pnp-name (?).net, and that worked.. ??: Think is a good idea, but doesn't stop adding new "TLD style" use of special name Warren: Would be nice to have something to defer users to, and ask them to come back once they have millions of users Richard Barnes: Generally a fine idea, completely unmanaged... better some minimal management? Warren: Advantage of special name is that confidential names do not flow up to the root zone. Steward Cheshire: Special names vs Special top Level Names - spirit of 6761 is not "top level". onion.net does not help, becuase we still want some "specialness" (treatment at recursors, etc). Support .alt as a playground and knowin in experiments that it is already blackholed survey of DNS caching recursors in China (16:54) ------------------------------------------------ Wei Wang Traditionally 3 big ISPs doing the recursive DNS, now also other companies (eg. Alibaba) Change is that data is being prefetched Backup-Server "caches" top-n and most important zones beyond TTL eg. Alibaba - peak 600k queries per second 114DNS (114.114.114.114) Negative impact on DNS ecosystem: Reduces query impact on auth servers Conclusion: role of recursive server is becoming more important Paul Hoffman: Would love to find out how often the emergency backup servers are being used. Wei: Once a year, maybe - in case of DNS traffic attack Ralf: Have you measured that there is a significant advantage for users? Wei: no, would need measurement Ralf: Random names? Can't cache all... Wei: over 100Million NS records cached.. Ralf: NS records not the problem? Random names fujiwara-dnso-nsec-aggressiveuse (17:05) ---------------------------------------- K. Fujiware from JPRS "NSEC/NSEC3 agressive negative caching" - implemented in Unbound since 0.4. Also in the DLV validator since 1.1 Patch was sent to unbound Suzanne: Complex draft - we shall see more discussion on the list John Levine: Have on concrete application for which this will be a big win EDNS compliance (Mark Andrews, 17:11) ------------------------------------- Motivation: Deployed experimental version of DNS cookies in BIND 9.10 - various zones failed because of EDNS implementation issues Various queries to servers in parallel, typical faults listed in the slides - "fully compliant" around 60% "Better quality" at TLD servers, degenerationg towards "less important" services (Alexa bottom 1000) TLDs already involved - SWITCH and .ie - data and reports on the web sites Suzanne: Terrific data, more on the list or bar Tim closes the meeting, pleasereach out for us if you need anything else