dnsop minutes IETF 83 2012-03-30 (Friday) 11:20 CEST (UTC+2) Chairs: - Peter Koch - Stephen Morris Agenda: http://www.ietf.org/proceedings/83/agenda/agenda-83-dnsop.txt Actions: Administrivia: http://www.ietf.org/proceedings/83/slides/slides-83-dnsop-3.pdf Status Update: RFC 4641bis * Olaf Kolkman would like a timeline for this. Post-processing steps have taken most of a year. * Peter Koch expects it within 2 weeks. DNS framework * Stephen Morris reports substantially complete. Write-up to go to AD within 2 weeks. draft-weil-shared-transition-space-request * Not dnsop document. ===================================================================== Reverse DNS Naming Convention for CIDR Address Blocks draft-gersch-dnsop-revdns-cidr-01 http://www.ietf.org/proceedings/83/slides/slides-83-dnsop-0.pdf Joe Gersch Presented by Dan Massey About 20 people have read draft. Ondrej Sury CZNIC: - Misses the ability to put information about hosts too. Feels incomplete. Dan: - You can put this in. Ondrej: - Now you will have the new prefixes with 'm', and you still have to use CNAME for the hosts? Does not make sense. Identifying hosts should be the same. Eric Osterweil: - You'd still just use PTR records in the regular place for hosts. It's still the same today. Ondrej: - I think you should do it. Rob Austein: - There are times with 2 ways to name the same object, this is described as a feature. Also you are doing things with zone cuts adding semantic content to the resolver. Dan: - Would love to talk offline. This is strictly a naming convention, there may not even be zone cuts! That's a different document. - Alternative naming... benefit to putting things on an octet boundary in 2 ways? That is the question. Rob: - Do you believe that is a feature? Dan: - I do. Wes Hardaker: - I do think this would be a good thing to do. We may not know all of the use cases but standarizing how we encode this is good. I had a hard time reading the documents - it is non-trivial. What is missing is how to algorithmically find the parent when you are querying for a child sent that is non-existent. Murry Kucherawy: - Very interested in this work, but more attention needed to abuse implications. Ed Lewis: - We're skipping use cases but I think we need to talk about that. We have at least 1 or 2 other ways to do this. I'm not sure what the use of querying for prefix is. Dan: - Imagine I want to associate data with a prefix. How do I do that? Ed: - There are many ways to do this. The problem I'm seeing is why is this better than what we have existing? We have lots of these. For example the CNAME trick. Dan: - Not for prefixes. The author of the document says it does not apply to prefixes. Kurtis Lindqvist: - I think there is a use case for this... reverse DNS! - I think having different ways to map is not a feature. - I do not think we have good ways of doing this now. Sam Weiler: - This is good work. There may be use cases other than routing. However I think this should not be separated from the current use cases. The use case is driving the name space so separating them may not be the answer. Dan: - There is more than one use case, so having an application-agnostic way of doing this is a good thing. Sam: - Ed is right, we have had previous proposals. They do not work for your use case, so how do we know that your solution will work for other use cases? Dan: - This is about naming the prefix, not assigning anything. Hum on problem to be solved? - Silence for the "no", and interest from "yes" Hum: is problem well understood? - Roughly split. Hum for work for this working group? - Almost silence against Olaf Kolkman: - First well-known rule for applications in DNS. Not quite sure if this needs to happen in a working group. Peter: - We are not going to ask for adoption of this document, we are trying to see if we want to explore the problem space. ===================================================================== Considerations for TTL values for DNS infrastructure record types ---- Improving DNS Service Availability by Using Long TTL Values draft-pappas-dnsop-long-ttl-04 http://www.ietf.org/proceedings/83/slides/slides-83-dnsop-5.pdf Eric Osterweil DNSSEC KSK rollover failure recovery practices draft-yoneya-dnssec-kskro-failure-recovery-00 http://www.ietf.org/proceedings/83/slides/slides-83-dnsop-1.pdf Yoshiro Yoneya General discussion - is the topic of TTL values something the WG is willing to work on? - do we see reasonable chance to achieve consensus? - what other aspects/demands do we need to take into account? 5 persons read the long TTL draft About 7 read the short TTL draft Different people! Ed Lewis: - Whenever we try to recommend a number in a field in a working group there is a fight about that. So lets make a discussion and be general. - Whenever you try to use one field for another things go bad. So use signature expiration rather than TTL. Keep the times in the right category. Rob Austein: - Alisha gave the same presentation 5 years ago. I didn't see any changes. New data? Eric: - There is new data. See the OARC presentation. Rob: - I'm sympathetic to the short TTL. If your TTL is too long you can't revoke the keys. Ondrej Sury: - I am also also for short TTLs, because long TTLs are very customer unfriendly. Ours is now 5 hours and we get complaints that this is too long. I think 3 to 7 days is just "no go". I think a reasonable time is in hours and not days, and we have to cope with that. Patrik Wallstrom: - For the SE zone we have 3 hours TTL. A few years ago we lowered the TTL for DNSSEC zones to 1 hour, and this has been very helpful. John Levine: - I see a lot of data bout TTLs published. Are there data from the cache behavior? Eric: - A number of caches do not respect long TTL. We simulated this. Eric: - This is good feedback. I am starting to think there are zones that are more highly-augmented at the top. As far as the structure of the DNS it does not change - static structure vs. availability. John: - I think it is dangerous to conclude things about the nature of a zone based on its distance from the root. Eric: - Top level domains have a little churn in their NS set, but this may not be true at the SLD. There is a trade off that may be more or less appropriate for some zones. Hum is there a problem to be solved? A bit more for yes than no. Hum is the problem well understood? Noise for both, number vs. volume difference. Hum is there work to do in the long run? Noise for both, one very loud against. Hum is there a chance to reach consensus? Not so much confidence in either, but non-confidence was stronger. Andrew Sullivan: - I don't know what the work is going to be, so I could not say if we can reach consensus. Peter: - Reverse mapping ended up being a tradeoff document and still did not get consensus. Andrew: - That started off as advice, and later people did not read revised documents. If we start as a considerations document there might be hope of consensus. Peter: - We don't have a straight way forward. So this is not the point in time to ask for adoption of either of these. Please add to the comments on the mailing list and lets see how we can get these competing documents overlaid. A.O.B. SPFBIS "amplification" side effects Ray Bellis: - Whois DNS Borat? Olaf Kolkman: - I wanted to point out that there is a draft at the IAB "draft-iab-dns-applications" that is worth reviewing. End of Session