From jim at rfc1035.com Mon Nov 3 12:09:18 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 3 Nov 2008 11:09:18 +0000 Subject: [dns-wg] revised text for NTIA response - v4 Message-ID: I have updated the list of bullet points to reflect the recent comments and feedback. There are a few minor tweaks and some introductory motherhood and apple pie statements. Point 5 has the most substantive change. I think it now accommodates the concerns that some have expressed about the possibilty that the existing way of managing the root could become entrenched by the deployment of DNSSEC. Perhaps the two sentences here need to be split into discrete statements? We have to be careful here. If we don't go along with the current process for co-ordinating root zone changes, politicians will latch on to that as an excuse to open another line of attack over USG control of the Internet. If that happens, we won't get a signed root any time soon. So I hope the line we can all agree on is "Let's go with the current process for managing the root for now to get DNSSEC deployed. But don't introduce a signed root in a way that will prevent a different mechanism with perhaps different entities and roles being used at some point later on.". I hope we can all live with that. This is what I have tried to encapsulate in point 5. Point 12 is a tweaked version of Richard Lamb's remarks. I think this could/should be moved nearer to the top of the list. Anyway, now it's time for comments. It would be helpful if you contribute alternate text along with any clarifications or remarks. ie Please don't just say "Point X is unclear/confusing". Please say why it's confusing and suggest better wording. If we are to reach consensus by this weekend, the discussion needs to be focused and direct. # # $Id: ntia-draft,v 1.4 2008/11/03 10:25:25 jim Exp $ # RIPE welcomes the NTIA's consultation on the proposals to sign the root and is pleased to support that effort. We urge the NTIA to adopt a solution that leads to a prompt signed root zone. The solution must not compromise the stability and integrity of the root zone management process. It should be flexible enough to allow for the entities and roles involved in the process to be replaced or for the process itself to be replaced. The solution should minimise reasonable concerns, whether they are of a political, economic or business nature. It is to be expected that a community as diverse as RIPE cannot have a unified set of detailed answers to the NTIA questionnaire. However several members of the RIPE community will be individually responding to that questionnaire. We present the following statement as the consensus view of our community (or the DNS Working Group?) about the principles that should form the basis of the introduction of a signed DNS root. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control. 2. The introduction of DNSSEC to the root zone must be recognised as a global initiative. 3. Addition of DNSSEC to the root zone must be done in a way that the security and stability of the Domain Name System is not at risk. 4. Deployment of a signed root should be done in a timely but not hasty manner. 5. To assist with a timely deployment, any procedural changes introduced by DNSSEC should be aligned with the current process for coordinating changes to and the distribution of the root zone. However those procedural changes should provide sufficient flexibility to allow for the roles and processes as well as the entities holding those roles to be changed after suitable consultations have taken place. 6. Policies and processes for signing the root zone should make it easy for TLDs to supply keys and credentials so the delegations for those TLDs can be signed. 7. There is no technical justification to create a new organisation to oversee the process of signing of the root. 8. No data should be moved between organisations without appropriate authenticity and integrity checking. 9. The public part of the key signing key must be distributed as widely as possible. 10. The organisation that generates the root zone file must hold the private part of the zone signing key. 11. Changes to the entities and roles in the signing process must not necessarily require a change of keys. 12. When balancing the various concerns about signing the root zone, the chosen approach must provide an appropriate level of trust and confidence by offering a maximally secure technical solution. From bmanning at vacation.karoshi.com Mon Nov 3 17:05:07 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 3 Nov 2008 16:05:07 +0000 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: References: Message-ID: <20081103160507.GA5068@vacation.karoshi.com.> > Anyway, now it's time for comments. It would be helpful if you > contribute alternate text along with any clarifications or remarks. ie > Please don't just say "Point X is unclear/confusing". Please say why > it's confusing and suggest better wording. If we are to reach > consensus by this weekend, the discussion needs to be focused and > direct. > > # > # $Id: ntia-draft,v 1.4 2008/11/03 10:25:25 jim Exp $ > # > > 10. The organisation that generates the root zone file must hold the > private part of the zone signing key. > the imperative in this point is made with zero justification. why the "must hold"? I think a more pragmatic reply (if the previous points are to be respected) would be something along these lines: 10. The organization that generates the root zone file must sign the file and therefore must hold the private part of the zone signing key. or 10. The organization that generates the root zone file must have unfettered access to the zone signing key components. I have a slight inclination towards the second. --bill From jim at rfc1035.com Mon Nov 3 17:12:02 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 3 Nov 2008 16:12:02 +0000 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: <20081103160507.GA5068@vacation.karoshi.com.> References: <20081103160507.GA5068@vacation.karoshi.com.> Message-ID: On Nov 3, 2008, at 16:05, bmanning at vacation.karoshi.com wrote: >> 10. The organisation that generates the root zone file must hold the >> private part of the zone signing key. >> > > the imperative in this point is made with zero justification. > why the "must hold"? Well, it will be hard to sign the root if the entity that generates the zone hasn't got access to the private part of the ZSK. From bmanning at vacation.karoshi.com Mon Nov 3 17:22:39 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 3 Nov 2008 16:22:39 +0000 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: References: <20081103160507.GA5068@vacation.karoshi.com.> Message-ID: <20081103162239.GA5456@vacation.karoshi.com.> On Mon, Nov 03, 2008 at 04:12:02PM +0000, Jim Reid wrote: > On Nov 3, 2008, at 16:05, bmanning at vacation.karoshi.com wrote: > > >>10. The organisation that generates the root zone file must hold the > >>private part of the zone signing key. > >> > > > > the imperative in this point is made with zero justification. > > why the "must hold"? > > Well, it will be hard to sign the root if the entity that generates > the zone hasn't got access to the private part of the ZSK. thats hardly true - unless the presumptive argument is that the generator also signs. going w/ your earlier thread, the pragmatic approach (get the zoen signed this decade) is exactly down that line of argument. I, however, am taking a slightly divergent POV. I think it si required to create a third party to generate/hold/use the keys (some blend of options #3 and #6 in the graphics) a strictly technical solution would be to eliminate two of the three parties currently involved. there is no technical reason things are structured they way they are today. there are sound political reasons to create a new structure, one that does not assemble the data or publish the data but simply attests to the data. anyway, point 10 woudl be clearer if the reason fo rthe must was made explicit. --bill From paf at cisco.com Mon Nov 3 20:11:18 2008 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 3 Nov 2008 21:11:18 +0200 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: <20081103160507.GA5068@vacation.karoshi.com.> References: <20081103160507.GA5068@vacation.karoshi.com.> Message-ID: On 3 nov 2008, at 18.05, bmanning at vacation.karoshi.com wrote: > I think a more pragmatic reply (if the previous points are to > be respected) would be something along these lines: > > 10. The organization that generates the root zone file must sign the > file and therefore must hold the private part of the zone signing key. > > or > > 10. The organization that generates the root zone file must have > unfettered > access to the zone signing key components. > > > I have a slight inclination towards the second. I think the first of these is better as the word "unfettered" is not easy to understand if one is not english speaking. I for one have no idea what it means... The simpler the text, the better. Patrik From bmanning at vacation.karoshi.com Mon Nov 3 20:28:45 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 3 Nov 2008 19:28:45 +0000 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: References: <20081103160507.GA5068@vacation.karoshi.com.> Message-ID: <20081103192845.GA7001@vacation.karoshi.com.> On Mon, Nov 03, 2008 at 09:11:18PM +0200, Patrik FC$ltstrC6m wrote: > > On 3 nov 2008, at 18.05, bmanning at vacation.karoshi.com wrote: > > > I think a more pragmatic reply (if the previous points are to > > be respected) would be something along these lines: > > > >10. The organization that generates the root zone file must sign the > >file and therefore must hold the private part of the zone signing key. > > > >or > > > >10. The organization that generates the root zone file must have > >unfettered > >access to the zone signing key components. > > > > > > I have a slight inclination towards the second. > > I think the first of these is better as the word "unfettered" is not > easy to understand if one is not english speaking. I for one have no > idea what it means... > > The simpler the text, the better. > > Patrik Main Entry: fetB7ter Pronunciation: \Kfe-tIr\ Function: noun Etymology: Middle English feter, from Old English; akin to Old English fE t foot Date: before 12th century 1 : a chain or shackle for the feet 2 : something that confines : restraint that clarified, if you are happier with the first choice, i think it will make the response a better one than the current text. --bill From paf at cisco.com Mon Nov 3 20:30:54 2008 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 3 Nov 2008 21:30:54 +0200 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: <20081103192845.GA7001@vacation.karoshi.com.> References: <20081103160507.GA5068@vacation.karoshi.com.> <20081103192845.GA7001@vacation.karoshi.com.> Message-ID: On 3 nov 2008, at 21.28, bmanning at vacation.karoshi.com wrote: > Etymology: > Middle English feter, from Old English; akin to Old English fE > t foot HA HA HA! > Date: > before 12th century That was about the same time as we started working on DNSSEC, right? ;-) Patrik From bmanning at vacation.karoshi.com Mon Nov 3 20:34:52 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 3 Nov 2008 19:34:52 +0000 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: References: <20081103160507.GA5068@vacation.karoshi.com.> <20081103192845.GA7001@vacation.karoshi.com.> Message-ID: <20081103193452.GA7114@vacation.karoshi.com.> On Mon, Nov 03, 2008 at 09:30:54PM +0200, Patrik Fdltstrvm wrote: > > >Date: > > before 12th century > > That was about the same time as we started working on DNSSEC, right? > > ;-) > > Patrik DNSSEC was already in its second incarnation then. :) --bill From jim at rfc1035.com Tue Nov 4 00:56:16 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 3 Nov 2008 23:56:16 +0000 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: <20081103162239.GA5456@vacation.karoshi.com.> References: <20081103160507.GA5068@vacation.karoshi.com.> <20081103162239.GA5456@vacation.karoshi.com.> Message-ID: <7B31EAF4-1764-4C43-82C1-6573CC206441@rfc1035.com> On Nov 3, 2008, at 16:22, bmanning at vacation.karoshi.com wrote: > thats hardly true - unless the presumptive argument is > that the generator also signs. Well Bill, that seems to be a valid assumption as far as this WG goes. Other options are theoretically possible, but from a pragmatic PoV they don't make sense IMO. Having one entity create an unsigned file to give to someone else to sign (and distribute?) just adds more complexity and more opportunities for things to go wrong. One could also argue that "generating" the zone includes the insertion of RRSIGs, DS records, NSEC3 and so on. > going w/ your earlier thread, the pragmatic approach (get the > zoen signed this decade) is exactly down that line of argument. Indeed. Let's get the root signed! Soon! > I, however, am taking a slightly divergent POV. I think it si > required to create a third party to generate/hold/use the keys > (some blend of options #3 and #6 in the graphics) > > a strictly technical solution would be to eliminate two of the > three parties currently involved. there is no technical reason > things are structured they way they are today. By all means Bill express that as your view when you respond to the NTIA consultation. However please don't open up that can of worms here. There are diverging (perhaps mutually exclusive) views in this WG about which of the NTIA proposals are better/ideal/preferred. I doubt a consensus can emerge around one of them from the WG and we've pretty much decided not to try and look for that because it's likely to be impossible in the time available, if ever. Instead, there's a consensus to state the general high-level principles that we would like to see in a signed DNS root. This was the general direction which prevailed in Dubai last week. > there are sound political reasons to create a new structure, one that > does not assemble the data or publish the data but simply attests > to the data. Well so far Bill, I hear no-one else supporting that view. I would advise the WG against exploring this approach right now. Firstly, the clock is ticking. If we can't get consensus on an NTIA response by the end of this week, it's over. If the WG can't make up its mind by then, we can't ask for RIPE community endorsement in time to get something sent to NTIA by the deadline. Which is just 3 weeks away. The second reason is that raising the prospect of creating a new structure will open up all sorts of layer-9 and above rat-holes that will take forever to resolve. This will give the politicians and lawyers an opportunity to pile in and start arguments that will go on until the start of the next Ice Age. IMO that would be bad. > anyway, point 10 woudl be clearer if the reason fo rthe must was > made explicit. Noted. Can we agree to leave the matter there? I'll add some explanatory text for the next version. From bmanning at vacation.karoshi.com Tue Nov 4 01:10:44 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 4 Nov 2008 00:10:44 +0000 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: <7B31EAF4-1764-4C43-82C1-6573CC206441@rfc1035.com> References: <20081103160507.GA5068@vacation.karoshi.com.> <20081103162239.GA5456@vacation.karoshi.com.> <7B31EAF4-1764-4C43-82C1-6573CC206441@rfc1035.com> Message-ID: <20081104001044.GA9052@vacation.karoshi.com.> On Mon, Nov 03, 2008 at 11:56:16PM +0000, Jim Reid wrote: > On Nov 3, 2008, at 16:22, bmanning at vacation.karoshi.com wrote: > > By all means Bill express that as your view when you respond to the > NTIA consultation. However please don't open up that can of worms > here. just providing a bit of backing material on some of the unstated assumptions in the RIEP WG response. I have no intention to debate the relative merits over email. (But if I can have a quiet chat over there in the bar w/ you...) > > anyway, point 10 woudl be clearer if the reason fo rthe must was > > made explicit. > > Noted. Can we agree to leave the matter there? I'll add some > explanatory text for the next version. i think that will help make the point. (as a native english speaker :) --bill From bortzmeyer at nic.fr Tue Nov 4 12:05:08 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 4 Nov 2008 12:05:08 +0100 Subject: [dns-wg] Re: revised text for NTIA response - v4 In-Reply-To: References: Message-ID: <20081104110508.GA19080@nic.fr> On Mon, Nov 03, 2008 at 11:09:18AM +0000, Jim Reid wrote a message of 94 lines which said: > I have updated the list of bullet points to reflect the recent > comments and feedback. The list of bullet points seems reasonable to me and reflects faithfully the discussions IRL in Dubai. However, the new introductory paragraph is very questionable: > RIPE welcomes the NTIA's consultation on the proposals to sign the > root and is pleased to support that effort. RIPE certainly has no business issuing political statements of support like this one! I certainly do not approve the fact that the root signing process is driven by the NTIA and I believe many people in RIPE do not approve either. Let's stick with what we want and do not add any sort of support or applause for the unilateral management of the process by the NTIA. > We urge the NTIA to adopt a solution that leads to a prompt signed > root zone. Same thing here. Stay with technical requirments, do not ask a specific organization to do something. From jim at rfc1035.com Wed Nov 5 12:11:33 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 5 Nov 2008 11:11:33 +0000 Subject: [dns-wg] Re: revised text for NTIA response - v4 In-Reply-To: <20081104110508.GA19080@nic.fr> References: <20081104110508.GA19080@nic.fr> Message-ID: On Nov 4, 2008, at 11:05, Stephane Bortzmeyer wrote: >> RIPE welcomes the NTIA's consultation on the proposals to sign the >> root and is pleased to support that effort. > > RIPE certainly has no business issuing political statements of support > like this one! I certainly do not approve the fact that the root > signing process is driven by the NTIA and I believe many people in > RIPE do not approve either. Let's stick with what we want and do not > add any sort of support or applause for the unilateral management of > the process by the NTIA. Stephane, I do not believe this interpretation can be drawn from the opening paragraphs. It's common courtesy to respond to these sorts of consultations by thanking the organisation for offering an opportunity to comment. This does not mean endorsement or acceptance that the people doing the consultation have some form of authority or control over whatever the consultation is about. However let's not debate this: the clock is ticking. Please contribute text. It is not helpful to just say "I don't like this". Please suggest alternate wording that addresses your concerns and could serve as a suitable introduction to our response. I realise some members of this WG do not like the NTIA's involvement in the root zone. However the reality is that unless the NTIA does something (for some definition of something), there won't be a signed root before our grandchildren retire. And if the Internet community doesn't support the NTIA proposals (for some definition of support), the politicians and bureaucrats will intervene to kill or indefinitely postpone the creation of a signed root because they can justifiably claim that support is not there. So the choice here is clear: either the world continues with an unsigned root or it gets a signed root that has involvement of an organisation that some of us would prefer not to have a role in the oversight DNS root. >> We urge the NTIA to adopt a solution that leads to a prompt signed >> root zone. > > Same thing here. Stay with technical requirments, do not ask a > specific organization to do something. Same here: suggest alternate text. How about "We urge the adoption of a solution that leads to a prompt signed root zone."? From bortzmeyer at nic.fr Wed Nov 5 17:37:35 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 5 Nov 2008 17:37:35 +0100 Subject: [dns-wg] Re: revised text for NTIA response - v4 In-Reply-To: References: <20081104110508.GA19080@nic.fr> Message-ID: <20081105163735.GA12895@nic.fr> On Wed, Nov 05, 2008 at 11:11:33AM +0000, Jim Reid wrote a message of 44 lines which said: > Please contribute text. OK. I suggest to replace: "RIPE welcomes the NTIA's consultation on the proposals to sign the root and is pleased to support that effort. We urge the NTIA to adopt a solution that leads to a prompt signed root zone. The solution must not compromise the stability and integrity of the root zone management process." by: "RIPE wants the root zone to be signed, in order to enable an easier deployment of DNSSEC." and then go on with your text. From jim at rfc1035.com Wed Nov 5 23:11:03 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 5 Nov 2008 22:11:03 +0000 Subject: [dns-wg] Re: revised text for NTIA response - v4 In-Reply-To: <20081105163735.GA12895@nic.fr> References: <20081104110508.GA19080@nic.fr> <20081105163735.GA12895@nic.fr> Message-ID: <3F6C86C9-8B0E-48F1-9D22-EC96754B46B5@rfc1035.com> On Nov 5, 2008, at 16:37, Stephane Bortzmeyer wrote: > On Wed, Nov 05, 2008 at 11:11:33AM +0000, > Jim Reid wrote > a message of 44 lines which said: > >> Please contribute text. > > OK. I suggest to replace: > > "RIPE welcomes the NTIA's consultation on the proposals to sign the > root and is pleased to support that effort. We urge the NTIA to adopt > a solution that leads to a prompt signed root zone. The solution must > not compromise the stability and integrity of the root zone management > process." > > by: > > "RIPE wants the root zone to be signed, in order to enable an easier > deployment of DNSSEC." > > and then go on with your text. Stephane, this your text is somewhat abrupt. I do not consider it appropriate for any formal correspondance, far less something that represents the DNS WG and/or the RIPE community. Our response should be courteous and observe the expected niceties: like thanking NTIA for running a consultation and giving the world a chance to comment. Which the NTIA didn't *have* to do. I will try to construct something from your input that (a) is something the WG/RIPE community can accept as a consensus view; (b) observes the usual etiquette which both parties should follow. From jim at rfc1035.com Wed Nov 5 23:42:38 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 5 Nov 2008 22:42:38 +0000 Subject: [dns-wg] NTIA response - v5 Message-ID: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> I have updated the draft response to reflect today's comments. Aside from tweaking the introductory paragraph -- I hope this now sets the right tone without upsetting Stephane -- the significant change was to move Rick's comments about trust to nomber 4 from number 12 on the list. This seemed to be a more suitable place for this point. Is version 5 of the draft now something that the WG as a whole can accept? PS: Please try to avoid suggestions on cosmetic changes to the text unless these would improve the clarity. The WG needs to reach consensus on a statement in a day or two. So we should try to focus on what we are trying to say rather than how we are actually saying it. Within reason of course.... # # $Id: ntia-draft,v 1.6 2008/11/05 22:36:42 jim Exp $ # The RIPE community (or DNS WG?) thanks the NTIA for its consultation on proposals to sign the root and is pleased to offer the following response to that consultation. We urge the adoption of a solution that leads to the prompt introduction of a signed root zone. Our community considers the introduction of a signed root zone to be an essential enabling step towards widespread deployment of Secure DNS, DNSSEC. It is to be expected that a community as diverse as RIPE cannot have a unified set of detailed answers to the NTIA questionnaire. However several members of the RIPE community will be individually responding to that questionnaire. We present the following statement as the consensus view of our community (or the DNS Working Group?) about the principles that should form the basis of the introduction of a signed DNS root. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control. 2. The introduction of DNSSEC to the root zone must be recognised as a global initiative. 3. Addition of DNSSEC to the root zone must be done in a way that does not compromise the security and stability of the Domain Name System. 4. When balancing the various concerns about signing the root zone, the chosen approach must provide an appropriate level of trust and confidence by offering a maximally secure technical solution. 5. Deployment of a signed root should be done in a timely but not hasty manner. 6. To assist with a timely deployment, any procedural changes introduced by DNSSEC should be aligned with the current process for coordinating changes to and the distribution of the root zone. However those procedural changes should provide sufficient flexibility to allow for the roles and processes as well as the entities holding those roles to be changed after suitable consultations have taken place. 7. Policies and processes for signing the root zone should make it easy for TLDs to supply keys and credentials so the delegations for those TLDs can be signed. 8. There is no technical justification to create a new organisation to oversee the process of signing of the root. 9. No data should be moved between organisations without appropriate authenticity and integrity checking. 10. The public part of the key signing key must be distributed as widely as possible. 11. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key. 12. Changes to the entities and roles in the signing process must not necessarily require a change of keys. From bmanning at vacation.karoshi.com Thu Nov 6 00:01:23 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 5 Nov 2008 23:01:23 +0000 Subject: [dns-wg] NTIA response - v5 In-Reply-To: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> References: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> Message-ID: <20081105230123.GA1651@vacation.karoshi.com.> much better - wrt the opening statement, I suspect this should be couched as a response from teh RIPE DNS WG and not the Ripe community as a whole, since I suspect they have not seen the text or had a chance to comment on the same. --bill From fweimer at bfk.de Thu Nov 6 12:06:30 2008 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 06 Nov 2008 12:06:30 +0100 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: <20081103160507.GA5068@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Mon, 3 Nov 2008 16:05:07 +0000") References: <20081103160507.GA5068@vacation.karoshi.com.> Message-ID: <82mygdktah.fsf@mid.bfk.de> > 10. The organization that generates the root zone file must sign the > file and therefore must hold the private part of the zone signing key. > > or > > 10. The organization that generates the root zone file must have > unfettered access to the zone signing key components. The second version seems to exclude storing the ZSK in an HSM. The first version is more ambiguous. In both cases, I don't quite see what the statement is supposed to mean. Does it advise against the introduction of yet another layer of indirection, by requiring that the organization which makes the final, technical content decision on the root zone (the "generator") also creates the digital signatures? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pk at DENIC.DE Thu Nov 6 12:48:36 2008 From: pk at DENIC.DE (Peter Koch) Date: Thu, 6 Nov 2008 12:48:36 +0100 Subject: [dns-wg] NTIA response - v5 In-Reply-To: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> References: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> Message-ID: <20081106114836.GA466@x27.adm.denic.de> On Wed, Nov 05, 2008 at 10:42:38PM +0000, Jim Reid wrote: > PS: Please try to avoid suggestions on cosmetic changes to the text > unless these would improve the clarity. The WG needs to reach > consensus on a statement in a day or two. So we should try to focus on > what we are trying to say rather than how we are actually saying it. As a matter of process, the timeline as of Dubai suggests that the final draft response shall be ready by November, 10th. I.e., the DNS WG should have reached consensus by then - or the effort is goinf to die. After that date, further edits are not expected, but the RIPE community (as represented by the ripe-list mailing list) is asked for comment, aftre which the presence or absence of consensus will have to be judged. > The RIPE community (or DNS WG?) thanks the NTIA for its consultation As an editorial matter, I understand the part in brackets (same below) would come into effect if and only if the broader RIPE community does not accept the proposal _and_ the DNS WG still plans to pursue. > 4. When balancing the various concerns about signing the root zone, > the chosen approach must provide an appropriate level of trust and > confidence by offering a maximally secure technical solution. It is unclear to me what the implications of "maximally secure" are. Does this imply FIPS 140 level 4 HSMs and 4K key lengths? I doubt that, but I'd appreciate a clarification here to avoid ambiguity. > 7. Policies and processes for signing the root zone should make it > easy for TLDs to supply keys and credentials so the delegations for > those TLDs can be signed. I'd avoid the notion of delegations being signed, because that can be read in a way inconsistent with statement (1). The prime function of a DNSSEC signed root zone is a secure, centralized way of publishing TLD trust anchors: "... delegations for those TLDs can be accompanied by the TLDs' signed Trust Anchors." > 8. There is no technical justification to create a new organisation to > oversee the process of signing of the root. That's probably true, but one could argue that _technically_ there's also no need for today's role split, so I doubt this adds much. If this is a comment re: any particular proposal, the text should be more explicit. > 9. No data should be moved between organisations without appropriate > authenticity and integrity checking. Ack. The list doesn't say anything re: confidentiality requirements or, more precisely, moving ZSK private key material around. Shouldn't the latter be discouraged? > 11. The organisation that generates the root zone file must sign the > file and therefore hold the private part of the zone signing key. Why this if (9) was followed? Not saying (11) is bad, but it needs a bit more explanation. > 12. Changes to the entities and roles in the signing process must not > necessarily require a change of keys. I see two ambiguities here: first, which I assume 'keys' means KSK here; second: what is the meaning of "must not necessarily" as opposed to "must not"? -Peter ('s own opinions) From bmanning at vacation.karoshi.com Thu Nov 6 13:01:20 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 6 Nov 2008 12:01:20 +0000 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: <82mygdktah.fsf@mid.bfk.de> References: <20081103160507.GA5068@vacation.karoshi.com.> <82mygdktah.fsf@mid.bfk.de> Message-ID: <20081106120120.GA7037@vacation.karoshi.com.> On Thu, Nov 06, 2008 at 12:06:30PM +0100, Florian Weimer wrote: > > 10. The organization that generates the root zone file must sign the > > file and therefore must hold the private part of the zone signing key. > > > > or > > > > 10. The organization that generates the root zone file must have > > unfettered access to the zone signing key components. > > The second version seems to exclude storing the ZSK in an HSM. The > first version is more ambiguous. In both cases, I don't quite see > what the statement is supposed to mean. Does it advise against the > introduction of yet another layer of indirection, by requiring that > the organization which makes the final, technical content decision on > the root zone (the "generator") also creates the digital signatures? > > -- the first statement is an amplification ... the added text is "...and therefore..." eg. the org must hold the private key if it is going to sign the zone. the second actually does no preclude an HSM, but does acknowledge the NoI requirement that the administrator must have access to the signing keys (both K&Z, public and private). --bill From jim at rfc1035.com Thu Nov 6 14:25:02 2008 From: jim at rfc1035.com (Jim Reid) Date: Thu, 6 Nov 2008 13:25:02 +0000 Subject: [dns-wg] NTIA response - v5 In-Reply-To: <20081105230123.GA1651@vacation.karoshi.com.> References: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> <20081105230123.GA1651@vacation.karoshi.com.> Message-ID: <144EA11B-CA57-4396-8A89-ED2010CDC8D3@rfc1035.com> On Nov 5, 2008, at 23:01, bmanning at vacation.karoshi.com wrote: > much better - wrt the opening statement, I suspect this should > be couched as a response from teh RIPE DNS WG and not the Ripe > community as a whole, since I suspect they have not seen the text > or had a chance to comment on the same. Bill, the algorithm here is: if (no wg consensus by this weekend) give up send agreed WG text to ripe-announce if (ripe consensus by Nov 20th-ish) send letter(we == RIPE community) else send letter(we == DNS WG) From bmanning at vacation.karoshi.com Thu Nov 6 14:29:49 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 6 Nov 2008 13:29:49 +0000 Subject: [dns-wg] NTIA response - v5 In-Reply-To: <144EA11B-CA57-4396-8A89-ED2010CDC8D3@rfc1035.com> References: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> <20081105230123.GA1651@vacation.karoshi.com.> <144EA11B-CA57-4396-8A89-ED2010CDC8D3@rfc1035.com> Message-ID: <20081106132949.GA7948@vacation.karoshi.com.> On Thu, Nov 06, 2008 at 01:25:02PM +0000, Jim Reid wrote: > On Nov 5, 2008, at 23:01, bmanning at vacation.karoshi.com wrote: > > >much better - wrt the opening statement, I suspect this should > >be couched as a response from teh RIPE DNS WG and not the Ripe > >community as a whole, since I suspect they have not seen the text > >or had a chance to comment on the same. > > Bill, the algorithm here is: > > if (no wg consensus by this weekend) > give up > send agreed WG text to ripe-announce > if (ripe consensus by Nov 20th-ish) > send letter(we == RIPE community) > else > send letter(we == DNS WG) ack... thanks. --bill From ololocc at entratek.com Thu Nov 6 14:31:59 2008 From: ololocc at entratek.com (ololocc at entratek.com) Date: Thu, 6 Nov 2008 13:31:59 +0000 Subject: [dns-wg] NTIA response - v5 Message-ID: <1642674124-1225978320-cardhu_decombobulator_blackberry.rim.net-1121236429-@bxe103.bisx.prod.on.blackberry> Please unsubscribe cc_ololo at yahoo.com ------Original Message------ From: Jim Reid Sender: dns-wg-admin at ripe.net To: bmanning at vacation.karoshi.com Cc: dns-wg at ripe.net Sent: Nov 6, 2008 7:25 AM Subject: Re: [dns-wg] NTIA response - v5 On Nov 5, 2008, at 23:01, bmanning at vacation.karoshi.com wrote: > much better - wrt the opening statement, I suspect this should > be couched as a response from teh RIPE DNS WG and not the Ripe > community as a whole, since I suspect they have not seen the text > or had a chance to comment on the same. Bill, the algorithm here is: if (no wg consensus by this weekend) give up send agreed WG text to ripe-announce if (ripe consensus by Nov 20th-ish) send letter(we == RIPE community) else send letter(we == DNS WG) Sent via BlackBerry from T-Mobile From jim at rfc1035.com Thu Nov 6 14:35:23 2008 From: jim at rfc1035.com (Jim Reid) Date: Thu, 6 Nov 2008 13:35:23 +0000 Subject: [dns-wg] revised text for NTIA response - v4 In-Reply-To: <82mygdktah.fsf@mid.bfk.de> References: <20081103160507.GA5068@vacation.karoshi.com.> <82mygdktah.fsf@mid.bfk.de> Message-ID: <3F393695-DD99-4B3C-9327-1F6B931A4DB8@rfc1035.com> On Nov 6, 2008, at 11:06, Florian Weimer wrote: > In both cases, I don't quite see > what the statement is supposed to mean. Does it advise against the > introduction of yet another layer of indirection, by requiring that > the organization which makes the final, technical content decision on > the root zone (the "generator") also creates the digital signatures? It means whoever churns out the zone file for the root should also generate the RRSIGs for the signed version => having access to the ZSK. From jim at rfc1035.com Thu Nov 6 15:21:02 2008 From: jim at rfc1035.com (Jim Reid) Date: Thu, 6 Nov 2008 14:21:02 +0000 Subject: [dns-wg] NTIA response - v5 In-Reply-To: <20081106114836.GA466@x27.adm.denic.de> References: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> <20081106114836.GA466@x27.adm.denic.de> Message-ID: On Nov 6, 2008, at 11:48, Peter Koch wrote: > > As a matter of process, the timeline as of Dubai suggests that the > final > draft response shall be ready by November, 10th. I.e., the DNS WG > should > have reached consensus by then - or the effort is goinf to die. > After that date, further edits are not expected, but the RIPE > community > (as represented by the ripe-list mailing list) is asked for comment, > aftre which the presence or absence of consensus will have to be > judged. > Ditto. > >> The RIPE community (or DNS WG?) thanks the NTIA for its consultation > > As an editorial matter, I understand the part in brackets (same below) > would come into effect if and only if the broader RIPE community does > not accept the proposal _and_ the DNS WG still plans to pursue. Yes. >> 4. When balancing the various concerns about signing the root zone, >> the chosen approach must provide an appropriate level of trust and >> confidence by offering a maximally secure technical solution. > > It is unclear to me what the implications of "maximally secure" are. > Does this imply FIPS 140 level 4 HSMs and 4K key lengths? I doubt > that, > but I'd appreciate a clarification here to avoid ambiguity. This is implementation detail. It's not relevant to the *principles* we're stating. Let's not debate key lengths or which form of secure key handling hardware is best. That debate can be had somewhere else: dnsop for example. IMO "maximally secure" is good enough for the purposes of this letter. >> 7. Policies and processes for signing the root zone should make it >> easy for TLDs to supply keys and credentials so the delegations for >> those TLDs can be signed. > > I'd avoid the notion of delegations being signed, because that can be > read in a way inconsistent with statement (1). The prime function of > a DNSSEC signed root zone is a secure, centralized way of publishing > TLD trust anchors: "... delegations for those TLDs can be accompanied > by the TLDs' signed Trust Anchors." This is too subtle a distinction to matter IMO Peter. The people who will be reading any response (and acting on it) will not be DNS protocol engineers and crypto geeks. How about: Policies and processes for signing the root zone should make it easy for TLDs to supply keys and credentials so the delegations for those TLDs can benefit from a common DNSSEC trust anchor, the signed root. >> 8. There is no technical justification to create a new organisation >> to >> oversee the process of signing of the root. > > That's probably true, but one could argue that _technically_ there's > also no need for today's role split, so I doubt this adds much. If > this > is a comment re: any particular proposal, the text should be more > explicit. The intent here is to dissuade NTIA/ICANN/politicians from finding an excuse to introduce yet more bureaucracy to oversee the co-ordination of a signed root. A clear and unequivocal statement saying this is not needed will help to deflect those layer-9 arguments. Adding more text to this point will dilute that message and may well create more confusion, not less. Not to mention opening up rat-holes.... IMO the text is fine as-is. >> 9. No data should be moved between organisations without appropriate >> authenticity and integrity checking. > > Ack. The list doesn't say anything re: confidentiality requirements > or, > more precisely, moving ZSK private key material around. Shouldn't the > latter be discouraged? IMO the text is fine as-is. We're not writing a procedures manual or a functional spec here. >> 11. The organisation that generates the root zone file must sign the >> file and therefore hold the private part of the zone signing key. > > Why this if (9) was followed? Not saying (11) is bad, but it needs > a bit more explanation. Again, I believe the current text is fine as-is. IMO (9) primarily speaks to the movement of DS records and related stuff between TLDs and the root. (11) is about how the signed root zone is generated. In other words, it shouldn't be necessary for the root zone generator to go off and fetch the ZSK from somewhere else, then check it, every time it spits out a new signed root zone file. Besides, the root zone generator needs to have the flexibility to quickly change the ZSK for operational reasons: hard to do if some other entity is holding the ZSK. >> 12. Changes to the entities and roles in the signing process must not >> necessarily require a change of keys. > > I see two ambiguities here: first, which I assume 'keys' means KSK > here; Nope. The ambiguity here is deliberate. In all likelihood it's just KSKs that could be affected by a change of roles or organisations. But this should not be assumed or explicitly stated. > second: what is the meaning of "must not necessarily" as opposed to > "must not"? Wiggle room. Suppose one of the chosen entities screws up and has an important key compromised. The powers that be could be forced to choose someone else to take on that role and introduce a new key. OTOH, if a change of organisation or role is amicable, the existing key(s) move from the old to the new entity. So if one day the root KSK moves from my house to your house (say), that move shouldn't necessarily mean every TLD needs to generate new KSKs and/or ZSKs. But a change of TLD keys might be needed in that scenario because I've been perceived to be less trustworthy than you. For some definition of trustworthy. From pk at DENIC.DE Thu Nov 6 19:10:05 2008 From: pk at DENIC.DE (Peter Koch) Date: Thu, 6 Nov 2008 19:10:05 +0100 Subject: [dns-wg] NTIA response - v5 In-Reply-To: References: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> <20081106114836.GA466@x27.adm.denic.de> Message-ID: <20081106181005.GJ466@x27.adm.denic.de> Hi Jim, thanks for your patient response. > >>4. When balancing the various concerns about signing the root zone, > >>the chosen approach must provide an appropriate level of trust and > >>confidence by offering a maximally secure technical solution. > > > >It is unclear to me what the implications of "maximally secure" are. > >Does this imply FIPS 140 level 4 HSMs and 4K key lengths? I doubt > >that, > >but I'd appreciate a clarification here to avoid ambiguity. > > This is implementation detail. It's not relevant to the *principles* > we're stating. Let's not debate key lengths or which form of secure > key handling hardware is best. That debate can be had somewhere else: > dnsop for example. IMO "maximally secure" is good enough for the > purposes of this letter. maybe I misrepresented my intentions. Of course key lengths and matters of specific technology are far too detailed for this kind of response. However, "maximally secure" is too wide a term IMHO to be useful without a scale. Even more so since there's a balance between this "maximum" and operational reality. > This is too subtle a distinction to matter IMO Peter. The people who > will be reading any response (and acting on it) will not be DNS > protocol engineers and crypto geeks. How about: Exactly my point. If they were, they knew that the delegation isn't signed - technically. More importantly, there's also no other "signing" of the delegation. > Policies and processes for signing the root zone should make it easy > for TLDs to supply keys and credentials so the delegations for those > TLDs can benefit from a common DNSSEC trust anchor, the signed root. Sounds much better to me, thanks. > >>8. There is no technical justification to create a new organisation > >>to > The intent here is to dissuade NTIA/ICANN/politicians from finding an > excuse to introduce yet more bureaucracy to oversee the co-ordination > of a signed root. A clear and unequivocal statement saying this is not > needed will help to deflect those layer-9 arguments. Adding more text I doubt that any attempt, be that by reflex or by perceived attempt and angenda, to introduce bureaucracy can simply be defeated by a "no" statement, but so be it. > >>9. No data should be moved between organisations without appropriate > >>authenticity and integrity checking. > >>11. The organisation that generates the root zone file must sign the > >>file and therefore hold the private part of the zone signing key. > IMO (9) primarily speaks to the movement of DS records and related > stuff between TLDs and the root. (11) is about how the signed root Sure, but (9) could also be applied to an RZM and a separate root signer. Not that I'd see anyone here favor this, but the beauty is in the eye of the addressee. > then check it, every time it spits out a new signed root zone file. > Besides, the root zone generator needs to have the flexibility to > quickly change the ZSK for operational reasons: hard to do if some > other entity is holding the ZSK. The suggestions I've seen so far suggest to transfer the data or to transfer the ZSK once, not on every occasion, so this is besides the point. I can live with (11) as is, only I'd prefer a bit more reasoning. > >>12. Changes to the entities and roles in the signing process must not > >>necessarily require a change of keys. > >second: what is the meaning of "must not necessarily" as opposed to > >"must not"? > > Wiggle room. Suppose one of the chosen entities screws up and has an > important key compromised. The powers that be could be forced to > choose someone else to take on that role and introduce a new key. This is a new requirement. Not the change of entities but the compromise would suggest a key rollover in this case. Let's just focus on the preconditions set forth in the text. > key(s) move from the old to the new entity. So if one day the root KSK > moves from my house to your house (say), that move shouldn't > necessarily mean every TLD needs to generate new KSKs and/or ZSKs. But > a change of TLD keys might be needed in that scenario because I've > been perceived to be less trustworthy than you. For some definition of > trustworthy. I do not like this ambiguity and "wiggle room". The statement doesn't hurt, but with that additional explanation it doesn't say much, either. Again: so be it. -Peter From jim at rfc1035.com Fri Nov 7 12:36:30 2008 From: jim at rfc1035.com (Jim Reid) Date: Fri, 7 Nov 2008 11:36:30 +0000 Subject: [dns-wg] NTIA response - v5 In-Reply-To: <20081106181005.GJ466@x27.adm.denic.de> References: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> <20081106114836.GA466@x27.adm.denic.de> <20081106181005.GJ466@x27.adm.denic.de> Message-ID: On Nov 6, 2008, at 18:10, Peter Koch wrote: > I doubt that any attempt, be that by reflex or by perceived attempt > and > angenda, to introduce bureaucracy can simply be defeated by a "no" > statement, but so be it. This is true. The people who make those arguments for a new organisation or role to oversee DNSSEC in the root will make them regardless. But for those who have to debate that issue at places like IGF, it would be helpful them to point to community statements which say "we don't see a technical justification for adding another level of bureaucracy to the process". From jim at rfc1035.com Fri Nov 7 13:07:00 2008 From: jim at rfc1035.com (Jim Reid) Date: Fri, 7 Nov 2008 12:07:00 +0000 Subject: [dns-wg] final? draft of NTIA response Message-ID: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> Colleagues, here is what I hope is the final draft of our response to the NTIA. I trust we can reach consensus on this. There is very little time to continue with update/review cycles, so I would appreciate if any comments were confined to showstoppers. We might have reservations or quibbles about some of the detail or phrasing. However unless these materially affect the response, could I ask you to please keep these to yourself? My worry here is that further tweaks lead to yet more comments and tweaks, and this goes on and on and on. The current langauge may not be perfect. However I hope it is something that we can all agree is good enough. I would also ask WG members to say they support the text (assuming you do of course). It would be better to have positive statements of support instead of declaring that silence on this topic is consensus for the WG. # # $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $ # The RIPE community (or DNS WG?) thanks the NTIA for its consultation on proposals to sign the root and is pleased to offer the following response to that consultation. We urge the adoption of a solution that leads to the prompt introduction of a signed root zone. Our community considers the introduction of a signed root zone to be an essential enabling step towards widespread deployment of Secure DNS, DNSSEC. It is to be expected that a community as diverse as RIPE cannot have a unified set of detailed answers to the NTIA questionnaire. However several members of the RIPE community will be individually responding to that questionnaire. We present the following statement as the consensus view of our community (or the DNS Working Group?) about the principles that should form the basis of the introduction of a signed DNS root. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control. 2. The introduction of DNSSEC to the root zone must be recognised as a global initiative. 3. Addition of DNSSEC to the root zone must be done in a way that does not compromise the security and stability of the Domain Name System. 4. When balancing the various concerns about signing the root zone, the chosen approach must provide an appropriate level of trust and confidence by offering a maximally secure technical solution. 5. Deployment of a signed root should be done in a timely but not hasty manner. 6. To assist with a timely deployment, any procedural changes introduced by DNSSEC should be aligned with the current process for coordinating changes to and the distribution of the root zone. However those procedural changes should provide sufficient flexibility to allow for the roles and processes as well as the entities holding those roles to be changed after suitable consultations have taken place. 7. Policies and processes for signing the root zone should make it easy for TLDs to supply keys and credentials so the delegations for those TLDs can benefit from a common DNSSEC trust anchor, the signed root. 8. There is no technical justification to create a new organisation to oversee the process of signing of the root. 9. No data should be moved between organisations without appropriate authenticity and integrity checking. 10. The public part of the key signing key must be distributed as widely as possible. 11. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key. 12. Changes to the entities and roles in the signing process must not necessarily require a change of keys. From bmanning at vacation.karoshi.com Fri Nov 7 13:19:43 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 7 Nov 2008 12:19:43 +0000 Subject: [dns-wg] final? draft of NTIA response In-Reply-To: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> References: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> Message-ID: <20081107121943.GA6869@vacation.karoshi.com.> this is a great piece of work ... and I CAN NOT support it. --bill On Fri, Nov 07, 2008 at 12:07:00PM +0000, Jim Reid wrote: > Colleagues, here is what I hope is the final draft of our response to > the NTIA. I trust we can reach consensus on this. There is very little > time to continue with update/review cycles, so I would appreciate if > any comments were confined to showstoppers. We might have reservations > or quibbles about some of the detail or phrasing. However unless these > materially affect the response, could I ask you to please keep these > to yourself? My worry here is that further tweaks lead to yet more > comments and tweaks, and this goes on and on and on. The current > langauge may not be perfect. However I hope it is something that we > can all agree is good enough. > > I would also ask WG members to say they support the text (assuming you > do of course). It would be better to have positive statements of > support instead of declaring that silence on this topic is consensus > for the WG. > > > # > # $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $ > # > > The RIPE community (or DNS WG?) thanks the NTIA for its consultation > on proposals to sign the root and is pleased to offer the following > response to that consultation. We urge the adoption of a solution that > leads to the prompt introduction of a signed root zone. Our community > considers the introduction of a signed root zone to be an essential > enabling step towards widespread deployment of Secure DNS, DNSSEC. > > It is to be expected that a community as diverse as RIPE cannot have a > unified set of detailed answers to the NTIA questionnaire. However > several > members of the RIPE community will be individually responding to that > questionnaire. We present the following statement as the consensus > view of our community (or the DNS Working Group?) about the principles > that should form the basis of the introduction of a signed DNS root. > > 1. Secure DNS, DNSSEC, is about data authenticity and integrity and > not about control. > > 2. The introduction of DNSSEC to the root zone must be recognised as a > global initiative. > > 3. Addition of DNSSEC to the root zone must be done in a way that does > not compromise the security and stability of the Domain Name System. > > 4. When balancing the various concerns about signing the root zone, > the chosen approach must provide an appropriate level of trust and > confidence by offering a maximally secure technical solution. > > 5. Deployment of a signed root should be done in a timely but not > hasty manner. > > 6. To assist with a timely deployment, any procedural changes > introduced by DNSSEC should be aligned with the current process for > coordinating changes to and the distribution of the root zone. However > those procedural changes should provide sufficient flexibility to > allow for the roles and processes as well as the entities holding > those roles to be changed after suitable consultations have taken > place. > > 7. Policies and processes for signing the root zone should make it > easy for TLDs to supply keys and credentials so the delegations for > those TLDs can benefit from a common DNSSEC trust anchor, the signed > root. > > 8. There is no technical justification to create a new organisation to > oversee the process of signing of the root. > > 9. No data should be moved between organisations without appropriate > authenticity and integrity checking. > > 10. The public part of the key signing key must be distributed as > widely as possible. > > 11. The organisation that generates the root zone file must sign the > file and therefore hold the private part of the zone signing key. > > 12. Changes to the entities and roles in the signing process must not > necessarily require a change of keys. > > From bmanning at vacation.karoshi.com Fri Nov 7 16:57:24 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 7 Nov 2008 15:57:24 +0000 Subject: [dns-wg] final? draft of NTIA response In-Reply-To: <20081107121943.GA6869@vacation.karoshi.com.> References: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> <20081107121943.GA6869@vacation.karoshi.com.> Message-ID: <20081107155724.GA8592@vacation.karoshi.com.> so.... this response sounds a bit harsh. let me clarify with a few more words. Although the draft response does not reflect my views, I accept it can go forward as a consensus view of the WG. I encourage folks w/ divergent views to respond to the NOI on their own. --bill On Fri, Nov 07, 2008 at 12:19:43PM +0000, bmanning at vacation.karoshi.com wrote: > > this is a great piece of work ... and I CAN NOT support it. > > --bill > > > On Fri, Nov 07, 2008 at 12:07:00PM +0000, Jim Reid wrote: > > Colleagues, here is what I hope is the final draft of our response to > > the NTIA. I trust we can reach consensus on this. There is very little > > time to continue with update/review cycles, so I would appreciate if > > any comments were confined to showstoppers. We might have reservations > > or quibbles about some of the detail or phrasing. However unless these > > materially affect the response, could I ask you to please keep these > > to yourself? My worry here is that further tweaks lead to yet more > > comments and tweaks, and this goes on and on and on. The current > > langauge may not be perfect. However I hope it is something that we > > can all agree is good enough. > > > > I would also ask WG members to say they support the text (assuming you > > do of course). It would be better to have positive statements of > > support instead of declaring that silence on this topic is consensus > > for the WG. > > > > > > # > > # $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $ > > # > > > > The RIPE community (or DNS WG?) thanks the NTIA for its consultation > > on proposals to sign the root and is pleased to offer the following > > response to that consultation. We urge the adoption of a solution that > > leads to the prompt introduction of a signed root zone. Our community > > considers the introduction of a signed root zone to be an essential > > enabling step towards widespread deployment of Secure DNS, DNSSEC. > > > > It is to be expected that a community as diverse as RIPE cannot have a > > unified set of detailed answers to the NTIA questionnaire. However > > several > > members of the RIPE community will be individually responding to that > > questionnaire. We present the following statement as the consensus > > view of our community (or the DNS Working Group?) about the principles > > that should form the basis of the introduction of a signed DNS root. > > > > 1. Secure DNS, DNSSEC, is about data authenticity and integrity and > > not about control. > > > > 2. The introduction of DNSSEC to the root zone must be recognised as a > > global initiative. > > > > 3. Addition of DNSSEC to the root zone must be done in a way that does > > not compromise the security and stability of the Domain Name System. > > > > 4. When balancing the various concerns about signing the root zone, > > the chosen approach must provide an appropriate level of trust and > > confidence by offering a maximally secure technical solution. > > > > 5. Deployment of a signed root should be done in a timely but not > > hasty manner. > > > > 6. To assist with a timely deployment, any procedural changes > > introduced by DNSSEC should be aligned with the current process for > > coordinating changes to and the distribution of the root zone. However > > those procedural changes should provide sufficient flexibility to > > allow for the roles and processes as well as the entities holding > > those roles to be changed after suitable consultations have taken > > place. > > > > 7. Policies and processes for signing the root zone should make it > > easy for TLDs to supply keys and credentials so the delegations for > > those TLDs can benefit from a common DNSSEC trust anchor, the signed > > root. > > > > 8. There is no technical justification to create a new organisation to > > oversee the process of signing of the root. > > > > 9. No data should be moved between organisations without appropriate > > authenticity and integrity checking. > > > > 10. The public part of the key signing key must be distributed as > > widely as possible. > > > > 11. The organisation that generates the root zone file must sign the > > file and therefore hold the private part of the zone signing key. > > > > 12. Changes to the entities and roles in the signing process must not > > necessarily require a change of keys. > > > > From jim at rfc1035.com Fri Nov 7 17:02:44 2008 From: jim at rfc1035.com (Jim Reid) Date: Fri, 7 Nov 2008 16:02:44 +0000 Subject: [dns-wg] final? draft of NTIA response In-Reply-To: <20081107155724.GA8592@vacation.karoshi.com.> References: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> <20081107121943.GA6869@vacation.karoshi.com.> <20081107155724.GA8592@vacation.karoshi.com.> Message-ID: <24DAF0C5-250B-4394-B593-874E9FEB549B@rfc1035.com> On Nov 7, 2008, at 15:57, bmanning at vacation.karoshi.com wrote: > so.... this response sounds a bit harsh. let me clarify with a few > more words. Although the draft response does not reflect my views, I > accept it can go forward as a consensus view of the WG. > > I encourage folks w/ divergent views to respond to the NOI on their > own. Thanks Bill. Much appreciated. From mohsen.souissi at nic.fr Fri Nov 7 18:52:16 2008 From: mohsen.souissi at nic.fr (Mohsen Souissi) Date: Fri, 7 Nov 2008 18:52:16 +0100 Subject: [dns-wg] final? draft of NTIA response In-Reply-To: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> References: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> Message-ID: <20081107175216.GK90760@kerkenna.nic.fr> Jim &all, Thank you for all the efforts you put in this work and congratulations for the result. It appears to me that the reservations I raised in Dubai about the risk our text be interpreted as an endorsement of the current process/actors have been well addressed in the recent versions. Now, speaking individuall as a member of this working group, I support this text as is* and I'm in favor of moving it forward at least as a DNS-WG document (if we happened not to get a consensus at the RIPE meeting level). Mohsen. * "Le mieux est l'ennemi du bien" as we say in French and further improvements which are of course possible would be too energy/time-consuming for editors and for the wg. On 07 Nov, Jim Reid wrote: | Colleagues, here is what I hope is the final draft of our response to | the NTIA. I trust we can reach consensus on this. There is very little | time to continue with update/review cycles, so I would appreciate if | any comments were confined to showstoppers. We might have reservations | or quibbles about some of the detail or phrasing. However unless these | materially affect the response, could I ask you to please keep these | to yourself? My worry here is that further tweaks lead to yet more | comments and tweaks, and this goes on and on and on. The current | langauge may not be perfect. However I hope it is something that we | can all agree is good enough. | | I would also ask WG members to say they support the text (assuming you | do of course). It would be better to have positive statements of | support instead of declaring that silence on this topic is consensus | for the WG. | | | # | # $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $ | # | | The RIPE community (or DNS WG?) thanks the NTIA for its consultation | on proposals to sign the root and is pleased to offer the following | response to that consultation. We urge the adoption of a solution that | leads to the prompt introduction of a signed root zone. Our community | considers the introduction of a signed root zone to be an essential | enabling step towards widespread deployment of Secure DNS, DNSSEC. | | It is to be expected that a community as diverse as RIPE cannot have a | unified set of detailed answers to the NTIA questionnaire. However | several | members of the RIPE community will be individually responding to that | questionnaire. We present the following statement as the consensus | view of our community (or the DNS Working Group?) about the principles | that should form the basis of the introduction of a signed DNS root. | | 1. Secure DNS, DNSSEC, is about data authenticity and integrity and | not about control. | | 2. The introduction of DNSSEC to the root zone must be recognised as a | global initiative. | | 3. Addition of DNSSEC to the root zone must be done in a way that does | not compromise the security and stability of the Domain Name System. | | 4. When balancing the various concerns about signing the root zone, | the chosen approach must provide an appropriate level of trust and | confidence by offering a maximally secure technical solution. | | 5. Deployment of a signed root should be done in a timely but not | hasty manner. | | 6. To assist with a timely deployment, any procedural changes | introduced by DNSSEC should be aligned with the current process for | coordinating changes to and the distribution of the root zone. However | those procedural changes should provide sufficient flexibility to | allow for the roles and processes as well as the entities holding | those roles to be changed after suitable consultations have taken | place. | | 7. Policies and processes for signing the root zone should make it | easy for TLDs to supply keys and credentials so the delegations for | those TLDs can benefit from a common DNSSEC trust anchor, the signed | root. | | 8. There is no technical justification to create a new organisation to | oversee the process of signing of the root. | | 9. No data should be moved between organisations without appropriate | authenticity and integrity checking. | | 10. The public part of the key signing key must be distributed as | widely as possible. | | 11. The organisation that generates the root zone file must sign the | file and therefore hold the private part of the zone signing key. | | 12. Changes to the entities and roles in the signing process must not | necessarily require a change of keys. From dwmalone at maths.tcd.ie Fri Nov 7 19:26:44 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Fri, 07 Nov 2008 18:26:44 +0000 Subject: [dns-wg] NTIA response - v5 In-Reply-To: Your message of "Fri, 07 Nov 2008 11:36:30 GMT." Message-ID: <200811071826.aa56364@walton.maths.tcd.ie> (I seem to have lost the message I actually wanted to reply to...) FWIW, I've been lurking and following the discussion. The current response seems sensible to me. I guess it is obvious that the NTIA can come back to us and for further discussion/clarification? David. From richard.lamb at icann.org Fri Nov 7 20:10:30 2008 From: richard.lamb at icann.org (Richard Lamb) Date: Fri, 7 Nov 2008 11:10:30 -0800 Subject: [dns-wg] final? draft of NTIA response In-Reply-To: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> References: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> Message-ID: <05B243F724B2284986522B6ACD0504D788D79952F8@EXVPMBX100-1.exc.icann.org> No hats. Speaking only as an old kernel/network stack programmer and someone who at one time had to work with various US govt agencies including NTIA. And who just wants to see this done in both a timely, secure, and stable fashion. And believing that with the changing US Administration - "yes, we can change" how things are done. I don't care who signs the root just as long as it is done securely, timely and we don't lock ourselves into anything - organizationally or technically. DNSSEC deployment seems like an evolving process technically and politically. > -----Original Message----- > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of > Jim Reid > Sent: Friday, November 07, 2008 2:07 PM > To: dns-wg at ripe.net > Subject: [dns-wg] final? draft of NTIA response > > Colleagues, here is what I hope is the final draft of our response to > the NTIA. I trust we can reach consensus on this. There is very little > time to continue with update/review cycles, so I would appreciate if > any comments were confined to showstoppers. We might have reservations > or quibbles about some of the detail or phrasing. However unless these > materially affect the response, could I ask you to please keep these > to yourself? My worry here is that further tweaks lead to yet more > comments and tweaks, and this goes on and on and on. The current > langauge may not be perfect. However I hope it is something that we > can all agree is good enough. > > I would also ask WG members to say they support the text (assuming you > do of course). It would be better to have positive statements of > support instead of declaring that silence on this topic is consensus > for the WG. > > > # > # $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $ > # > > The RIPE community (or DNS WG?) thanks the NTIA for its consultation > on proposals to sign the root and is pleased to offer the following > response to that consultation. We urge the adoption of a solution that > leads to the prompt introduction of a signed root zone. Our community Replace this sentence with: "We urge the development of a solution that leads to the prompt introduction of a signed root zone." The NTIA NOI is asking YOU to design it. Not for you to accept or adopt another's solution. Nothing is cast in stone. Be as technical as you want to be. They are looking for technical feedback. > considers the introduction of a signed root zone to be an essential > enabling step towards widespread deployment of Secure DNS, DNSSEC. > > It is to be expected that a community as diverse as RIPE cannot have a > unified set of detailed answers to the NTIA questionnaire. However > several > members of the RIPE community will be individually responding to that > questionnaire. We present the following statement as the consensus > view of our community (or the DNS Working Group?) about the principles > that should form the basis of the introduction of a signed DNS root. > > 1. Secure DNS, DNSSEC, is about data authenticity and integrity and > not about control. > > 2. The introduction of DNSSEC to the root zone must be recognised as a > global initiative. Looking at this from DoC/NTIA's eyes, this says DNSSEC can NOT be deployed till all the worlds governments come to them and say they want it. If this is your intent, it is not my place to argue. Its fine. But if it not, this has to be reworded. If the intent is to say that DNSSEC at the root must be implemented/deployed in a way that is recognized (trusted?) by the world, then id suggest: "The introduction of DNSSEC to the root zone must be made in such a way as to be globally recognised." > > 3. Addition of DNSSEC to the root zone must be done in a way that does > not compromise the security and stability of the Domain Name System. This reads (again reading it in my old job capacity) a bit like you do not want DNSSEC. Again, if that's the view, that's fine. However, if not I would say: "Addition of DNSSEC to the root zone must be done in a way that only enhances the security and stability of the Domain Name System." OR "Addition of DNSSEC to the root zone must be done in a way that does not negatively impact the security and stability of the Domain Name System." > > 4. When balancing the various concerns about signing the root zone, > the chosen approach must provide an appropriate level of trust and > confidence by offering a maximally secure technical solution. We are not choosing what they give us. We are telling them how to design it. So I would say "developed" instead of "chosen". Left out "technical" to not suggest specifics about HSM's or facilities or what have you since these are general point. "When balancing the various concerns about signing the root zone, the approach developed must provide an appropriate level of trust and confidence by offering a maximally secure solution." > > 5. Deployment of a signed root should be done in a timely but not > hasty manner. > > 6. To assist with a timely deployment, any procedural changes > introduced by DNSSEC should be aligned with the current process for > coordinating changes to and the distribution of the root zone. However > those procedural changes should provide sufficient flexibility to > allow for the roles and processes as well as the entities holding > those roles to be changed after suitable consultations have taken > place. I strongly believe the first sentence would still be read by USG folk as saying you want the root DNSSEC implementation to not change the current IANA-NTIA-VeriSign arrangement in the slightest. If this is what you want, this is fine. However, the NOI is asking for your technical input not constrained by policy or current structures. Why not think outside this old box? Might be easier to change in this new US Administration and I think bringing in the techies from NIST on this one bodes well for NTIA. I truly believe this is an opportunity to build a secure, and yes timely, solution. Most of the world's DNNSEC experience is in RIPE! With respect to the second sentence. It also strongly suggests changes to the current troika would be hard to come by - again policy issues. Just as a newbie observer, I have the sense that if VeriSign starts performing the signing function as part of its separate CRADA contract with NTIA, it will likely never move to another organization (whereas the IANA function is designed to be moved.. I know.. unlikely but I invite you to look at the IANA and CRADA contracts - really .. definitely no hats). Tell me if I am wrong. Again, if you are happy with the current arrangement and want it to stay that way, that's fine. If however the idea is to get DNSSEC deployed fast but not hastily, that was already said elsewhere. So I would remove this point. As it stands it clearly tells NTIA to select VeriSign...and again if this is what people want, that would be fine with me since as an American it gives me strong legal rights regarding corporations. Just seems like moving a root signing system from one place to another, though I see no technical problems with it, will be "made difficult" with various technical and managerial arguments once it is in place. This would mean the hope for a non-US corp signed root gets even dimmer. Assuming the current roles are frozen or cannot be changed in a timely fashion and that we therefore must live by them is a policy issue. It may be hard to separate tech and policy issues here but if we are willing to touch on policy, I would like to make these points slightly differently. Ill watch the list. > > 7. Policies and processes for signing the root zone should make it > easy for TLDs to supply keys and credentials so the delegations for > those TLDs can benefit from a common DNSSEC trust anchor, the signed > root. > > 8. There is no technical justification to create a new organisation to > oversee the process of signing of the root. > > 9. No data should be moved between organisations without appropriate > authenticity and integrity checking. Again, I get the sense that an artificial constraint on technical designs is being placed here by assuming multiple physically separate organizations. If this is what you want, that's fine. However a more general statement would be: "If data is moved between organizations, it should be with appropriate authenticity and integrity checking." > > 10. The public part of the key signing key must be distributed as > widely as possible. Anyone could generate a key and publish its public half widely but it would not be any good unless users trust it, e.g., accept it as having been generated and managed in an acceptable way for them. So I suggest: "The public part of the widely agreed to key signing key must be distributed as widely as possible." > > 11. The organisation that generates the root zone file must sign the > file and therefore hold the private part of the zone signing key. > > 12. Changes to the entities and roles in the signing process must not > necessarily require a change of keys. > > -Rick From dougb at dougbarton.us Fri Nov 7 21:37:01 2008 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 07 Nov 2008 12:37:01 -0800 Subject: [dns-wg] final? draft of NTIA response In-Reply-To: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> References: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> Message-ID: <4914A6ED.40805@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Sorry to enter the discussion late, but I have a couple comments and hopefully helpful suggestions. I've ellided anything that I agree with. I should also add that I think the WG presenting a position on this is an excellent idea, and I commend Jim for his hard work and patience on this. Jim Reid wrote: > # > # $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $ > # > > The RIPE community (or DNS WG?) I'd say "The RIPE DNS Working Group" here, and "the Working Group" hereafter. > It is to be expected that a community as diverse as RIPE cannot have a > unified set of detailed answers to the NTIA questionnaire. > However I would say "Therefore" here. > several > members of the RIPE community will be individually responding to that > questionnaire. > 5. Deployment of a signed root should be done in a timely but not > hasty manner. To my tastes this sounds a little too much like "diplo-speak." That sentence doesn't have any technical meaning, so if we are presenting ourselves as technologists I would not say this at all, or at least say it differently. > 6. To assist with a timely deployment, any procedural changes > introduced by DNSSEC should be aligned with the current process for > coordinating changes to and the distribution of the root zone. However > those procedural changes should provide sufficient flexibility to > allow for the roles and processes as well as the entities holding > those roles to be changed after suitable consultations have taken > place. Again, I can't find any actual meaning in that paragraph. > 7. Policies and processes for signing the root zone should make it > easy for TLDs to supply keys and credentials so the delegations for > those TLDs can benefit from a common DNSSEC trust anchor, the signed > root. I don't like this one at all, as "easy" has no technical meaning, and it's way too generic. I also think that the bit about "benefiting from a common trust anchor" deserves its own line item given that it's a major motivating factor for signing the root. How about something like: Because DNSSEC keys have technical properties similar to name server delegation records the procedure for submitting and authenticating keys should be very similar, if not identical to that of submitting delegation records. > 9. No data should be moved between organisations related to the process of editing, publishing, or signing the root zone > without appropriate > authenticity and integrity checking. > > 10. The public part of the key signing key must be distributed as > widely as possible. Once again IMO this sentence has no technical meaning, but I would not object to it being included. > 11. The organisation that generates the root zone file must sign the > file and therefore hold the private part of the zone signing key. I get very icky feelings reading this sentence. Not sure why yet ... hth, Doug ObDisclaimer: Speaking only for myself, and not for any past, future, present, or inter-dimensional employers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEAREDAAYFAkkUpuwACgkQyIakK9Wy8PviPACgpeTvoe81+QAkr0KSD6yVVFlR vNIAoI+mIHXCn/HmNOesE9jZawjDx7YQ =Kc1/ -----END PGP SIGNATURE----- From paf at cisco.com Sat Nov 8 15:31:06 2008 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sat, 8 Nov 2008 15:31:06 +0100 Subject: [dns-wg] Input from the ICANN meeting in Cairo Message-ID: <1E909F7C-1BB7-42DF-B67E-DC86D2B0EDBE@cisco.com> In Cairo, I was thinking of what we have written so far, and find that the conclusions people draw from the text we have so far is not consistent with what I think was said at the RIPE meeting in Dubai. I will suggest text, but wanted to rise these two things asap: - I did NOT hear at the RIPE meeting in Dubai any specific preference for either of IANA or Verisign as the holder of any keys. That said, I did hear some voices that felt "IANA is the natural trust anchor today for the DNS namespace, and because of that they should also hold the KSK". I did not hear any similar voice for Verisign. - I have heard last week more voices that think one should look carefully at the whole chain of trust from the TLD via the root to the resolver. And point out the whole chain is important. This include at where/when the zone is signed. I hear some people saying it is good if the DS record passed from the TLD is signed as soon as possible (by the organisation that receive the DS, today IANA). To let the rubber hit the road: These _technical_ arguments argue for a zone signing by the organisation receiving the DS, and therefore the ZSK should be held by that organisation. This imply further a move of the zone creation from Verisign to IANA. So, I see the following alternatives being the dominant ones: 1. No change in the current structure. ZSK should be with Verisign as Verisign is zone creator. KSK stays also with Verisign so that KSK and ZSK are close to each other. Security of DS when moving DS from IANA to Verisign is unclear, and trust chain from IANA (that we trust for the root of the namespace) and the KSK that Verisign holds is unclear. 2. No change in the current structure. ZSK should be with Verisign as Verisign is zone creator. KSK held by IANA. Namespace root and KSK held by IANA, so trust chain is simple to see. Security of DS when moving DS from IANA to Verisign is unclear. 3. Zone signing is with IANA, so IANA send signed records to Verisign. This imply a change in the current structure as more than the record changed is sent to Verisign (also NSEC etc). ZSK should be with IANA. KSK held by IANA. Namespace root and KSK held by IANA, so trust chain is simple to see. Security of DS is clear as it is signed when received by IANA. Then on top of this, we could have alternatives like whether the "control over the keys" should be via some multiple-password systems like suggested by Verisign, or split-key, or whether the community can "simply" trust whoever is going to hold the keys (via open key ceremonies etc). I think my question is, should reply from RIPE list alternatives in a way similar to this (I do not claim the above is perfect), so that it is easier for "whoever make the decision" can count plusses and minuses from their point of view? Something I think should be possible already with the current list of bullets, if one just make some of the points more clear and down to earth and not so much hand waving. Patrik From dburk at burkov.aha.ru Sat Nov 8 21:17:44 2008 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sat, 08 Nov 2008 23:17:44 +0300 Subject: [dns-wg] Input from the ICANN meeting in Cairo In-Reply-To: <1E909F7C-1BB7-42DF-B67E-DC86D2B0EDBE@cisco.com> References: <1E909F7C-1BB7-42DF-B67E-DC86D2B0EDBE@cisco.com> Message-ID: <4915F3E8.2020407@burkov.aha.ru> Patrik F?ltstr?m wrote: Patrick, I strongly support yuor's and Jim's efforts to get consensuson our statement. I don't even comment Doug's reply on dns-wg proposed statement - I simply can't accept his proposals. Regarding your points:(not your personally - just a comments): 1.We (here I am Russian) can't accept any scheme where we should sign something under USG legislation(it is enough easy - if we have no trust - what's meaning for digital signature - any questions?) - It does means that we don't need secure network. 2. We will have a great problem to use any foreign cryptography - but it seems it can be solved on the same approach as biometrics passports today. 3. It is clear that in current situation we will have more chances to find a common solution as it will be more flexible and will reflect current reality. 4. Raising issue on DNSSEC practically destroyed current status de-facto! system of DNS root legitimacy - imho it was the greatest mistake (if someone can understand - drop me personal message - I don't want to be a flamer). Dima without any hats = hope you can understand me. > In Cairo, I was thinking of what we have written so far, and find that > the conclusions people draw from the text we have so far is not > consistent with what I think was said at the RIPE meeting in Dubai. > > I will suggest text, but wanted to rise these two things asap: > > - I did NOT hear at the RIPE meeting in Dubai any specific preference > for either of IANA or Verisign as the holder of any keys. That said, I > did hear some voices that felt "IANA is the natural trust anchor today > for the DNS namespace, and because of that they should also hold the > KSK". I did not hear any similar voice for Verisign. > > - I have heard last week more voices that think one should look > carefully at the whole chain of trust from the TLD via the root to the > resolver. And point out the whole chain is important. This include at > where/when the zone is signed. I hear some people saying it is good if > the DS record passed from the TLD is signed as soon as possible (by > the organisation that receive the DS, today IANA). > > To let the rubber hit the road: These _technical_ arguments argue for > a zone signing by the organisation receiving the DS, and therefore the > ZSK should be held by that organisation. This imply further a move of > the zone creation from Verisign to IANA. > > So, I see the following alternatives being the dominant ones: > > 1. No change in the current structure. ZSK should be with Verisign as > Verisign is zone creator. KSK stays also with Verisign so that KSK and > ZSK are close to each other. Security of DS when moving DS from IANA > to Verisign is unclear, and trust chain from IANA (that we trust for > the root of the namespace) and the KSK that Verisign holds is unclear. > > 2. No change in the current structure. ZSK should be with Verisign as > Verisign is zone creator. KSK held by IANA. Namespace root and KSK > held by IANA, so trust chain is simple to see. Security of DS when > moving DS from IANA to Verisign is unclear. > > 3. Zone signing is with IANA, so IANA send signed records to Verisign. > This imply a change in the current structure as more than the record > changed is sent to Verisign (also NSEC etc). ZSK should be with IANA. > KSK held by IANA. Namespace root and KSK held by IANA, so trust chain > is simple to see. Security of DS is clear as it is signed when > received by IANA. > > Then on top of this, we could have alternatives like whether the > "control over the keys" should be via some multiple-password systems > like suggested by Verisign, or split-key, or whether the community can > "simply" trust whoever is going to hold the keys (via open key > ceremonies etc). > > I think my question is, should reply from RIPE list alternatives in a > way similar to this (I do not claim the above is perfect), so that it > is easier for "whoever make the decision" can count plusses and > minuses from their point of view? Something I think should be possible > already with the current list of bullets, if one just make some of the > points more clear and down to earth and not so much hand waving. > > Patrik > From dburk at burkov.aha.ru Sat Nov 8 22:15:58 2008 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sun, 09 Nov 2008 00:15:58 +0300 Subject: [dns-wg] NTIA response - v5 In-Reply-To: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> References: <1B4C9D6C-BC28-4C4D-B743-29B37AA6D6A7@rfc1035.com> Message-ID: <4916018E.5040106@burkov.aha.ru> :Jim Reid wrote Jim, I speak in hat as a member of ccTLD .ru dnssec wg. We can support this statement in general too.. For us - it will be most important to get more flexibility in current situation. You should understand that we translated some pieces of text in our ways. and our interpretation in Russion could be different. I am personally think that you and Patrick did a great job. I expect that in result we can give our own statement aligned wittoo.h this one and with Russian translation and interpretation thanks, Dima > I have updated the draft response to reflect today's comments. Aside > from tweaking the introductory paragraph -- I hope this now sets the > right tone without upsetting Stephane -- the significant change was to > move Rick's comments about trust to nomber 4 from number 12 on the > list. This seemed to be a more suitable place for this point. > > Is version 5 of the draft now something that the WG as a whole can > accept? > > PS: Please try to avoid suggestions on cosmetic changes to the text > unless these would improve the clarity. The WG needs to reach > consensus on a statement in a day or two. So we should try to focus on > what we are trying to say rather than how we are actually saying it. > Within reason of course.... > > # > # $Id: ntia-draft,v 1.6 2008/11/05 22:36:42 jim Exp $ > # > > The RIPE community (or DNS WG?) thanks the NTIA for its consultation > on proposals to sign the root and is pleased to offer the following > response to that consultation. We urge the adoption of a solution that > leads to the prompt introduction of a signed root zone. Our community > considers the introduction of a signed root zone to be an essential > enabling step towards widespread deployment of Secure DNS, DNSSEC. > > It is to be expected that a community as diverse as RIPE cannot have a > unified set of detailed answers to the NTIA questionnaire. However > several > members of the RIPE community will be individually responding to that > questionnaire. We present the following statement as the consensus > view of our community (or the DNS Working Group?) about the principles > that should form the basis of the introduction of a signed DNS root. > > 1. Secure DNS, DNSSEC, is about data authenticity and integrity and > not about control. > > 2. The introduction of DNSSEC to the root zone must be recognised as a > global initiative. > > 3. Addition of DNSSEC to the root zone must be done in a way that does > not compromise the security and stability of the Domain Name System. > > 4. When balancing the various concerns about signing the root zone, > the chosen approach must provide an appropriate level of trust and > confidence by offering a maximally secure technical solution. > > 5. Deployment of a signed root should be done in a timely but not > hasty manner. > > 6. To assist with a timely deployment, any procedural changes > introduced by DNSSEC should be aligned with the current process for > coordinating changes to and the distribution of the root zone. However > those procedural changes should provide sufficient flexibility to > allow for the roles and processes as well as the entities holding > those roles to be changed after suitable consultations have taken > place. > > 7. Policies and processes for signing the root zone should make it > easy for TLDs to supply keys and credentials so the delegations for > those TLDs can be signed. > > 8. There is no technical justification to create a new organisation to > oversee the process of signing of the root. > > 9. No data should be moved between organisations without appropriate > authenticity and integrity checking. > > 10. The public part of the key signing key must be distributed as > widely as possible. > > 11. The organisation that generates the root zone file must sign the > file and therefore hold the private part of the zone signing key. > > 12. Changes to the entities and roles in the signing process must not > necessarily require a change of keys. > From dburk at burkov.aha.ru Sat Nov 8 22:38:44 2008 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sun, 09 Nov 2008 00:38:44 +0300 Subject: [dns-wg] final? draft of NTIA response In-Reply-To: <20081107175216.GK90760@kerkenna.nic.fr> References: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> <20081107175216.GK90760@kerkenna.nic.fr> Message-ID: <491606E4.7000509@burkov.aha.ru> Mohsen Souissi wrote:you > Jim &all > Mohsen, I can just support you as I expected the same interpration. Dima > Thank you for all the efforts you put in this work and congratulations > for the result. > > It appears to me that the reservations I raised in Dubai about the > risk our text be interpreted as an endorsement of the current > process/actors have been well addressed in the recent versions. > > Now, speaking individuall as a member of this working group, I support > this text as is* and I'm in favor of moving it forward at least as a > DNS-WG document (if we happened not to get a consensus at the RIPE > meeting level). > > Mohsen. > > * "Le mieux est l'ennemi du bien" as we say in French and further > improvements which are of course possible would be too > energy/time-consuming for editors and for the wg. > > On 07 Nov, Jim Reid wrote: > | Colleagues, here is what I hope is the final draft of our response to > | the NTIA. I trust we can reach consensus on this. There is very little > | time to continue with update/review cycles, so I would appreciate if > | any comments were confined to showstoppers. We might have reservations > | or quibbles about some of the detail or phrasing. However unless these > | materially affect the response, could I ask you to please keep these > | to yourself? My worry here is that further tweaks lead to yet more > | comments and tweaks, and this goes on and on and on. The current > | langauge may not be perfect. However I hope it is something that we > | can all agree is good enough. > | > | I would also ask WG members to say they support the text (assuming you > | do of course). It would be better to have positive statements of > | support instead of declaring that silence on this topic is consensus > | for the WG. > | > | > | # > | # $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $ > | # > | > | The RIPE community (or DNS WG?) thanks the NTIA for its consultation > | on proposals to sign the root and is pleased to offer the following > | response to that consultation. We urge the adoption of a solution that > | leads to the prompt introduction of a signed root zone. Our community > | considers the introduction of a signed root zone to be an essential > | enabling step towards widespread deployment of Secure DNS, DNSSEC. > | > | It is to be expected that a community as diverse as RIPE cannot have a > | unified set of detailed answers to the NTIA questionnaire. However > | several > | members of the RIPE community will be individually responding to that > | questionnaire. We present the following statement as the consensus > | view of our community (or the DNS Working Group?) about the principles > | that should form the basis of the introduction of a signed DNS root. > | > | 1. Secure DNS, DNSSEC, is about data authenticity and integrity and > | not about control. > | > | 2. The introduction of DNSSEC to the root zone must be recognised as a > | global initiative. > | > | 3. Addition of DNSSEC to the root zone must be done in a way that does > | not compromise the security and stability of the Domain Name System. > | > | 4. When balancing the various concerns about signing the root zone, > | the chosen approach must provide an appropriate level of trust and > | confidence by offering a maximally secure technical solution. > | > | 5. Deployment of a signed root should be done in a timely but not > | hasty manner. > | > | 6. To assist with a timely deployment, any procedural changes > | introduced by DNSSEC should be aligned with the current process for > | coordinating changes to and the distribution of the root zone. However > | those procedural changes should provide sufficient flexibility to > | allow for the roles and processes as well as the entities holding > | those roles to be changed after suitable consultations have taken > | place. > | > | 7. Policies and processes for signing the root zone should make it > | easy for TLDs to supply keys and credentials so the delegations for > | those TLDs can benefit from a common DNSSEC trust anchor, the signed > | root. > | > | 8. There is no technical justification to create a new organisation to > | oversee the process of signing of the root. > | > | 9. No data should be moved between organisations without appropriate > | authenticity and integrity checking. > | > | 10. The public part of the key signing key must be distributed as > | widely as possible. > | > | 11. The organisation that generates the root zone file must sign the > | file and therefore hold the private part of the zone signing key. > | > | 12. Changes to the entities and roles in the signing process must not > | necessarily require a change of keys. > > From patrik at frobbit.se Sat Nov 8 15:21:03 2008 From: patrik at frobbit.se (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sat, 8 Nov 2008 15:21:03 +0100 Subject: [dns-wg] Input from the ICANN meeting in Cairo Message-ID: <535B3CEC-FA20-4AD3-B433-4889F76DDD4F@frobbit.se> In Cairo, I was thinking of what we have written so far, and find that the conclusions people draw from the text we have so far is not consistent with what I think was said at the RIPE meeting in Dubai. I will suggest text, but wanted to rise these two things asap: - I did NOT hear at the RIPE meeting in Dubai any specific preference for either of IANA or Verisign as the holder of any keys. That said, I did hear some voices that felt "IANA is the natural trust anchor today for the DNS namespace, and because of that they should also hold the KSK". I did not hear any similar voice for Verisign. - I have heard last week more voices that think one should look carefully at the whole chain of trust from the TLD via the root to the resolver. And point out the whole chain is important. This include at where/when the zone is signed. I hear some people saying it is good if the DS record passed from the TLD is signed as soon as possible (by the organisation that receive the DS, today IANA). To let the rubber hit the road: These _technical_ arguments argue for a zone signing by the organisation receiving the DS, and therefore the ZSK should be held by that organisation. This imply further a move of the zone creation from Verisign to IANA. So, I see the following alternatives being the dominant ones: 1. No change in the current structure. ZSK should be with Verisign as Verisign is zone creator. KSK stays also with Verisign so that KSK and ZSK are close to each other. Security of DS when moving DS from IANA to Verisign is unclear, and trust chain from IANA (that we trust for the root of the namespace) and the KSK that Verisign holds is unclear. 2. No change in the current structure. ZSK should be with Verisign as Verisign is zone creator. KSK held by IANA. Namespace root and KSK held by IANA, so trust chain is simple to see. Security of DS when moving DS from IANA to Verisign is unclear. 3. Zone signing is with IANA, so IANA send signed records to Verisign. This imply a change in the current structure as more than the record changed is sent to Verisign (also NSEC etc). ZSK should be with IANA. KSK held by IANA. Namespace root and KSK held by IANA, so trust chain is simple to see. Security of DS is clear as it is signed when received by IANA. Then on top of this, we could have alternatives like whether the "control over the keys" should be via some multiple-password systems like suggested by Verisign, or split-key, or whether the community can "simply" trust whoever is going to hold the keys (via open key ceremonies etc). I think my question is, should reply from RIPE list alternatives in a way similar to this (I do not claim the above is perfect), so that it is easier for "whoever make the decision" can count plusses and minuses from their point of view? Something I think should be possible already with the current list of bullets, if one just make some of the points more clear and down to earth and not so much hand waving. Patrik From jim at rfc1035.com Mon Nov 10 09:57:23 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 10 Nov 2008 08:57:23 +0000 Subject: [dns-wg] one more effort on the NTIA response Message-ID: Colleagues, I am sorry to say that we have still not reached consensus on the proposed response to the NTIA NoI. After discussing this yesterday the WG co-chairs felt that further work is needed. We have also had reliable feedback that Friday's draft was being misinterpreted by some of the likely audience for this response outside the WG. I have taken guidance from an informal editing group to tweak the response to clear up the ambiguity and potential for misunderstanding. So we now have an updated draft response to consider. The intention is still to try and get consensus in the WG, ideally on the text below. If that can be achieved in the next few days, we will then endeavour to get consensus from the RIPE community. And if that is done, the agreed text will go to NTIA as a statement of the RIPE community. The NTIA deadline makes this a delicate balancing act. On the one hand, there's little time left for further discussion. On the other, there needs to be reasonable discussion time in both the WG and RIPE lists so that the validity of our procedures are not undermined. Please bear this in mind before commenting about the latest draft on the list. Please take a look at the latest revised version below. As before, I would ask you to only comment about any matters that you consider to be showstoppers and provide suggested alternate text. Please try not to focus on minor tweaks to the language as that will divert us all from the matter at hand. And take time we don't really have to spare. Remember too that we're trying to get consensus within the WG. This is hard because there are differing views about how the root could or should be signed. There may be wording in the text below that is not to your personal taste. And other WG members may well be uncomfortable with the stuff in the draft that you like. However I hope we can all agree the latest draft is a fair reflection of the collective view of the WG. Some compromise and good sense from all of us is needed to keep this thing on track. Don't forget that what we're doing here is expressing the view of the WG (or the RIPE community?) *as a whole*. This does not prevent any of you from making your own personal or professional representations to the NTIA, something I encourage all of you to do. If some of the detail is not to your personal taste, please think carefully about whether it's better to handle that inside the WG in the time available or by making a personal submission to NTIA. So unless there's something in the draft below that you think makes us look bad/stupid/ wrong, can I ask for your support on this latest version? Oh, and if you are happy with the latest draft, please say so on the list. Your WG co-chairs will feel a lot more comfortable declaring consensus when there are positive statements to that effect on the list. This is far better than presuming a default of silence implies consent. # # $Id: ntia-draft,v 1.8 2008/11/09 17:28:20 jim Exp $ # The RIPE community (or DNS WG?) thanks the NTIA for its consultation on proposals to sign the root and is pleased to offer the following response to that consultation. We urge the adoption of a solution that leads to the prompt introduction of a signed root zone. Our community considers the introduction of a signed root zone to be an essential enabling step towards widespread deployment of Secure DNS, DNSSEC. It is to be expected that a community as diverse as RIPE cannot have a unified set of detailed answers to the NTIA questionnaire. However several members of the RIPE community will be individually responding to that questionnaire. We present the following statement as the consensus view of our community (or the DNS Working Group?) about the principles that should form the basis of the introduction of a signed DNS root. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control. 2. The introduction of DNSSEC to the root zone must be made in such a way that it is accepted as a global initiative. 3. Addition of DNSSEC to the root zone must be done in a way that does not compromise the security and stability of the Domain Name System. 4. When balancing the various concerns about signing the root zone, the approach must provide an appropriate level of trust and confidence by offering an optimally secure solution. 5. Deployment of a signed root should be done in a timely but not hasty manner. 6. Updates from TLD operators relating to DNSSEC should be aligned with the operational mechanisms for co-ordinating changes to the root zone. 7. If any procedural changes are introduced by the deployment of DNSSEC they should provide sufficient flexibility to allow for the roles and processes as well as the entities holding those roles to be changed after suitable consultations have taken place. 8. Policies and processes for signing the root zone must be transparent and trustworthy, making it straightforward for TLDs to supply keys and credentials so the delegations for those TLDs can benefit from a common DNSSEC trust anchor, the signed root. 9. There is no technical justification to create a new organisation to oversee the process of signing of the root. 10. No data should be moved between organisations without appropriate authenticity and integrity checking, particularly the flow of keying material between a TLD operator and the entity that signs the root. 11. The public part of the key signing key must be distributed as widely as possible. 12. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key. 13. Changes to the entities and roles in the signing process must not necessarily require a change of keys. From dogwallah at gmail.com Mon Nov 10 11:50:21 2008 From: dogwallah at gmail.com (McTim) Date: Mon, 10 Nov 2008 13:50:21 +0300 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: Hi Jim, The latest draft is fine AFAIAC. Count me as +1 -- Cheers, McTim http://stateoftheinternetin.ug From Mats.Dufberg at teliasonera.com Mon Nov 10 12:00:11 2008 From: Mats.Dufberg at teliasonera.com (Mats.Dufberg at teliasonera.com) Date: Mon, 10 Nov 2008 12:00:11 +0100 Subject: [dns-wg] Re: Another DNSSEC action: add your DS to DLV (Was: NTIA NoI: does anyone care? In-Reply-To: <9937734F-3CB0-46C2-B84B-F8254952F4E8@virtualized.org> References: <82iqruw72k.fsf@mid.bfk.de> <2BF5805E-FA39-4CBE-9A38-E184333EA858@virtualized.org> <20081021092558.GC16823@nic.fr> <20081023091608.GA15397@nic.fr> <2706CA5F-C507-4A07-B2F3-DB3EB909DCF2@virtualized.org> <20081024140307.GA21162@laperouse.bortzmeyer.org> <934C363F-1BCB-40ED-B951-4F7377B4EA7D@virtualized.org> <49034D10.90400@psg.com> <9937734F-3CB0-46C2-B84B-F8254952F4E8@virtualized.org> Message-ID: > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On > Behalf Of David Conrad > Sent: den 25 oktober 2008 20:50 (...) > This is NOT what I am claiming. I stated: > > "[...] I personally believe [DLV] is non-scalable, non-standard, and > imputes a highly questionable trust model into _every_ > non-cached DNS lookup [...]." Configuring the resolver (caching nameserver) with a DLV also makes it as dependent on the DLV zone as it is on the root zone. If the DLV zone is unavailable, no DNSsec checking and validation will work and the server will consider all DNS data as untrusted, i.e. returning all queries with SERVFAIL. We run DNSsec validation for some 1.5 million customers with .SE as the sole trust anchor. I will leave the DLV's out for many reasons. Mats ------------------------------------------ Mats Dufberg TeliaSonera BBS P&P VAS/Internet +46-70-2582588 mats.dufberg at teliasonera.com ------------------------------------------ From paf at cisco.com Mon Nov 10 12:09:38 2008 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 10 Nov 2008 12:09:38 +0100 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: Yes, I have been helping with the text, but I still explicitly want to say I support the text as proposed by Jim. Patrik From k13 at nikhef.nl Mon Nov 10 12:14:44 2008 From: k13 at nikhef.nl (Rob Blokzijl) Date: Mon, 10 Nov 2008 12:14:44 +0100 (MET) Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: Yes, I fully support this text as a RIPE community reply to the NTIA questions. Rob From richard.lamb at icann.org Mon Nov 10 17:27:33 2008 From: richard.lamb at icann.org (Richard Lamb) Date: Mon, 10 Nov 2008 08:27:33 -0800 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: <05B243F724B2284986522B6ACD0504D788D79953F7@EXVPMBX100-1.exc.icann.org> Jim- Latest draft is much clearer, I believe even for bureaucrats. Count me as +1. -Rick From sander at steffann.nl Mon Nov 10 18:39:45 2008 From: sander at steffann.nl (Sander Steffann) Date: Mon, 10 Nov 2008 18:39:45 +0100 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: <5135FFCBB823447BA549ED05BF6878E5@10ww.steffann.nl> Hi Jim, > Oh, and if you are happy with the latest draft, please say so on the > list. Your WG co-chairs will feel a lot more comfortable declaring > consensus when there are positive statements to that effect on the > list. This is far better than presuming a default of silence implies > consent. I am happy with the latest draft as sent to the list on November 10th 2008. Sander From Ed.Lewis at neustar.biz Mon Nov 10 19:17:57 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 10 Nov 2008 13:17:57 -0500 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: At 8:57 +0000 11/10/08, Jim Reid wrote: >can I ask for your support on this latest version? I'd be okay with this, in general, except for two things. #1 - I'd be happier without 9 - I mean, just delete it. (Why is it there? Did someone believe there was a technical justification to add an organization?) #2 - I'd be happier if the list wasn't just a set of requirements but included some "here's a way to do it"s. But then, this point is not critical. >9. There is no technical justification to create a new organisation to >oversee the process of signing of the root. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From barbara.roseman at icann.org Mon Nov 10 19:33:19 2008 From: barbara.roseman at icann.org (Barbara Roseman) Date: Mon, 10 Nov 2008 10:33:19 -0800 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: Message-ID: Ed, I believe 9 addresses some of the proposed workflows published with the NOI. It was not in either the VeriSign or ICANN proposals, but was, I believe, in some of the other diagrams. -Barb On 11/10/08 10:17 AM, "Edward Lewis" wrote: At 8:57 +0000 11/10/08, Jim Reid wrote: >can I ask for your support on this latest version? I'd be okay with this, in general, except for two things. #1 - I'd be happier without 9 - I mean, just delete it. (Why is it there? Did someone believe there was a technical justification to add an organization?) #2 - I'd be happier if the list wasn't just a set of requirements but included some "here's a way to do it"s. But then, this point is not critical. >9. There is no technical justification to create a new organisation to >oversee the process of signing of the root. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ed.Lewis at neustar.biz Mon Nov 10 19:48:18 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 10 Nov 2008 13:48:18 -0500 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: In that case, I'll modify my statement to "I'd be happier if #9 was less obtuse (that is, happier if it's intent was more direct or clear). At 10:33 -0800 11/10/08, Barbara Roseman wrote: Ed, I believe 9 addresses some of the proposed workflows published with the NOI. It was not in either the VeriSign or ICANN proposals, but was, I believe, in some of the other diagrams. -Barb On 11/10/08 10:17 AM, "Edward Lewis" <<>Ed.Lewis at neustar.biz> wrote: At 8:57 +0000 11/10/08, Jim Reid wrote: >can I ask for your support on this latest version? I'd be okay with this, in general, except for two things. #1 - I'd be happier without 9 - I mean, just delete it. (Why is it there? Did someone believe there was a technical justification to add an organization?) #2 - I'd be happier if the list wasn't just a set of requirements but included some "here's a way to do it"s. But then, this point is not critical. >9. There is no technical justification to create a new organisation to >oversee the process of signing of the root. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paf at cisco.com Mon Nov 10 20:54:49 2008 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 10 Nov 2008 20:54:49 +0100 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: Correct, that is the reason why #9 is there. Patrik On 10 nov 2008, at 19.33, Barbara Roseman wrote: > Ed, I believe 9 addresses some of the proposed workflows published > with the NOI. It was not in either the VeriSign or ICANN proposals, > but was, I believe, in some of the other diagrams. > > -Barb > > > On 11/10/08 10:17 AM, "Edward Lewis" wrote: > > At 8:57 +0000 11/10/08, Jim Reid wrote: > >> can I ask for your support on this latest version? > > I'd be okay with this, in general, except for two things. > > #1 - I'd be happier without 9 - I mean, just delete it. (Why is it > there? Did someone believe there was a technical justification to > add an organization?) > > #2 - I'd be happier if the list wasn't just a set of requirements but > included some "here's a way to do it"s. But then, this point is not > critical. > >> 9. There is no technical justification to create a new organisation >> to >> oversee the process of signing of the root. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > Edward Lewis > +1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. > > From jim at rfc1035.com Mon Nov 10 23:52:27 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 10 Nov 2008 22:52:27 +0000 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: <3A144905-3270-4487-874E-FBF4EAA4DC07@rfc1035.com> On Nov 10, 2008, at 18:17, Edward Lewis wrote: > #1 - I'd be happier without 9 - I mean, just delete it. (Why is it > there? Did someone believe there was a technical justification to > add an organization?) Ed, aside from the points that have already been explained to you, point 9 counteracts arguments that are likely to be made in other circles to establish/introduce some other entity to oversee the signing of the root. If/when those groups make that claim, there would be at least one emphatic statement from the Internet community refuting it. > #2 - I'd be happier if the list wasn't just a set of requirements > but included some "here's a way to do it"s. But then, this point is > not critical. Well please re-read my introductory notes on the latest draft. The WG does not have a common view of how to sign the root. At least that what the mood seemed to be in Dubai. This is why we've tried to focus on requirements (where we can agree hopefully) than operational detail (where there are divergent opinions). If you want to debate operational details, go ahead. But please don't do that in a way that stops the WG from formulating a response to NTIA. Or you could present those technical details in your own response to the NTIA NoI. From Ed.Lewis at neustar.biz Tue Nov 11 00:12:24 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 10 Nov 2008 18:12:24 -0500 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: <3A144905-3270-4487-874E-FBF4EAA4DC07@rfc1035.com> References: <3A144905-3270-4487-874E-FBF4EAA4DC07@rfc1035.com> Message-ID: At 22:52 +0000 11/10/08, Jim Reid wrote: >On Nov 10, 2008, at 18:17, Edward Lewis wrote: > >> #1 - I'd be happier without 9 - I mean, just delete it. (Why is >>it there? Did someone believe there was a technical justification >>to add an organization?) > >Ed, aside from the points that have already been explained to you, point 9 >counteracts arguments that are likely to be made in other circles to >establish/introduce some other entity to oversee the signing of the root. >If/when those groups make that claim, there would be at least one emphatic >statement from the Internet community refuting it. How about "While there may be reasons supporting the creation or introduction of another organization in the process of signing the root zone, the reasons are not technical in nature." I just think, judging from my reactions to #9, that the wording is not clearly getting the intention across. > >> #2 - I'd be happier if the list wasn't just a set of requirements >>but included some "here's a way to do it"s. But then, this point >>is not critical. > >Well please re-read my introductory notes on the latest draft. The WG does >not have a common view of how to sign the root. At least that what the mood >seemed to be in Dubai. Perhaps therein lies the issue - I wasn't in Dubai. ;) Meaning, all I have to go on is what was posted to the mailing list, not any background discussion. >This is why we've tried to focus on requirements (where we can agree >hopefully) >than operational detail (where there are divergent opinions). This should be in the preamble then. There's no problem with just sticking to requirements, but I was *expecting* that a "DNS WG" was going to give advice on how to do, rather than just what to do. Especially considering that the NTIA includes sample architectures. It isn't that the DNS WG is missing the boat by sticking to requirements. The statement should indicate that. (OK, maybe you do in the last half of the final sentence of the preamble: # "We present the following statement as the consensus view of # our community (or the DNS Working Group?) about the principles # that should form the basis of the introduction of a signed DNS root. ) The $source-of-comments offers the following architectural guidelines when considering a process for signing the root. The $source-of-comments feels that proscribing technical details at this point is premature as there are many different approaches to signing a DNS zone. Yadda, yadda, yadda. What's in the preamble is first an excuse for not proscribing a solution and then saying all we will do is give you principles. My advice here is to first say what you are doing and then later say what you are not. >If you want to debate operational details, go ahead. But please don't do that >in a way that stops the WG from formulating a response to NTIA. Or you could >present those technical details in your own response to the NTIA NoI. I'd said earlier that I'd rather send my thoughts directly to the NTIA as requested than put it on the list. What I'm saying is that the response seems to be lacking directness in it's message. Hence, it reads very political and non-technical. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From jim at rfc1035.com Tue Nov 11 00:32:22 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 10 Nov 2008 23:32:22 +0000 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: <3A144905-3270-4487-874E-FBF4EAA4DC07@rfc1035.com> Message-ID: <1BD829B5-D15E-459D-8506-AC783D0A6FFD@rfc1035.com> On Nov 10, 2008, at 23:12, Edward Lewis wrote: > How about "While there may be reasons supporting the creation or > introduction of another organization in the process of signing the > root zone, the reasons are not technical in nature." This pretty much says the same as what's already there, so no. In fact, your proposed text is far worse. It implies the WG concedes that there are reasons for adding another entity or layer of bureaucracy. That's not what we're saying at all, From dogwallah at gmail.com Tue Nov 11 06:10:52 2008 From: dogwallah at gmail.com (McTim) Date: Tue, 11 Nov 2008 08:10:52 +0300 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: <1BD829B5-D15E-459D-8506-AC783D0A6FFD@rfc1035.com> References: <3A144905-3270-4487-874E-FBF4EAA4DC07@rfc1035.com> <1BD829B5-D15E-459D-8506-AC783D0A6FFD@rfc1035.com> Message-ID: On Tue, Nov 11, 2008 at 2:32 AM, Jim Reid wrote: > On Nov 10, 2008, at 23:12, Edward Lewis wrote: > > How about "While there may be reasons supporting the creation or >> introduction of another organization in the process of signing the root >> zone, the reasons are not technical in nature." >> > > This pretty much says the same as what's already there, so no. In fact, > your proposed text is far worse. It implies the WG concedes that there are > reasons for adding another entity or layer of bureaucracy. agreed, let's NOT open that door! -- Cheers, McTim http://stateoftheinternetin.ug -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles.massen at restena.lu Tue Nov 11 07:54:53 2008 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 11 Nov 2008 07:54:53 +0100 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: <200811110754.53571.gilles.massen@restena.lu> Jim, I'm quite happy with the latest draft. best, Gilles -- Fondation RESTENA - DNS-LU From sanz at denic.de Tue Nov 11 09:17:39 2008 From: sanz at denic.de (Marcos Sanz/Denic) Date: Tue, 11 Nov 2008 09:17:39 +0100 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: Message-ID: Jim, speaking as an individual, I support the version 1.8 (latest) of the draft. Best regards Marcos From support at on-communications.com Wed Nov 12 16:33:52 2008 From: support at on-communications.com (Support) Date: Wed, 12 Nov 2008 15:33:52 +0000 Subject: [dns-wg] HELP Message-ID: <6a80e6850811120733w3548119bjf474cba12a93a063@mail.gmail.com> Hello, We are currently experiencing an issue when trying to create a Domain Object within the Ripe Database. Below is a copy of the message response after submitting the form: * From-Host: 91.102.59.133 - Date/Time: Wed Nov 12 16:23:56 2008 SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 1 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Create FAILED: [domain] 60.102.91.in-addr-arpa ***Error: Authorisation failed ***Info: Syntax check passed domain: 60.102.91.in-addr-arpa descr: Reverse Delegation got On-Communication Customers nserver: ns20.netriplex.com changed: support at on-communications.com admin-c: GILL1-RIPE tech-c: GILL1-RIPE zone-c: GILL1-RIPE changed: support at on-communications.com mnt-by: ON-COMMS-MNT source: RIPE ***Warning: Date '20081112' added to changed: attribute ' support at on-communications.com' ***Warning: Date '20081112' added to changed: attribute ' support at on-communications.com' ***Error: More than one changed: attribute without date ***Error: There is no parent object ***Info: Authorisation for [domain] 60.102.91.in-addr-arpa using mnt-by: authenticated by: ON-COMMS-MNT * ** Can you please look into why this is failing, as any help would be greatly appreciated. Kind Regards *Technical Support* Phone: 0114 321 0016 Fax: 0114 242 5336 *www.on-communications.com* ** Sheffield City Airport, Europa Way, Sheffield S9 1XZ t. 08704 296745 f. 08704 296746 P Reduce, Reuse, Recycle ? "Think before you print" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej.sury at nic.cz Wed Nov 12 18:09:27 2008 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Wed, 12 Nov 2008 18:09:27 +0100 Subject: [dns-wg] HELP In-Reply-To: <6a80e6850811120733w3548119bjf474cba12a93a063@mail.gmail.com> References: <6a80e6850811120733w3548119bjf474cba12a93a063@mail.gmail.com> Message-ID: Maybe you should try it with in-addr.arpa suffix instead of in-addr-arpa ? :) 2008/11/12 Support : > Hello, > > We are currently experiencing an issue when trying to create a Domain Object > within the Ripe Database. Below is a copy of the message response after > submitting the form: > > From-Host: 91.102.59.133 > - Date/Time: Wed Nov 12 16:23:56 2008 > > SUMMARY OF UPDATE: > Number of objects found: 1 > Number of objects processed successfully: 0 > Create: 0 > Modify: 0 > Delete: 0 > No Operation: 0 > Number of objects processed with errors: 1 > Create: 1 > Modify: 0 > Delete: 0 > Syntax Errors: 0 > > DETAILED EXPLANATION: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The following object(s) were found to have ERRORS: > > --- > Create FAILED: [domain] 60.102.91.in-addr-arpa > ***Error: Authorisation failed > ***Info: Syntax check passed > > domain: 60.102.91.in-addr-arpa > descr: Reverse Delegation got On-Communication Customers > nserver: ns20.netriplex.com > changed: support at on-communications.com > admin-c: GILL1-RIPE > tech-c: GILL1-RIPE > zone-c: GILL1-RIPE > changed: support at on-communications.com > mnt-by: ON-COMMS-MNT > source: RIPE > ***Warning: Date '20081112' added to changed: attribute > 'support at on-communications.com' > ***Warning: Date '20081112' added to changed: attribute > 'support at on-communications.com' > ***Error: More than one changed: attribute without date > > ***Error: There is no parent object > > ***Info: Authorisation for [domain] 60.102.91.in-addr-arpa > using mnt-by: > authenticated by: ON-COMMS-MNT > > Can you please look into why this is failing, as any help would be greatly > appreciated. > > > > > Kind Regards > > > > Technical Support > > Phone: 0114 321 0016 > > Fax: 0114 242 5336 > > www.on-communications.com > > Sheffield City Airport, Europa Way, Sheffield S9 1XZ > t. 08704 296745 f. 08704 296746 > > P Reduce, Reuse, Recycle ? "Think before you print" > > -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From ondrej.sury at nic.cz Wed Nov 12 18:38:09 2008 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Wed, 12 Nov 2008 18:38:09 +0100 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: > # > # $Id: ntia-draft,v 1.8 2008/11/09 17:28:20 jim Exp $ > # > > The RIPE community (or DNS WG?) thanks the NTIA for its consultation > on proposals to sign the root and is pleased to offer the following > response to that consultation. We urge the adoption of a solution that > leads to the prompt introduction of a signed root zone. Our community > considers the introduction of a signed root zone to be an essential > enabling step towards widespread deployment of Secure DNS, DNSSEC. > > It is to be expected that a community as diverse as RIPE cannot have a > unified set of detailed answers to the NTIA questionnaire. However several > members of the RIPE community will be individually responding to that > questionnaire. We present the following statement as the consensus > view of our community (or the DNS Working Group?) about the principles > that should form the basis of the introduction of a signed DNS root. > > 1. Secure DNS, DNSSEC, is about data authenticity and integrity and > not about control. > > 2. The introduction of DNSSEC to the root zone must be made in such a > way that it is accepted as a global initiative. > > 3. Addition of DNSSEC to the root zone must be done in a way that does > not compromise the security and stability of the Domain Name System. > > 4. When balancing the various concerns about signing the root zone, > the approach must provide an appropriate level of trust and confidence > by offering an optimally secure solution. > > 5. Deployment of a signed root should be done in a timely but not > hasty manner. > > 6. Updates from TLD operators relating to DNSSEC should be aligned > with the operational mechanisms for co-ordinating changes to the root > zone. > > 7. If any procedural changes are introduced by the deployment of > DNSSEC they should provide sufficient flexibility to allow for the > roles and processes as well as the entities holding those roles to be > changed after suitable consultations have taken place. > > 8. Policies and processes for signing the root zone must be > transparent and trustworthy, making it straightforward for TLDs to > supply keys and credentials so the delegations for those TLDs can > benefit from a common DNSSEC trust anchor, the signed root. > > 9. There is no technical justification to create a new organisation to > oversee the process of signing of the root. > > 10. No data should be moved between organisations without appropriate > authenticity and integrity checking, particularly the flow of keying > material between a TLD operator and the entity that signs the root. > > 11. The public part of the key signing key must be distributed as > widely as possible. > > 12. The organisation that generates the root zone file must sign the > file and therefore hold the private part of the zone signing key. > > 13. Changes to the entities and roles in the signing process must not > necessarily require a change of keys. I support this text as a reply to NTIA. Ondrej. -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From Antoin.Verschuren at sidn.nl Thu Nov 13 11:15:12 2008 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 13 Nov 2008 11:15:12 +0100 Subject: [dns-wg] final? draft of NTIA response References: <23A4C755-5A41-415A-84A8-9594DEF607A8@rfc1035.com> Message-ID: <850A39016FA57A4887C0AA3C8085F94948DD13@KAEVS1.SIDN.local> Hi all, I feel comfortable with this response on behalf of the RIPE DNS working group. Well done. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ > -----Original Message----- > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of > Jim Reid > Sent: Friday, November 07, 2008 1:07 PM > To: dns-wg at ripe.net > Subject: [dns-wg] final? draft of NTIA response > > Colleagues, here is what I hope is the final draft of our response to > the NTIA. I trust we can reach consensus on this. There is very little > time to continue with update/review cycles, so I would appreciate if > any comments were confined to showstoppers. We might have reservations > or quibbles about some of the detail or phrasing. However unless these > materially affect the response, could I ask you to please keep these > to yourself? My worry here is that further tweaks lead to yet more > comments and tweaks, and this goes on and on and on. The current > langauge may not be perfect. However I hope it is something that we > can all agree is good enough. > > I would also ask WG members to say they support the text (assuming you > do of course). It would be better to have positive statements of > support instead of declaring that silence on this topic is consensus > for the WG. > > > # > # $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $ > # > > The RIPE community (or DNS WG?) thanks the NTIA for its consultation > on proposals to sign the root and is pleased to offer the following > response to that consultation. We urge the adoption of a solution that > leads to the prompt introduction of a signed root zone. Our community > considers the introduction of a signed root zone to be an essential > enabling step towards widespread deployment of Secure DNS, DNSSEC. > > It is to be expected that a community as diverse as RIPE cannot have a > unified set of detailed answers to the NTIA questionnaire. However > several > members of the RIPE community will be individually responding to that > questionnaire. We present the following statement as the consensus > view of our community (or the DNS Working Group?) about the principles > that should form the basis of the introduction of a signed DNS root. > > 1. Secure DNS, DNSSEC, is about data authenticity and integrity and > not about control. > > 2. The introduction of DNSSEC to the root zone must be recognised as a > global initiative. > > 3. Addition of DNSSEC to the root zone must be done in a way that does > not compromise the security and stability of the Domain Name System. > > 4. When balancing the various concerns about signing the root zone, > the chosen approach must provide an appropriate level of trust and > confidence by offering a maximally secure technical solution. > > 5. Deployment of a signed root should be done in a timely but not > hasty manner. > > 6. To assist with a timely deployment, any procedural changes > introduced by DNSSEC should be aligned with the current process for > coordinating changes to and the distribution of the root zone. However > those procedural changes should provide sufficient flexibility to > allow for the roles and processes as well as the entities holding > those roles to be changed after suitable consultations have taken > place. > > 7. Policies and processes for signing the root zone should make it > easy for TLDs to supply keys and credentials so the delegations for > those TLDs can benefit from a common DNSSEC trust anchor, the signed > root. > > 8. There is no technical justification to create a new organisation to > oversee the process of signing of the root. > > 9. No data should be moved between organisations without appropriate > authenticity and integrity checking. > > 10. The public part of the key signing key must be distributed as > widely as possible. > > 11. The organisation that generates the root zone file must sign the > file and therefore hold the private part of the zone signing key. > > 12. Changes to the entities and roles in the signing process must not > necessarily require a change of keys. > > From Antoin.Verschuren at sidn.nl Thu Nov 13 11:32:30 2008 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 13 Nov 2008 11:32:30 +0100 Subject: [dns-wg] one more effort on the NTIA response References: Message-ID: <850A39016FA57A4887C0AA3C8085F94948DD18@KAEVS1.SIDN.local> Oops, I replied to the wrong email. I meant I feel confortable with this latest version of the draft, 1,8. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ > -----Original Message----- > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of > Jim Reid > Sent: Monday, November 10, 2008 9:57 AM > To: dns-wg at ripe.net > Subject: [dns-wg] one more effort on the NTIA response > > Colleagues, I am sorry to say that we have still not reached consensus > on the proposed response to the NTIA NoI. After discussing this > yesterday the WG co-chairs felt that further work is needed. We have > also had reliable feedback that Friday's draft was being > misinterpreted by some of the likely audience for this response > outside the WG. I have taken guidance from an informal editing group > to tweak the response to clear up the ambiguity and potential for > misunderstanding. So we now have an updated draft response to consider. > > The intention is still to try and get consensus in the WG, ideally on > the text below. If that can be achieved in the next few days, we will > then endeavour to get consensus from the RIPE community. And if that > is done, the agreed text will go to NTIA as a statement of the RIPE > community. The NTIA deadline makes this a delicate balancing act. On > the one hand, there's little time left for further discussion. On the > other, there needs to be reasonable discussion time in both the WG and > RIPE lists so that the validity of our procedures are not undermined. > Please bear this in mind before commenting about the latest draft on > the list. > > Please take a look at the latest revised version below. As before, I > would ask you to only comment about any matters that you consider to > be showstoppers and provide suggested alternate text. Please try not > to focus on minor tweaks to the language as that will divert us all > from the matter at hand. And take time we don't really have to spare. > > Remember too that we're trying to get consensus within the WG. This is > hard because there are differing views about how the root could or > should be signed. There may be wording in the text below that is not > to your personal taste. And other WG members may well be uncomfortable > with the stuff in the draft that you like. However I hope we can all > agree the latest draft is a fair reflection of the collective view of > the WG. Some compromise and good sense from all of us is needed to > keep this thing on track. > > Don't forget that what we're doing here is expressing the view of the > WG (or the RIPE community?) *as a whole*. This does not prevent any of > you from making your own personal or professional representations to > the NTIA, something I encourage all of you to do. If some of the > detail is not to your personal taste, please think carefully about > whether it's better to handle that inside the WG in the time available > or by making a personal submission to NTIA. So unless there's > something in the draft below that you think makes us look bad/stupid/ > wrong, can I ask for your support on this latest version? > > Oh, and if you are happy with the latest draft, please say so on the > list. Your WG co-chairs will feel a lot more comfortable declaring > consensus when there are positive statements to that effect on the > list. This is far better than presuming a default of silence implies > consent. > > # > # $Id: ntia-draft,v 1.8 2008/11/09 17:28:20 jim Exp $ > # > > The RIPE community (or DNS WG?) thanks the NTIA for its consultation > on proposals to sign the root and is pleased to offer the following > response to that consultation. We urge the adoption of a solution that > leads to the prompt introduction of a signed root zone. Our community > considers the introduction of a signed root zone to be an essential > enabling step towards widespread deployment of Secure DNS, DNSSEC. > > It is to be expected that a community as diverse as RIPE cannot have a > unified set of detailed answers to the NTIA questionnaire. However > several > members of the RIPE community will be individually responding to that > questionnaire. We present the following statement as the consensus > view of our community (or the DNS Working Group?) about the principles > that should form the basis of the introduction of a signed DNS root. > > 1. Secure DNS, DNSSEC, is about data authenticity and integrity and > not about control. > > 2. The introduction of DNSSEC to the root zone must be made in such a > way that it is accepted as a global initiative. > > 3. Addition of DNSSEC to the root zone must be done in a way that does > not compromise the security and stability of the Domain Name System. > > 4. When balancing the various concerns about signing the root zone, > the approach must provide an appropriate level of trust and confidence > by offering an optimally secure solution. > > 5. Deployment of a signed root should be done in a timely but not > hasty manner. > > 6. Updates from TLD operators relating to DNSSEC should be aligned > with the operational mechanisms for co-ordinating changes to the root > zone. > > 7. If any procedural changes are introduced by the deployment of > DNSSEC they should provide sufficient flexibility to allow for the > roles and processes as well as the entities holding those roles to be > changed after suitable consultations have taken place. > > 8. Policies and processes for signing the root zone must be > transparent and trustworthy, making it straightforward for TLDs to > supply keys and credentials so the delegations for those TLDs can > benefit from a common DNSSEC trust anchor, the signed root. > > 9. There is no technical justification to create a new organisation to > oversee the process of signing of the root. > > 10. No data should be moved between organisations without appropriate > authenticity and integrity checking, particularly the flow of keying > material between a TLD operator and the entity that signs the root. > > 11. The public part of the key signing key must be distributed as > widely as possible. > > 12. The organisation that generates the root zone file must sign the > file and therefore hold the private part of the zone signing key. > > 13. Changes to the entities and roles in the signing process must not > necessarily require a change of keys. > From pk at DENIC.DE Thu Nov 13 11:57:30 2008 From: pk at DENIC.DE (Peter Koch) Date: Thu, 13 Nov 2008 11:57:30 +0100 Subject: [adm] Re: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: <20081113105730.GF9314@unknown.office.denic.de> Dear DNS WG, On Mon, Nov 10, 2008 at 08:57:23AM +0000, Jim Reid wrote: > The intention is still to try and get consensus in the WG, ideally on > the text below. [...] the DNS WG co-chairs (again, as an active editor, Jim had recused himself) have evaluated the discussion of the draft NTIA response. The final draft NTIA statement (version 1.8) was sent to the DNS WG mailing list on 11 November. Before and after this date, there has been active discussion and participation on the DNS WG mailing list. 11 people have directly responded to the latest draft, of which nine have explicitly stated their support. One person was unhappy with the lack of operational detail and the presence of one bullet item, but apart from that, generally supported the effort. This is consistent with the discussion of the previous versions of the document, where multiple people had voiced support, with another dissenting individual, who would still not oppose the text going forward as a WG statement. We therefore declare strong WG consensus on the final draft version 1.8. According to our schedule, the document will now be sent to the general RIPE mailing list with a request for endorsement by the RIPE community. The editors will replace the references to the DNS WG with references to the RIPE community where appropriate. We would like to thank the editors and everybody who commented or contributed. Regards, Peter Koch [for the DNS WG co-chairs] From Ed.Lewis at neustar.biz Thu Nov 13 12:07:33 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 13 Nov 2008 06:07:33 -0500 Subject: [adm] Re: [dns-wg] one more effort on the NTIA response In-Reply-To: <20081113105730.GF9314@unknown.office.denic.de> References: <20081113105730.GF9314@unknown.office.denic.de> Message-ID: At 11:57 +0100 11/13/08, Peter Koch wrote: >support, with another dissenting individual, who would still not oppose >the text going forward as a WG statement. Assuming I'm the dissenting individual - I had a talk with Jim yesterday. My comments were strictly related to the words used and how they might be interpreted, not the point being made. I.e., no substantive argument. In the sense that editing anything means a new cycle of review, rewording for clarification would mean that there'd be no time for vetting, etc., and still get this to the NTIA in time - you can say that I agree with the message being sent (if not the exact words). I didn't have time last evening to email about this conversation with Jim. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From denic at eng.colt.net Thu Nov 13 11:45:15 2008 From: denic at eng.colt.net (Ralf Weber) Date: Thu, 13 Nov 2008 11:45:15 +0100 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: References: Message-ID: <1C45ED1E-8053-43B1-99A4-BB5859627A54@eng.colt.net> Moin! I would like to thank Jim and all the people who contributed to the document. The current, last, v1.8 is an appropriate response to the NTIA questionnaire and has our support. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services Sch?tze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From dogwallah at gmail.com Thu Nov 13 12:31:56 2008 From: dogwallah at gmail.com (McTim) Date: Thu, 13 Nov 2008 14:31:56 +0300 Subject: [adm] Re: [dns-wg] one more effort on the NTIA response In-Reply-To: <20081113105730.GF9314@unknown.office.denic.de> References: <20081113105730.GF9314@unknown.office.denic.de> Message-ID: On Thu, Nov 13, 2008 at 1:57 PM, Peter Koch wrote: > Dear DNS WG, We therefore declare strong WG consensus on the final draft version 1.8. > w00t! > > According to our schedule, the document will now be sent to the general > RIPE mailing list with a request for endorsement by the RIPE community. > The editors will replace the references to the DNS WG with references to > the RIPE community where appropriate. > and if the statement does NOT reach consensus there, I trust you will submit it from the DNS-WG? -- Cheers, McTim http://stateoftheinternetin.ug -------------- next part -------------- An HTML attachment was scrubbed... URL: From pk at DENIC.DE Thu Nov 13 13:50:48 2008 From: pk at DENIC.DE (Peter Koch) Date: Thu, 13 Nov 2008 13:50:48 +0100 Subject: [adm] Re: [dns-wg] one more effort on the NTIA response In-Reply-To: References: <20081113105730.GF9314@unknown.office.denic.de> Message-ID: <20081113125048.GC9841@unknown.office.denic.de> Hi Ed, > >support, with another dissenting individual, who would still not oppose > >the text going forward as a WG statement. > > Assuming I'm the dissenting individual - I had a talk with Jim actually you were the first person quoted, this reference was to Bill. > yesterday. My comments were strictly related to the words used and > how they might be interpreted, not the point being made. I.e., no > substantive argument. In the sense that editing anything means a new > cycle of review, rewording for clarification would mean that there'd > be no time for vetting, etc., and still get this to the NTIA in time > - you can say that I agree with the message being sent (if not the > exact words). Thanks for the clarification. Since this would even more contribute to the consensus already declared, I'd rather not reword our statement and hope you do not feel misrepresented. -Peter From Ed.Lewis at neustar.biz Thu Nov 13 14:01:45 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 13 Nov 2008 08:01:45 -0500 Subject: [adm] Re: [dns-wg] one more effort on the NTIA response In-Reply-To: <20081113125048.GC9841@unknown.office.denic.de> References: <20081113105730.GF9314@unknown.office.denic.de> <20081113125048.GC9841@unknown.office.denic.de> Message-ID: At 13:50 +0100 11/13/08, Peter Koch wrote: >Thanks for the clarification. Since this would even more contribute to >the consensus already declared, I'd rather not reword our statement >and hope you do not feel misrepresented. No problem...never let nits slow down progress. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From jim at rfc1035.com Thu Nov 13 14:25:32 2008 From: jim at rfc1035.com (Jim Reid) Date: Thu, 13 Nov 2008 13:25:32 +0000 Subject: [dns-wg] submitting a response to NTIA In-Reply-To: References: <20081113105730.GF9314@unknown.office.denic.de> Message-ID: <71C62E07-3983-4C60-883C-252560F7856B@rfc1035.com> On Nov 13, 2008, at 11:31, McTim wrote: > and if the statement does NOT reach consensus there, I trust you > will submit it from the DNS-WG? Yes. From bmanning at vacation.karoshi.com Thu Nov 13 14:48:42 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 13 Nov 2008 13:48:42 +0000 Subject: [adm] Re: [dns-wg] one more effort on the NTIA response In-Reply-To: References: <20081113105730.GF9314@unknown.office.denic.de> Message-ID: <20081113134842.GB7870@vacation.karoshi.com.> On Thu, Nov 13, 2008 at 06:07:33AM -0500, Edward Lewis wrote: > At 11:57 +0100 11/13/08, Peter Koch wrote: > > >support, with another dissenting individual, who would still not oppose > >the text going forward as a WG statement. > > Assuming I'm the dissenting individual - I had a talk with Jim > yesterday. My comments were strictly related to the words used and > how they might be interpreted, not the point being made. I.e., no > substantive argument. In the sense that editing anything means a new > cycle of review, rewording for clarification would mean that there'd > be no time for vetting, etc., and still get this to the NTIA in time > - you can say that I agree with the message being sent (if not the > exact words). > > I didn't have time last evening to email about this conversation with Jim. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 you flatter yourself :) I beleive I was the disenting individual. and for the record, NTIA is still interested in other views, so either find folks who share your views and respond to the NOI or send in your individual concerns. DoC would be pleased to be inundated w/ responses. :) --bill From dougb at dougbarton.us Thu Nov 13 21:18:00 2008 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 13 Nov 2008 12:18:00 -0800 Subject: [adm] Re: [dns-wg] one more effort on the NTIA response In-Reply-To: <20081113105730.GF9314@unknown.office.denic.de> References: <20081113105730.GF9314@unknown.office.denic.de> Message-ID: <491C8B78.2080801@dougbarton.us> Peter Koch wrote: > Dear DNS WG, > > On Mon, Nov 10, 2008 at 08:57:23AM +0000, Jim Reid wrote: > >> The intention is still to try and get consensus in the WG, ideally on >> the text below. [...] > > the DNS WG co-chairs (again, as an active editor, Jim had recused himself) > have evaluated the discussion of the draft NTIA response. > > The final draft NTIA statement (version 1.8) was sent to the DNS WG mailing > list on 11 November. > Before and after this date, there has been active discussion and participation > on the DNS WG mailing list. > 11 people have directly responded to the latest draft, of which nine have > explicitly stated their support. One person was unhappy with the lack of > operational detail and the presence of one bullet item, but apart from that, > generally supported the effort. This is consistent with the discussion of > the previous versions of the document, where multiple people had voiced > support, with another dissenting individual, who would still not oppose > the text going forward as a WG statement. Out of curiosity, where do the comments and suggestions that I offered fit into this description? > We therefore declare strong WG consensus on the final draft version 1.8. I do not object to this characterization. I would simply add that while "strong" may be the right adjective, "unanimous" is definitely not. My chief concern remains that as technologists we enter dangerous waters when we choose to dabble in politics, and run the risk of producing work that is valuable to neither community. Regards, Doug From jim at rfc1035.com Thu Nov 13 21:40:36 2008 From: jim at rfc1035.com (Jim Reid) Date: Thu, 13 Nov 2008 20:40:36 +0000 Subject: [dns-wg] production of the final version of the NTIA response In-Reply-To: <491C8B78.2080801@dougbarton.us> References: <20081113105730.GF9314@unknown.office.denic.de> <491C8B78.2080801@dougbarton.us> Message-ID: <0DEB6FF9-C3CB-49DB-9EAD-EB2CE9687B7E@rfc1035.com> On Nov 13, 2008, at 20:18, Doug Barton wrote: > Out of curiosity, where do the comments and suggestions that I offered > fit into this description? The editing group that worked on the text over the weekend took into account all the comments that had been made on the list and accommodated them as best and as practically as possible. It was obviously impractical to include everything everyone said verbatim, so the guiding principle of the editing group was to convey the general thrust of those comments in a way that (a) didn't dilute or confuse the overall message; (b) dive into too much detail; (c) produced text that the WG as a whole (and hopefully the RIPE community) would be comfortable with. The editing group also had to consider how others outside RIPE and the WG had perceived the earlier draft. Balancing all of these demands was not an easy task, given the various dynamics and the broader audience who will be reading this response. [FYI I know some governments are taking a keen interest in what we say in response to the NTIA NoI.] I hope you can agree the editing group managed to achieve that. I apologise to anyone who feels their contribution has been overlooked because their favourite phrases didn't make it into the final version. The editing group didn't overlook those contributions. And I hope everyone appreciates that a document of this nature by definition involves compromise from all who contributed to its production. From dougb at dougbarton.us Thu Nov 13 21:50:01 2008 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 13 Nov 2008 12:50:01 -0800 Subject: [dns-wg] production of the final version of the NTIA response In-Reply-To: <0DEB6FF9-C3CB-49DB-9EAD-EB2CE9687B7E@rfc1035.com> References: <20081113105730.GF9314@unknown.office.denic.de> <491C8B78.2080801@dougbarton.us> <0DEB6FF9-C3CB-49DB-9EAD-EB2CE9687B7E@rfc1035.com> Message-ID: <491C92F9.3030804@dougbarton.us> Jim Reid wrote: > On Nov 13, 2008, at 20:18, Doug Barton wrote: > >> Out of curiosity, where do the comments and suggestions that I offered >> fit into this description? > > The editing group that worked on the text over the weekend ... Sorry, I think you misunderstood my question. Peter's description of the discussion (inadvertently?) did not include the fact that there was at least one other person (me) who objected to some of what was included in what became the final statement. I fully understand the delicacies of trying to incorporate various ideas of how to word things into a final form. I'm not at all concerned that my "favourite phrases didn't make it into the final version." hope this helps, Doug From liman at autonomica.se Fri Nov 14 13:25:27 2008 From: liman at autonomica.se (Lars-Johan Liman) Date: Fri, 14 Nov 2008 13:25:27 +0100 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: (Jim Reid's message of "Mon\, 10 Nov 2008 08\:57\:23 +0000") References: Message-ID: <22bpwio5oo.fsf@zaptop.autonomica.net> jim at rfc1035.com: > # > # $Id: ntia-draft,v 1.8 2008/11/09 17:28:20 jim Exp $ > # FWIW at this late stage, I was in on the editing of the first version, and I see this as an improvement. I'll gladly support this document, preferrably as a RIPE statement, if not, as a DNS WG statement. Cheers, /Liman #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail/SIP/Jabber: liman at autonomica.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Autonomica AB, Stockholm ! http://www.autonomica.se/ #---------------------------------------------------------------------- From randy at psg.com Fri Nov 14 13:29:40 2008 From: randy at psg.com (Randy Bush) Date: Fri, 14 Nov 2008 06:29:40 -0600 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: <22bpwio5oo.fsf@zaptop.autonomica.net> References: <22bpwio5oo.fsf@zaptop.autonomica.net> Message-ID: <491D6F34.4070604@psg.com> > I'll gladly support this document, preferrably as a RIPE statement, if > not, as a DNS WG statement. From pk at DENIC.DE Sat Nov 15 00:44:35 2008 From: pk at DENIC.DE (Peter Koch) Date: Sat, 15 Nov 2008 00:44:35 +0100 Subject: [adm] Re: [dns-wg] one more effort on the NTIA response In-Reply-To: <491C8B78.2080801@dougbarton.us> References: <20081113105730.GF9314@unknown.office.denic.de> <491C8B78.2080801@dougbarton.us> Message-ID: <20081114234435.GB19232@x27.adm.denic.de> Doug, > > generally supported the effort. This is consistent with the discussion of > > the previous versions of the document, where multiple people had voiced > > support, with another dissenting individual, who would still not oppose > > the text going forward as a WG statement. > > Out of curiosity, where do the comments and suggestions that I offered > fit into this description? I assume you refer to your message <4914A6ED.40805 at dougbarton.us> dated Fri, 7 Nov 2008 12:37:01 -0800. First, the summary above was not meant to cover the details of every individual response, especially when these responses addressed earlier than the final draft versions. Second, my reading of your contribution is that it's generally supportive, while you make editorial suggestions and are critical of very few bullet items. Some of the suggestions have been incorporated, albeit not literally. In other cases the editors have decided against a change, which is sensible in favor of convergence and in the presence of maybe competing suggestions. This has happened to others, including my [hatless] self and is not unusual. That said, I still believe we should not have counted your statement on the "dissenting" side. I also maintain the consensus judgement. > > We therefore declare strong WG consensus on the final draft version 1.8. > > I do not object to this characterization. I would simply add that while > "strong" may be the right adjective, "unanimous" is definitely not. That is true and the words were chosen deliberately. > My chief concern remains that as technologists we enter dangerous waters > when we choose to dabble in politics, and run the risk of producing work > that is valuable to neither community. Thanks for that clarification. Best regards, Peter From pk at DENIC.DE Sat Nov 15 00:52:29 2008 From: pk at DENIC.DE (Peter Koch) Date: Sat, 15 Nov 2008 00:52:29 +0100 Subject: [dns-wg] Call for Support of our NTIA response posted Message-ID: <20081114235229.GC19232@x27.adm.denic.de> Dear DNS WG, the draft NTIA response has now been forwarded to the general RIPE discussion list for endorsement. Find below the differences between version 1.8 last called here and version 1.9, which went to the list. The changes clarify the originating entity and add a reference to RIPE's previous effort w.r.t. signing the root. -Peter Koch [for the DNS WG co-chairs] --- version1.8 2008-11-14 19:34:14.000000000 +0100 +++ version1.9 2008-11-14 09:40:15.000000000 +0100 @@ -1,21 +1,23 @@ # -# $Id: ntia-draft,v 1.8 2008/11/09 17:28:20 jim Exp $ +# $Id: ntia-draft,v 1.9 2008/11/13 20:20:41 jim Exp $ # -The RIPE community (or DNS WG?) thanks the NTIA for its consultation -on proposals to sign the root and is pleased to offer the following -response to that consultation. We urge the adoption of a solution that -leads to the prompt introduction of a signed root zone. Our community -considers the introduction of a signed root zone to be an essential -enabling step towards widespread deployment of Secure DNS, DNSSEC. +The RIPE community thanks the NTIA for its consultation on proposals +to sign the root and is pleased to offer the following response to +that consultation. We urge the adoption of a solution that leads to +the prompt introduction of a signed root zone. Our community considers +the introduction of a signed root zone to be an essential enabling +step towards widespread deployment of Secure DNS, DNSSEC. This view +is supported by the letter from the RIPE community to ICANN as an +outcome of discussions at the May 2007 RIPE meeting in Tallinn: +http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf. It is to be expected that a community as diverse as RIPE cannot have a -unified set of detailed answers to the NTIA questionnaire. However -several -members of the RIPE community will be individually responding to that -questionnaire. We present the following statement as the consensus -view of our community (or the DNS Working Group?) about the principles -that should form the basis of the introduction of a signed DNS root. +unified set of detailed answers to the NTIA questionnaire. However +several members of the RIPE community will be individually responding +to that questionnaire. We present the following statement as the +consensus view of our community about the principles that should form +the basis of the introduction of a signed DNS root. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control. From mohsen.souissi at nic.fr Wed Nov 19 11:59:10 2008 From: mohsen.souissi at nic.fr (Mohsen Souissi) Date: Wed, 19 Nov 2008 11:59:10 +0100 Subject: [dns-wg] Survey on a "Technology Backdrop": please participate Message-ID: <20081119105910.GE35445@kerkenna.nic.fr> [Apologies for multiple copies due to mailing-lists overlapping] Dear all, Our R&D team at AFNIC (The French ccTLD Registry), with the help of its Scientific Council, is carrying out a survey on a "Technology backdrop" for AFNIC in a medium-to-long term (10-15 years). The main objective is to get a common view of the future (trends, uncertainties) when assessing R&D opportunities in the future. We believe that the outcome of this survey may be of interest to people answering it, as most questions sit indeed in a a quite wide technology perimeter/scope. Here's a short description of the context & goals of the survey: ------------------------------------------------------------------------ This survey aims at helping AFNIC to develop a technology backdrop (i.e., a shared vision of technology evolution) in a medium-to-long term. Three axes have been chosen: "A. Global Internet Architecture", "B. Internet Naming, Identifiers and Digital Identities" and "C. User trends". : ------------------------------------------------------------------------ The survey is open from the 1st October to 31st of December 2008. Please feel free to participate: - "Canonical" URL: http://www.surveymonkey.com/s.aspx?sm=V0j_2fSEbCuIRb4EwwMPcyOA_3d_3d - "Tiny" URL: http://tinyurl.com/4xn2xc We commit to sharing the results with contributors who desire it (the survey includes a question to that effect). Looking forward to your contribution and thank you in advance for your time! Best Regards, Mohsen. From niallm at avernus.net Tue Nov 18 16:21:41 2008 From: niallm at avernus.net (Niall Richard Murphy) Date: Tue, 18 Nov 2008 15:21:41 +0000 Subject: [dns-wg] one more effort on the NTIA response In-Reply-To: <1BD829B5-D15E-459D-8506-AC783D0A6FFD@rfc1035.com> References: <3A144905-3270-4487-874E-FBF4EAA4DC07@rfc1035.com> <1BD829B5-D15E-459D-8506-AC783D0A6FFD@rfc1035.com> Message-ID: <3DDC8AB4-BCE4-4D0B-835B-AF5E2A63FFD9@avernus.net> I'm in favour of the latest version of the draft. NRM From Woeber at CC.UniVie.ac.at Thu Nov 20 13:45:49 2008 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 20 Nov 2008 12:45:49 +0000 Subject: [dns-wg] question re the "fate" of ns-v6.ripe.net Message-ID: <49255BFD.7000006@CC.UniVie.ac.at> I am following up on some v6-related hickups (on our side) and found that our reverse zones specify ns-v6.ripe.net as one of the slaves. I am pretty sure that we didn't "invent" that out of the blue :-) but the documentation does not know about the "-v6" variant, and, checking the responses, queries to ns-v6.ripe.net and ns.ripe.net seem to yield the same A and AAAA responses. It may be a left-over from the time when the NCC's Services were not "transparently" IPv6-aware. What is the current recommendation? Wilfried. From Woeber at CC.UniVie.ac.at Thu Nov 20 15:02:34 2008 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 20 Nov 2008 14:02:34 +0000 Subject: [dns-wg] rev delegation robot and selection of NS to pull zone from Message-ID: <49256DFA.4070609@CC.UniVie.ac.at> Another question regarding v6 reverse delegation, but possibly also applicable to v4 reverse... One of our customers has a somewhat complex DNS setup which makes us face the situation that in the SOA record the name of the NS where the zone originates is not in the set of responses to NS queries. While this is not the common case, I presume, it seems to NOT be "illegal". The domain has to on-site name servers and is configured to have a slave at the NCC. For this zone we received an alert that the ZXFR has failed from the machine with the name given in the SOA. That box will never be serving external zone transfer requests. So - this may just be a glitch in the alerting script, but I am still left with the question: how does the robot at the NCC's end determine the "appropriate" host to try zone transfers from? Any recommendations? Thanks, Wilfreid. From mohsen.souissi at nic.fr Thu Nov 20 19:44:36 2008 From: mohsen.souissi at nic.fr (Mohsen Souissi) Date: Thu, 20 Nov 2008 19:44:36 +0100 Subject: [dns-wg] rev delegation robot and selection of NS to pull zone from In-Reply-To: <49256DFA.4070609@CC.UniVie.ac.at> References: <49256DFA.4070609@CC.UniVie.ac.at> Message-ID: <20081120184436.GF17903@kerkenna.nic.fr> Wilfried, Some call it "hidden master", others call it "hidden primary" and others call it "stealth master"... This URL may help and I'm sure there is much more thorough source of documentation: http://www.dns.net/dnsrd/servers/ (just look up "hidden master" in the web page...) You may also visit this page: https://www.isc.org/software/bind/documentation/arm95 I think as for the XFR config, amha, the slave run by NCC should be configured to feed from the other NS listed (and run on-site). Hope that helps, Mohsen. On 20 Nov, Wilfried Woeber, UniVie/ACOnet wrote: | Another question regarding v6 reverse delegation, but possibly also | applicable to v4 reverse... | | One of our customers has a somewhat complex DNS setup which makes us | face the situation that in the SOA record the name of the NS where | the zone originates is not in the set of responses to NS queries. | | While this is not the common case, I presume, it seems to NOT be "illegal". | | The domain has to on-site name servers and is configured to have a slave | at the NCC. | | For this zone we received an alert that the ZXFR has failed from the | machine with the name given in the SOA. That box will never be serving | external zone transfer requests. | | So - this may just be a glitch in the alerting script, but I am still | left with the question: how does the robot at the NCC's end determine | the "appropriate" host to try zone transfers from? | | Any recommendations? | | Thanks, | Wilfreid. From barbara.roseman at icann.org Thu Nov 20 19:48:25 2008 From: barbara.roseman at icann.org (Barbara Roseman) Date: Thu, 20 Nov 2008 10:48:25 -0800 Subject: [dns-wg] rev delegation robot and selection of NS to pull zone from In-Reply-To: <20081120184436.GF17903@kerkenna.nic.fr> Message-ID: A new term, without the baggage of "hidden" or "stealth" is "distribution master". -Barb On 11/20/08 10:44 AM, "Mohsen Souissi" wrote: Wilfried, Some call it "hidden master", others call it "hidden primary" and others call it "stealth master"... This URL may help and I'm sure there is much more thorough source of documentation: http://www.dns.net/dnsrd/servers/ (just look up "hidden master" in the web page...) You may also visit this page: https://www.isc.org/software/bind/documentation/arm95 I think as for the XFR config, amha, the slave run by NCC should be configured to feed from the other NS listed (and run on-site). Hope that helps, Mohsen. On 20 Nov, Wilfried Woeber, UniVie/ACOnet wrote: | Another question regarding v6 reverse delegation, but possibly also | applicable to v4 reverse... | | One of our customers has a somewhat complex DNS setup which makes us | face the situation that in the SOA record the name of the NS where | the zone originates is not in the set of responses to NS queries. | | While this is not the common case, I presume, it seems to NOT be "illegal". | | The domain has to on-site name servers and is configured to have a slave | at the NCC. | | For this zone we received an alert that the ZXFR has failed from the | machine with the name given in the SOA. That box will never be serving | external zone transfer requests. | | So - this may just be a glitch in the alerting script, but I am still | left with the question: how does the robot at the NCC's end determine | the "appropriate" host to try zone transfers from? | | Any recommendations? | | Thanks, | Wilfreid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anandb at ripe.net Thu Nov 20 20:14:34 2008 From: anandb at ripe.net (Anand Buddhdev) Date: Thu, 20 Nov 2008 20:14:34 +0100 Subject: [dns-wg] Re: rev delegation robot and selection of NS to pull zone from In-Reply-To: <49256DFA.4070609@CC.UniVie.ac.at> References: <49256DFA.4070609@CC.UniVie.ac.at> Message-ID: <4925B71A.5060206@ripe.net> On 20/11/08 15:02, Wilfried Woeber, UniVie/ACOnet wrote: Hello Wilfried, > Another question regarding v6 reverse delegation, but possibly also > applicable to v4 reverse... > > One of our customers has a somewhat complex DNS setup which makes us > face the situation that in the SOA record the name of the NS where > the zone originates is not in the set of responses to NS queries. > > While this is not the common case, I presume, it seems to NOT be "illegal". > > The domain has to on-site name servers and is configured to have a slave > at the NCC. > > For this zone we received an alert that the ZXFR has failed from the > machine with the name given in the SOA. That box will never be serving > external zone transfer requests. > > So - this may just be a glitch in the alerting script, but I am still > left with the question: how does the robot at the NCC's end determine > the "appropriate" host to try zone transfers from? When the RIPE NCC's provisioning system sees ns.ripe.net in the list of name servers for /16 IPv4 and /32 IPv6 zones, it looks up the SOA record of the zone, extracts the MNAME from there, and looks up A and AAAA records for the MNAME. These are then used to attempt zone transfers for that zone. The provisioning system does not use any servers from the NS RRset. The provisioning system just generates configuration for BIND running on the ns.ripe.net cluster. It doesn't know whether a zone transfer will succeed or not. The recent alerts that we sent out to notify administrators of failing zone transfers were generated by a script, which took its input from BIND log files, where we have a record of failed zone transfers. The configuration you describe above isn't illegal. However, the RIPE NCC's provisioning system won't be able to cope with it. Currently, there's no way to explicitly provide a list of master servers that zone transfers should be attempted from. One solution is to list a server in the MNAME field which will provide zone transfers. Alternatively, you can choose not to use ns.ripe.net as a secondary - it is no longer mandatory for /16 IPv4 and /32 IPv6 reverse zones. -- Anand Buddhdev DNS Services Manager, RIPE NCC From pk at DENIC.DE Thu Nov 20 21:23:53 2008 From: pk at DENIC.DE (Peter Koch) Date: Thu, 20 Nov 2008 21:23:53 +0100 Subject: [dns-wg] rev delegation robot and selection of NS to pull zone from In-Reply-To: References: <20081120184436.GF17903@kerkenna.nic.fr> Message-ID: <20081120202353.GA18651@x27.adm.denic.de> On Thu, Nov 20, 2008 at 10:48:25AM -0800, Barbara Roseman wrote: > A new term, without the baggage of "hidden" or "stealth" is "distribution master". while this is helpful to avoid layer 9 issues, associating 'stealth' with certainly colored helicopters and such, it doesn't make obvious the fact that the server is not listed in the NS RRSet. In theory the MNAME should be the root of the XFR dependency graph, not necessarily accessible from the outside. -Peter From pk at DENIC.DE Thu Nov 20 21:26:34 2008 From: pk at DENIC.DE (Peter Koch) Date: Thu, 20 Nov 2008 21:26:34 +0100 Subject: [dns-wg] Re: rev delegation robot and selection of NS to pull zone from In-Reply-To: <4925B71A.5060206@ripe.net> References: <49256DFA.4070609@CC.UniVie.ac.at> <4925B71A.5060206@ripe.net> Message-ID: <20081120202634.GB18651@x27.adm.denic.de> On Thu, Nov 20, 2008 at 08:14:34PM +0100, Anand Buddhdev wrote: > The configuration you describe above isn't illegal. However, the RIPE > NCC's provisioning system won't be able to cope with it. Currently, > there's no way to explicitly provide a list of master servers that zone > transfers should be attempted from. > > One solution is to list a server in the MNAME field which will provide > zone transfers. Alternatively, you can choose not to use ns.ripe.net as while the latter is probably the most pragmatic approach, it could interfere with other requirements. Depending on how widespread this issue is, the WG might also consider to propose a new attribute for the domain: object to denominate the (list of) AXFR source(s). -Peter From bmanning at vacation.karoshi.com Fri Nov 21 01:29:15 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 21 Nov 2008 00:29:15 +0000 Subject: [dns-wg] rev delegation robot and selection of NS to pull zone from In-Reply-To: References: <20081120184436.GF17903@kerkenna.nic.fr> Message-ID: <20081121002915.GA1849@vacation.karoshi.com.> the root ops folks have used that term for nearly a decade... its much cleaner/nicer than the baggage of other, more highly charged words. --bill On Thu, Nov 20, 2008 at 10:48:25AM -0800, Barbara Roseman wrote: > A new term, without the baggage of "hidden" or "stealth" is "distribution master". > > -Barb > > > On 11/20/08 10:44 AM, "Mohsen Souissi" wrote: > > Wilfried, > > Some call it "hidden master", others call it "hidden primary" and > others call it "stealth master"... > > This URL may help and I'm sure there is much more thorough source of > documentation: http://www.dns.net/dnsrd/servers/ > > (just look up "hidden master" in the web page...) > > You may also visit this page: > https://www.isc.org/software/bind/documentation/arm95 > > I think as for the XFR config, amha, the slave run by NCC should be > configured to feed from the other NS listed (and run on-site). > > Hope that helps, > > Mohsen. > > On 20 Nov, Wilfried Woeber, UniVie/ACOnet wrote: > | Another question regarding v6 reverse delegation, but possibly also > | applicable to v4 reverse... > | > | One of our customers has a somewhat complex DNS setup which makes us > | face the situation that in the SOA record the name of the NS where > | the zone originates is not in the set of responses to NS queries. > | > | While this is not the common case, I presume, it seems to NOT be "illegal". > | > | The domain has to on-site name servers and is configured to have a slave > | at the NCC. > | > | For this zone we received an alert that the ZXFR has failed from the > | machine with the name given in the SOA. That box will never be serving > | external zone transfer requests. > | > | So - this may just be a glitch in the alerting script, but I am still > | left with the question: how does the robot at the NCC's end determine > | the "appropriate" host to try zone transfers from? > | > | Any recommendations? > | > | Thanks, > | Wilfreid. > > From jaap at NLnetLabs.nl Fri Nov 21 05:54:18 2008 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Fri, 21 Nov 2008 05:54:18 +0100 Subject: [dns-wg] rev delegation robot and selection of NS to pull zone from In-Reply-To: Your message of Fri, 21 Nov 2008 00:29:15 +0000. <20081121002915.GA1849@vacation.karoshi.com.> Message-ID: <200811210454.mAL4sItl059021@bartok.nlnetlabs.nl> the root ops folks have used that term for nearly a decade... its much cleaner/nicer than the baggage of other, more highly charged words. So if we really can get rid of "master" and "slave", we get a political correct dns :-). jaap From bmanning at vacation.karoshi.com Fri Nov 21 08:22:28 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 21 Nov 2008 07:22:28 +0000 Subject: [dns-wg] rev delegation robot and selection of NS to pull zone from In-Reply-To: <200811210454.mAL4sItl059021@bartok.nlnetlabs.nl> References: <20081121002915.GA1849@vacation.karoshi.com.> <200811210454.mAL4sItl059021@bartok.nlnetlabs.nl> Message-ID: <20081121072228.GA3300@vacation.karoshi.com.> On Fri, Nov 21, 2008 at 05:54:18AM +0100, Jaap Akkerhuis wrote: > > the root ops folks have used that term for nearly a decade... > its much cleaner/nicer than the baggage of other, more highly > charged words. > > So if we really can get rid of "master" and "slave", we get a > political correct dns :-). > we did get rid of "master" and "slave" - using "primary" and "secondary". In the legal jurisdiction where I live, it is illegal to use the terms master/slave for DNS purposes.... YMMV. --bill From denic at eng.colt.net Fri Nov 21 08:29:21 2008 From: denic at eng.colt.net (Ralf Weber) Date: Fri, 21 Nov 2008 08:29:21 +0100 Subject: [dns-wg] Re: rev delegation robot and selection of NS to pull zone from In-Reply-To: <4925B71A.5060206@ripe.net> References: <49256DFA.4070609@CC.UniVie.ac.at> <4925B71A.5060206@ripe.net> Message-ID: Moin! On 20.11.2008, at 20:14, Anand Buddhdev wrote: > When the RIPE NCC's provisioning system sees ns.ripe.net in the list > of > name servers for /16 IPv4 and /32 IPv6 zones, it looks up the SOA > record > of the zone, extracts the MNAME from there, and looks up A and AAAA > records for the MNAME. These are then used to attempt zone transfers > for > that zone. The provisioning system does not use any servers from the > NS > RRset. Why? I mean for me that would be one natural source of information another of course would be the nserver entries in the RIPE database. Using these source also would increase the resiliency of the zone transfers as the server then usually has more than one source to transfer the zone from. I think that this is what people using hidden/ distribution masters want to have also, at least from my experience with our customers using this. [..] > One solution is to list a server in the MNAME field which will provide > zone transfers. Alternatively, you can choose not to use ns.ripe.net > as > a secondary - it is no longer mandatory for /16 IPv4 and /32 IPv6 > reverse zones. Both are options, but I still would like to know if it wouldn't make more sense to use nserver records or NS RRset. Do you have some statistics on how often the MNAME is not in the nserver/NS RRset? So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services Sch?tze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From denic at eng.colt.net Fri Nov 21 11:05:25 2008 From: denic at eng.colt.net (Ralf Weber) Date: Fri, 21 Nov 2008 11:05:25 +0100 Subject: [dns-wg] Re: rev delegation robot and selection of NS to pull zone from In-Reply-To: <49267F44.6040304@CC.UniVie.ac.at> References: <49256DFA.4070609@CC.UniVie.ac.at> <4925B71A.5060206@ripe.net> <49267F44.6040304@CC.UniVie.ac.at> Message-ID: <8F98ADE0-8715-4E52-B92C-622C73CABC75@eng.colt.net> Moin! On 21.11.2008, at 10:28, Wilfried Woeber, UniVie/ACOnet wrote: > My feeling is that the current behaviour is quite reasonable. Of > course > we might suggest to look at the NS records (in addition maybe), but I > presume that many folks do not allow zone transfers from *all* NS in > the > set. Correct, but only one is required for a proper transfer. > Unless we find a "clever" way to provide the info about the name > server(s) > to try for a transfer, overall, we would just increase the number of > failed > attempts. Whether that would do any harm (at the NCC's or customer's > end) > is a different story, maybe. Yes it could clutter the logs, but if one transfer would succeed it would be ok. I have used this technique successfully during various DNS migrations. >> Both are options, but I still would like to know if it wouldn't make >> more sense to use nserver records or NS RRset. Do you have some >> statistics on how often the MNAME is not in the nserver/NS RRset? > > I definitely don't have any figures. Sorry that was a question to Anand, but I didn't point that out. Anand do you have statistics for the current delegations? So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services Sch?tze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From Piotr.Strzyzewski at polsl.pl Fri Nov 21 11:18:14 2008 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Fri, 21 Nov 2008 11:18:14 +0100 Subject: [dns-wg] Re: rev delegation robot and selection of NS to pull zone from In-Reply-To: <8F98ADE0-8715-4E52-B92C-622C73CABC75@eng.colt.net> References: <49256DFA.4070609@CC.UniVie.ac.at> <4925B71A.5060206@ripe.net> <49267F44.6040304@CC.UniVie.ac.at> <8F98ADE0-8715-4E52-B92C-622C73CABC75@eng.colt.net> Message-ID: <20081121101814.GA30538@hydra.ck.polsl.pl> On Fri, Nov 21, 2008 at 11:05:25AM +0100, Ralf Weber wrote: > >Unless we find a "clever" way to provide the info about the name > >server(s) > >to try for a transfer, overall, we would just increase the number of > >failed > >attempts. Whether that would do any harm (at the NCC's or customer's > >end) > >is a different story, maybe. > Yes it could clutter the logs, but if one transfer would succeed it > would be ok. I have used this technique successfully during various > DNS migrations. So maybe the easiest idea is to change the structure of the nserver attribute to something like: nserver: name-of-ns-server [transfer] where "transfer" is optional parameter which is recognised by NCC? Regards, Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From denic at eng.colt.net Fri Nov 21 12:11:25 2008 From: denic at eng.colt.net (Ralf Weber) Date: Fri, 21 Nov 2008 12:11:25 +0100 Subject: [dns-wg] Re: rev delegation robot and selection of NS to pull zone from In-Reply-To: <20081121101814.GA30538@hydra.ck.polsl.pl> References: <49256DFA.4070609@CC.UniVie.ac.at> <4925B71A.5060206@ripe.net> <49267F44.6040304@CC.UniVie.ac.at> <8F98ADE0-8715-4E52-B92C-622C73CABC75@eng.colt.net> <20081121101814.GA30538@hydra.ck.polsl.pl> Message-ID: <0D7A15C4-1C7D-428B-82FE-0FB00F7DE82C@eng.colt.net> Moin! On 21.11.2008, at 11:18, Piotr Strzyzewski wrote: > So maybe the easiest idea is to change the structure of the nserver > attribute to something like: > nserver: name-of-ns-server [transfer] > where "transfer" is optional parameter which is recognised by NCC? Good idea, but if we want to solve this with changes you also have model the case that currently is handled with the primary not being in the name server records (transfer-only?). The questions is do we want to change this and if so don't we then have to take it to the Database and NCC Services Working Groupa also. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services Sch?tze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From Niall.oReilly at ucd.ie Fri Nov 21 11:49:14 2008 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 21 Nov 2008 10:49:14 +0000 Subject: [dns-wg] rev delegation robot and selection of NS to pull zone from In-Reply-To: <49256DFA.4070609@CC.UniVie.ac.at> References: <49256DFA.4070609@CC.UniVie.ac.at> Message-ID: <1227264554.6048.159.camel@d410-heron> On Thu, 2008-11-20 at 14:02 +0000, Wilfried Woeber, UniVie/ACOnet wrote: > So - this may just be a glitch in the alerting script, but I am still > left with the question: how does the robot at the NCC's end determine > the "appropriate" host to try zone transfers from? > > Any recommendations? IMHO ... This is a system-administrative matter to be agreed between the zone administrator and the slave operator. Zone data is not zone metadata. Blurring the distinction can only lead to unintended consequences. If a robot is involved, there needs to be an out-of-zone channel from the zone administrator to the robot. Peter's suggestion of using a new attribute in the database to serve this purpose makes sense to me. A similar, but more sensitive, issue arises with shared secrets for TSIGs. ATB, Niall From Woeber at CC.UniVie.ac.at Thu Nov 20 20:42:36 2008 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 20 Nov 2008 19:42:36 +0000 Subject: [dns-wg] Re: rev delegation robot and selection of NS to pull zone from In-Reply-To: <4925B71A.5060206@ripe.net> References: <49256DFA.4070609@CC.UniVie.ac.at> <4925B71A.5060206@ripe.net> Message-ID: <4925BDAC.2070101@CC.UniVie.ac.at> Thanks, Anand, providing answers for two of my questions in one mail :-) - that this isn't going to work for this setup, and - that we can deal with it locally, by excluding the server at the NCC from the list of slaves for that zone (as the requirement for a slave at the NCC is no longer in place - which I missed). Best regards, Wilfried Anand Buddhdev wrote: > On 20/11/08 15:02, Wilfried Woeber, UniVie/ACOnet wrote: > > Hello Wilfried, > > >>Another question regarding v6 reverse delegation, but possibly also >>applicable to v4 reverse... >> >>One of our customers has a somewhat complex DNS setup which makes us >>face the situation that in the SOA record the name of the NS where >>the zone originates is not in the set of responses to NS queries. >> >>While this is not the common case, I presume, it seems to NOT be "illegal". >> >>The domain has to on-site name servers and is configured to have a slave >>at the NCC. >> >>For this zone we received an alert that the ZXFR has failed from the >>machine with the name given in the SOA. That box will never be serving >>external zone transfer requests. >> >>So - this may just be a glitch in the alerting script, but I am still >>left with the question: how does the robot at the NCC's end determine >>the "appropriate" host to try zone transfers from? > > > When the RIPE NCC's provisioning system sees ns.ripe.net in the list of > name servers for /16 IPv4 and /32 IPv6 zones, it looks up the SOA record > of the zone, extracts the MNAME from there, and looks up A and AAAA > records for the MNAME. These are then used to attempt zone transfers for > that zone. The provisioning system does not use any servers from the NS > RRset. > > The provisioning system just generates configuration for BIND running on > the ns.ripe.net cluster. It doesn't know whether a zone transfer will > succeed or not. The recent alerts that we sent out to notify > administrators of failing zone transfers were generated by a script, > which took its input from BIND log files, where we have a record of > failed zone transfers. > > The configuration you describe above isn't illegal. However, the RIPE > NCC's provisioning system won't be able to cope with it. Currently, > there's no way to explicitly provide a list of master servers that zone > transfers should be attempted from. > > One solution is to list a server in the MNAME field which will provide > zone transfers. Alternatively, you can choose not to use ns.ripe.net as > a secondary - it is no longer mandatory for /16 IPv4 and /32 IPv6 > reverse zones. > From Woeber at CC.UniVie.ac.at Fri Nov 21 10:28:36 2008 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 21 Nov 2008 09:28:36 +0000 Subject: [dns-wg] Re: rev delegation robot and selection of NS to pull zone from In-Reply-To: References: <49256DFA.4070609@CC.UniVie.ac.at> <4925B71A.5060206@ripe.net> Message-ID: <49267F44.6040304@CC.UniVie.ac.at> Ralf Weber wrote: > Moin! > > On 20.11.2008, at 20:14, Anand Buddhdev wrote: > >> When the RIPE NCC's provisioning system sees ns.ripe.net in the list of >> name servers for /16 IPv4 and /32 IPv6 zones, it looks up the SOA record >> of the zone, extracts the MNAME from there, and looks up A and AAAA >> records for the MNAME. These are then used to attempt zone transfers for >> that zone. The provisioning system does not use any servers from the NS >> RRset. > > Why? I mean for me that would be one natural source of information > another of course would be the nserver entries in the RIPE database. Beware - I am not a DNS expert... My feeling is that the current behaviour is quite reasonable. Of course we might suggest to look at the NS records (in addition maybe), but I presume that many folks do not allow zone transfers from *all* NS in the set. Unless we find a "clever" way to provide the info about the name server(s) to try for a transfer, overall, we would just increase the number of failed attempts. Whether that would do any harm (at the NCC's or customer's end) is a different story, maybe. > Using these source also would increase the resiliency of the zone > transfers as the server then usually has more than one source to > transfer the zone from. I think that this is what people using hidden/ > distribution masters want to have also, at least from my experience > with our customers using this. > > [..] > >> One solution is to list a server in the MNAME field which will provide >> zone transfers. Alternatively, you can choose not to use ns.ripe.net as >> a secondary - it is no longer mandatory for /16 IPv4 and /32 IPv6 >> reverse zones. > > Both are options, but I still would like to know if it wouldn't make > more sense to use nserver records or NS RRset. Do you have some > statistics on how often the MNAME is not in the nserver/NS RRset? I definitely don't have any figures. > So long > -Ralf Wilfried