----------------------------------------------------------------------------- D R A F T dnsop WG minutes for IETF 72, Dublin, IE ----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 72, Dublin Location: Citywest Hotel, Saggart, Co Dublin, IE; "Ballroom 1" Date: Tuesday, 29 July 2008 Time: 13:00 - 15:00 (UTC+1) Chairs: Rob Austein Peter Koch Minutes: Shane Kerr Jabber: xmpp:dnsop@jabber.ietf.org J-Scribe: Marcos Sanz, Joao Damas J-Script: http://jabber.ietf.org/logs/dnsop/2008-07-29.txt Audio: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch7-tue-noon.mp3 WG URL: http://www.dnsop.org Material: https://datatracker.ietf.org/meeting/72/materials.html Version: $Id: ietf72-minutes.txt,v 1.1 2008/08/29 18:57:16 pk Exp $ ----------------------------------------------------------------------------- 1) Administrivia [ 13:07 {audio 0:00:00} ] - Scribes, blue sheets - Mailing list now has TMDA in front of it, so posters not subscribed should expect a challenge to respond to - agenda bashing no changes - IETF guest day ----------------------------------------------------------------------------- 2) Status Update [ 13:10 {audio 0:00:00} ] - RFCs published - NONE - - Internet-Drafts in RFC Editor Queue - NONE - - I-Ds at the IESG draft-ietf-dnsop-reflectors-are-evil-05.txt All issues with reflectors-are-evil document resolved except one IESG comment. AD holding document because of comments from Paul Hoffman, but he is not aware of that and is happy with current version. Ron Bonica (area director) will call off DISCUSS. - I-Ds in or past WGLC draft-ietf-dnsop-default-local-zones-06.txt Waiting for PROTO Write-Up draft-ietf-dnsop-reverse-mapping-considerations-06.txt Waiting for PROTO Write-Up ----------------------------------------------------------------------------- 3) WG Charter [ 13:13 {audio 0:00:00} ] Performance and measurement topics might have overlap with both PMOL and BMWG, but talking with chair of these WGs (same one person), so expect new draft after IETF. ----------------------------------------------------------------------------- 4) Active Drafts [ 13:14 {audio 0:00:00} ] 4.1) draft-ietf-dnsop-respsize-11.txt Awaiting WGLC 4.2) draft-ietf-dnsop-as112-ops-01.txt draft-ietf-dnsop-as112-under-attack-help-help-01.txt Awaiting WGLC Need to be revived for WGLC, no other hurdles. 4.3) draft-ietf-dnsop-dnssec-trust-anchor-02.txt [ 13:15 {audio 0:00:00} ] Matt Larson: Thought were going to have a WGLC in April. Think everyone's comments are addressed in -02 of this draft, so still ready for last call. When will this be? Chairs: Real Soon Now 4.4) draft-ietf-dnsop-resolver-priming-01.txt [ 13:16 {audio 0:00:00} ] Peter Koch: How many have read it? [About 10] Revised document to include comments on -00 versions. One topic removed: * DNSSEC validation of priming response. Other changes: * should NOT expect exactly 13 NS RRs (due to private/split DNS scenarios) * differences in priming response should notify operator somehow Issues: * What to do when only 512 octets available for response? Current text says, "prefer A". Different strategies exist today. Lars-Lohan Liman: What is the reason for wanting to specify this? Peter Koch: Sounded like a good idea to be consistent and friendly to resolving systems. If we can leave this open, then happy to remove this stuff. Lars-Lohan Liman: I think you should avoid specifying and leave it to operator of the server. Allows changes, and also diversity between operators, and also either A or AAAA recommendation will be premature or outdated. Peter: RFC 4472 already makes recommendations. One reason there should be guidance is that those root name servers that fill in AAAA might give priming responses that lack information completely for a given root server. How should a resolver deal with that situation? Lars-Lohan Liman: If you don't know, ask a root name server. They all carry all the names for the others. If we *do* have a recommendation, it should be to mix address types. Jaap Akkerhuis: Better to be mixed than to prefer things. Jaap Akkerhuis: Some of the recommendations are not really clear whether they are for the servers or for the resolvers. These problems can be solved by making explicit. Peter: Intent is for it to be specific for client and server. Stephane Bortzmeyer: Peter: Addresses for name servers for TLDs or futher Stephane: What to do if priming response is incomplete? Inconsistency between cache and response. Not a big difference between priming and ordinary requests. Rob Austein: There is a larger issue. EDNS fallback rules are starting to be a problem. What does a client do if it tries EDNS query and it does not work? Andrew Sullivan: [ Mostly echoing from jabber room. ] Should be talking about tradeoffs rather than making recommendations. A little uncomfortable making firm recommendations here. If you prefer A, some people will be 2nd class systems if they are moving to AAAA. Peter: Documenting tradeoffs means you cannot reach concensus, and I hope that we are not there yet. Also, this is a special place in the DNS tree. Mark Andrews: A lot of this comes back to bad behavior in BIND 8. IPv6 capable name servers are supposed to accept EDNS0. If you want to keep BIND 8 working you need to preference AAAA. Peter: If you have received your first incomplete response, you already have something to feed into your cache, so you could start the normal resolution process. Mark: You can, but you can also ask for the rest of your information. BIND 8 and BIND 4 did not, as they are lazy. Peter: Chapter & verse welcome as additional text. * What to do if priming response is incomplete (size or lack of EDNS0)? * Can we assume all root name servers to be authoritative for the root name servers names. Today this is not true, as L root does not serve root-servers.net. Matt Larson: The intent is that they all serve root-servers.net, and if this not true now we need to fix this. Mark: Information should be the same. Peter: Yes, but how efficient is it to get this information? Better to not have to go to the .NET servers to get this information. Brian Dickson: Rather than having a universal set of rules for each root server, we can have a set of results that can be expected. Peter: What happens if the client did not signal EDNS0 or used 512 and the server replied with more? That is a protocol violation. You cannot send unsolicited large packets. Lars-Lohan Liman: It is not good to return information that should come several layers down. But this is how it works. Removed DNSSEC recommendations: Should we reconsider this and put the recommendation back? Is there any purpose in setting the DO bit in the priming query? Mark: Recommend letting client make own decision about DO bit. Peter: What would you do? What do you do? Mark: We set DO bit if DNSSEC is enabled. Stephane: -01 says priming request must be UDP. Why is this? Also do recent developments mean we should reconsider? Peter: 1123 says you must start with UDP instead of TCP. Stephane: If resolver poisoned during priming a big problem. We can suggest TCP for priming only. Other Issues: * Are A/AAAA/NS RRSet TTLs to be aligned? * Within the root zone? With root-servers.net? * Should it be in IANA considerations? (Not strictly covered by RFC 2860) Lars-Lohan Liman: IANA considerations is not in the right place. Not all root servers are handled by IANA; you can have a private network. Peter: What about the first two questions? Lars-Lohan Liman: I would think aligning is a good thing. But DNSSEC might not allow this. Mark? Mark: Records should not be there. Answers will always come from .NET, so non-issue. Peter: But if you look at the TTLs, they are different, and do not match root-servers.net. Mark: Should not be there. Nothing in 1035 that says to look there! Need to fix the spec! Mark: As for TTLs... make them align. ----------------------------------------------------------------------------- 5) Current & New Topics [ 13:35 {audio 0:00:00} ] 5.1) Design Team Deliverable [ 13:35 {audio 0:00:00} ] "Name Server Configuration Protocol Requirements" Wes Hardaker Who has read that was not on the design team? [ Several hands ] Ed Lewis: Lot of security items. Did you also consider like "also-notify", and other things? Wes Hardaker: See if addressed later in presentatin. Carsten Strotmann: named-checkzone in validating the data? Kind of weird. [ agreed to hold until end of presentation ] Steve Crocker: One of the scenarios is ability for one group to manage the contents of the data, but service and signing elsewhere (or where the data is). To what extents do the requirements anticipate both scenarios? Wes Hardaker: Document is much higher level. Gut feeling is to list as deployment scenarios. Steve Crocker: These scenarios are of interest to user communities. Questions: Does DNSOP want it? Where should follow-on standards work be done? 5.2) Design Team Status and Next Steps [ 14:09 {audio 0:00:00} ] Jaap Akkerhuis - Make requirements WG work item - Disband design team (DCOMA) - Start protocol work - Need design team? Rob Austein: Our feeling is design team has done its job, so just normal WGLC procedure for document. Peter Koch: How many read latest version, outside of design team? [ More than 5 hands - 10ish? ] Peter: Is this a useful draft to continue within this WG? Andrew Sullivan: [ Jelte Jansen in jabber room. ] Should document not be an RFC but just used as a basis for protocol work? Rob Austein: Want a stable document to pass off to other group (maybe). Jaap Akkerhuis: Written as a requirement not a design. Mohsen Souissi: Read document, found quite comprehensive. Should we use some new keyworks like RFC 4307 (should+, must-, and so on)? John Schnizlein: Critical for managing DNS, so support this and appreciate design team. Roy Arends: Please issue a hum for adoption. Rob Austein: Already seen more than 5 people who have read it. Show of hands who will read future versions. [ LOTS of hands, 20ish ] Hum... [ loudish hum in favor ] 5.3) Proposal to revise RFC 4641 [ 14:20 {audio 0:00:00} ] Paul Hoffman: Came from .ORG DNSSEC review, PIR used the RFC and it was not good! Olaf Kolkman: All issues brought up are worth discussing. Do not necessarily agree wth all arguments, but that is part of discussion. Not sure if should be informational or BCP. Was not a BCP; maybe should be, but probably still in too much flux. Willing to hold a pen for this. Will support changing the document. Steve Crocker: Trust anchor words put them in a 2nd class position if your parent is signed. I think this is debatable. We are going to have to deal with trust anchors, comfortably, in a 1st class way. Trust anchor system is necessary, and will stay around. Paul Hoffman: Signing the root does not make the problem go away. We still have trust anchors! Olaf Kolkman: You will never know who configured your key as a trust anchor, so you always have to treat your KSK as a trust anchor. Wes Hardaker: If you are going to talk about rolling keys and putting DS in parent, I recommend putting advice for TTLs. Rob Austein: Should we adopt the document? Wes Hardaker: Hard to say, since you say "we may want to change things". Olaf Kolkman: Propose treating current document as draft and starting an issues list. Peter Koch: Want clear deliniation of issues, some from crypto, rollover issues, and so on. ----------------------------------------------------------------------------- 6) Other (non WG) Internet-Drafts [ 14:37 {audio 0:00:00} ] 6.1) Non-Availability of Dynamic Updates [ 14:37 {audio 0:00:00} ] Joe Abley Rob Austein: Useful proposal, but not obvious to me this is a DNSOP item, might be protocol change so for other WG. Mark: Document predicated on broken update clients. Supposed to use NS RRSET, not SOA. MNAME in SOA is only used to choose between name servers in NS RRSET. Joe Abley: Behaviour I have seen is if MNAME matches something in NS RRSET then do not set. Peter Koch: Appreciate the problem description. Do not like the adoption as WG item, since I don't like the solution. Should do something about problem though. Wes Hardaker: Would want to see a description of why this is a problem in the real world. Do you have measurements about this? Rob Austein: Look at "A Day in the Life of J.ROOT" Joe Abley: Traffic is being received, not sure it is a problem. Jim Reid: Olafur Gudmundsson: Chairs of two DNS WGs need to talk about where this will reside. Rob Austein: Hum if you think this is a problem that needs to be solved? [ Pretty loud in favor, nothing against ] Andrew Sullivan: Even if this is a protocol change, there may be other answers which do not involve protocol changes. Olafur: Chairs of DNSEXT would like DNSOP to host a discussion about the problem. Later decide where to deal with it. [ Some hum in favor of this discussion ] Joe Abley: Would like to point out that draft is shorter than the discussion. 6.2) EDNS0 Support in Auth Servers on 27 July [ 14:50 {audio 0:00:00} ] Shane Kerr George Michaelson: Does not contract clients not using EDNS0. On client side I see 60/40 split (60 do have it). Rob Austein: EDNS capable clients may not need to do fall back anymore. Ed Lewis: Measuring this against domains? Could be someone has a slave server stuck in the old days. Curious how many domains do not work. Wes Hardaker: Numbers done before or after CERT announcement? Joe Abley: After. We may run this a number of times. Olafur Gudmundsson: Really cool. You hit "regular" name servers, not load balancers and so on. Jim Reid: Wonder if you have any analysis on recursive resolvers? Joe Abley: Zones we use, we run authority servers. Shane Kerr: May not be quite as rosy because some name servers drop packets for EXAMPLE.COM. Will run again with queries within delegated zones. 6.3) draft-licanhuang-dnsop-distributeddns-04.txt [chairs] cancelled ----------------------------------------------------------------------------- 7) I/O with other WGs [ 15:01 {audio 2:00:00} ] v6ops: DNS AAAA synthesis ----------------------------------------------------------------------------- 8) A.O.B. [ 15:02 {audio 2:00:00} ] NONE ----------------------------------------------------------------------------- Z) Meeting closed [ 15:03 {audio 2:00:00} ] -----------------------------------------------------------------------------