November 2008 - dns-wg - mailman.ripe.net

rev delegation robot and selection of NS to pull zone from
by Wilfried Woeber, UniVie/ACOnet 21 Nov '08

21 Nov '08

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.

10 15

question re the "fate" of ns-v6.ripe.net
by Wilfried Woeber, UniVie/ACOnet 20 Nov '08

20 Nov '08

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.

1 0

Survey on a "Technology Backdrop": please participate
by Mohsen Souissi 19 Nov '08

19 Nov '08

[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.

1 0

one more effort on the NTIA response
by Jim Reid 18 Nov '08

18 Nov '08

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.

19 32

Call for Support of our NTIA response posted
by Peter Koch 15 Nov '08

15 Nov '08

Dear DNS WG, the draft NTIA response has now been forwarded to the general RIPE discussion list <http://www.ripe.net/ripe/maillists/archives/ripe-list/2008/msg00048.html> 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.

1 0

final? draft of NTIA response
by Jim Reid 13 Nov '08

13 Nov '08

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.

7 8

HELP
by Support 12 Nov '08

12 Nov '08

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(a)on-communications.com admin-c: GILL1-RIPE tech-c: GILL1-RIPE zone-c: GILL1-RIPE changed: support(a)on-communications.com mnt-by: ON-COMMS-MNT source: RIPE ***Warning: Date '20081112' added to changed: attribute ' support(a)on-communications.com' ***Warning: Date '20081112' added to changed: attribute ' support(a)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 <http://www.on-communications.com/> *www.on-communications.com* <http://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"

2 1

NTIA NoI: does anyone care?
by Jim Reid 10 Nov '08

10 Nov '08

So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh. Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list. I think this WG has an obligation to make some sort of "official" response to the NTIA's consultation. After all, we played our part to get the ball rolling by producing the "sign the root" letter to ICANN at the Tallinn meeting. So now that there are some concrete proposals for consideration, I feel the WG should look at them and respond. I would also welcome suggestions from WG members about how to stimulate a discussion here about the NTIA proposals. Although time has been set aside in the RIPE57 agenda, that won't be enough. The majority of people on this list won't be in Dubai. And besides, it's really the list that should decide the WG's opinion and what action it should take. Over to you....

20 68

NTIA response - v5
by Jim Reid 08 Nov '08

08 Nov '08

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.

5 9

Input from the ICANN meeting in Cairo
by Patrik Fältström 08 Nov '08

08 Nov '08

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

2 1

Input from the ICANN meeting in Cairo
by Patrik Fältström 08 Nov '08

08 Nov '08

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

1 0

revised text for NTIA response - v4
by Jim Reid 06 Nov '08

06 Nov '08

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.

5 16

Re: [dns-wg] NTIA response - v5
by ololocc＠entratek.com 06 Nov '08

06 Nov '08

Please unsubscribe cc_ololo(a)yahoo.com ------Original Message------ From: Jim Reid Sender: dns-wg-admin(a)ripe.net To: bmanning(a)vacation.karoshi.com Cc: dns-wg(a)ripe.net Sent: Nov 6, 2008 7:25 AM Subject: Re: [dns-wg] NTIA response - v5 On Nov 5, 2008, at 23:01, bmanning(a)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

1 0