From Bobby.olander at comhem.com Thu Aug 11 14:07:32 2005 From: Bobby.olander at comhem.com (=?iso-8859-1?Q?Bobby_=D6lander?=) Date: Thu, 11 Aug 2005 14:07:32 +0200 Subject: [dns-wg] DNS hardware Message-ID: Hello! I'm working at a company called Com Hem AB in Sweden, we are at the moment the biggest cabelnetwork company in Sweden. I have a question that concerns the hardware in the server that should be a primary DNS (even the hardware on the secondary DNS could be nice to know about). What I wonder most about is, should the primary DNS be build with a RAID-system? Or is that not importent of the fact there is a secondary DNS? Respectfully, Bobby ?lander NOC Com Hem AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Thu Aug 11 16:51:13 2005 From: jim at rfc1035.com (Jim Reid) Date: Thu, 11 Aug 2005 15:51:13 +0100 Subject: [dns-wg] DNS hardware In-Reply-To: References: Message-ID: <45B5191A-2B57-4818-B22B-71819FA7FB90@rfc1035.com> On Aug 11, 2005, at 13:07, Bobby ?lander wrote: > I'm working at a company called Com Hem AB in Sweden, we are at the > moment the biggest cabelnetwork company in Sweden. > > I have a question that concerns the hardware in the server that > should be a primary DNS (even the hardware on the secondary DNS > could be nice to know about). > > What I wonder most about is, should the primary DNS be build with a > RAID-system? Or is that not importent of the fact there is a > secondary DNS? Bobby, it is not possible to answer your questions in detail. It's not clear what your company's requirements are or what sort of DNS service is needed: number of queries, authoritative or caching (or both!) name servers, frequency of zone file & configuration file changes, number of zones & RRs to serve, SLAs, peak and steady-state throughput, etc, etc. Without this information, all you can expect here is educated guesswork. Perhaps someone on the WG could work with you to document your requirements and devise a suitable DNS infrastructure. After that comes the hardware specification... Unless you will be managing huge datasets -- eg hundreds of thousands of zones and/or millions of resource records -- a RAID solution would be overkiil. For DNS, the most significant advantage of RAID would be the facility to hot-swap broken disk drives. That would reduce the window where customers couldn't update their zone files. Most name servers store everything in RAM and will generally only load zone files from disk when they start. So having the DNS data "backed up" by a RAID system is unlikely to be worth it. Unless of course fixing a broken drive and restoring from backup takes so long that it annoys your customers . Or embarrasses your management. The DNS is designed to be resilient and can cope with server outages. So if one of the name servers for a zone dies, the others will seamlessly pick up the load. The only exception concerns the zone's master (primary) server. This is the *only* place where the contents of a zone can be changed. So if the master server dies, the zone can't be updated until it returns. The other servers for the zone will of course continue to answer queries for that zone. They'll automatically resynchronise with the master once it's back on-line too. Memory provision is usually more important for a name server than the CPU or disk subsystem because name servers almost always store everything in RAM. The amount of RAM depends on the number of zones and resource records the name server loads. [A good rule of thumb for BIND is allow 1K of RAM for each zone and 100 bytes for each RR.] The number of queries the server gets can also be a factor. Big Iron is rarely if ever justified for DNS. Commodity hardware is often used though some people prefer low-end Sun/IBM/HP boxes because they neatly fill a 1U or 2U slot in a 19" rack. From jon at menandmice.com Thu Aug 11 14:59:18 2005 From: jon at menandmice.com (Jon Adalsteinsson) Date: Thu, 11 Aug 2005 14:59:18 +0200 Subject: [dns-wg] DNS hardware In-Reply-To: Message-ID: <1088357312-67099865@mail.menandmice.is> Hello Bobby I saw your e-mail by coincidence. I cannot answer your question myself however I know people within my company who are experts on this and could provide you with answers to this and other DNS related questions. They have been doing such installations all over the world for several years. Please bear with me if this is not in line with the etiquette on this mailing list but if you like I could set up a phone conversation with one of those experts. Kind Regards, Jon Adalsteinsson Men&Mice Engineer Mobile +41 79 320 92 70 www.menandmice.com _____ From: dns-wg-admin at ripe.ne thant [mailto:dns-wg-admin at ripe.net] On Behalf Of Bobby ?lander Sent: Thursday, August 11, 2005 2:08 PM To: dns-wg-chair at ripe.net Subject: [dns-wg] DNS hardware Hello! I'm working at a company called Com Hem AB in Sweden, we are at the moment the biggest cabelnetwork company in Sweden. I have a question that concerns the hardware in the server that should be a primary DNS (even the hardware on the secondary DNS could be nice to know about). What I wonder most about is, should the primary DNS be build with a RAID-system? Or is that not importent of the fact there is a secondary DNS? Respectfully, Bobby ?lander NOC Com Hem AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at peter-dambier.de Thu Aug 11 16:51:00 2005 From: peter at peter-dambier.de (Peter Dambier) Date: Thu, 11 Aug 2005 16:51:00 +0200 Subject: [dns-wg] DNS hardware In-Reply-To: References: Message-ID: <42FB65D4.1070302@peter-dambier.de> Bobby ?lander wrote: > Hello! > > I'm working at a company called Com Hem AB in Sweden, we are at the > moment the biggest cabelnetwork company in Sweden. > > I have a question that concerns the hardware in the server that should > be a primary DNS (even the hardware on the secondary DNS could be nice > to know about). > > What I wonder most about is, should the primary DNS be build with a > RAID-system? Or is that not importent of the fact there is a secondary DNS? > > Respectfully, > > Bobby ?lander > NOC > Com Hem AB The secondary DNS is important because the primary from time has to reload its database. During that time it wont answer any queries. So the sondary will play it role for that short time. The same goes for the secondary when it updates its database from the primary. When running, bind does not use the disk at all. Only for logging, loading and updating you need a disk. I have seen bind running from ram disk or flash. Regards, Peter Dambier Public-Root -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) +1-360-448-1275 (VoIP: freeworldialup.com) mail: peter at peter-dambier.de http://iason.site.voila.fr http://www.kokoom.com/iason From jim at rfc1035.com Thu Aug 11 17:07:06 2005 From: jim at rfc1035.com (Jim Reid) Date: Thu, 11 Aug 2005 16:07:06 +0100 Subject: [dns-wg] DNSSEC Policy Development Process Message-ID: Colleagues, you may recall Olaf posted a proposal to the list a few weeks ago. It was about changes to the in-addr.arpa delegation process to accommodate DNSSEC. In other words, updates to the templates and database to allow for keying material, additional checks at the NCC, etc, etc. I'm surprised and a little disappointed that nobody has commented on Olaf's proposal. Perhaps the timing was bad. Since the proposal emerged in the run-up to an IETF during the summer holidays, maybe everyone was too busy getting a sun tan or reading the latest IETF I- Ds. :-) Olaf suggested a deadline of early August for the consultation period. There's been no response on the list, so I'm reluctant to declare consensus without some feedback from the WG. It would not be wise to presume that the WG's silence implied unqualified consent. So, following a discussion with Peter and Jaap, your WG co-chairs have decided to extend the deadline for comments until the end of August. The WG chairs have a meeting on Aug 31st, so that would be a good opportunity to take the proposed policy forward. I would like to ask all members of the WG to read Olaf's proposal and comment on it before Aug 31st, even if it's just to say that you think the proposal is fine as it is. Your comments and feedback would be greatly appreciated. Thanks. From jim at rfc1035.com Thu Aug 11 17:14:38 2005 From: jim at rfc1035.com (Jim Reid) Date: Thu, 11 Aug 2005 16:14:38 +0100 Subject: [dns-wg] DNS hardware In-Reply-To: <1088357312-67099865@mail.menandmice.is> References: <1088357312-67099865@mail.menandmice.is> Message-ID: <815E6C9B-23AC-4FC0-848E-164701316F52@rfc1035.com> Jon, your reply came a little too close to a salespitch IMO. Please try to make sure that the DNS WG mailing list maintains a very high signal-to-noise ratio. In other words, technical discussions, good: advertising messages, bad. From pim at bit.nl Thu Aug 11 17:36:56 2005 From: pim at bit.nl (Pim van Pelt) Date: Thu, 11 Aug 2005 17:36:56 +0200 Subject: [pim@bit.nl: Re: [dns-wg] DNS hardware] Message-ID: <20050811153656.GA3594@localhost.localdomain> Hi, Sorry for duplicates, I group-replied and the reply seems to have went to dns-wg-chair. Here's my original response to Bobby's question: | I have a question that concerns the hardware in the server that should | be a primary DNS (even the hardware on the secondary DNS could be nice | to know about). | What I wonder most about is, should the primary DNS be build with a | RAID-system? Or is that not importent of the fact there is a secondary | DNS? It depends on the software you will be running and the amount of queries per second you plan on answering. In the case of bind(9), disk access is low because the server loads zonedata into memory. Other software products (tinydns, nsd) use mmap()ed files, so they access disk but I don't think it'll be that much, because those pages are mapped into memory if you have enough of it. For the ISP I work for [medium sized ISP in the Netherlands], we have two diskless P4 boxes and they each answer some 100qps. They are not loaded or busy at all, and happen to also serve as DNScache [using djbdns stuff at 500qps] and an SNTP service. nsauth1 up 139+08:53, load 0.17, 0.22, 0.23 FreeBSD/i386 (4.10-RELEASE-p5) nsauth2 up 139+09:09, load 0.03, 0.02, 0.02 FreeBSD/i386 (4.10-RELEASE-p5) nsauth3 up 246+14:55, load 0.05, 0.08, 0.07 FreeBSD/i386 (4.10-RELEASE-p5) The difference in load is because most of our customers use nsauth1 as caching nameserver and nsauth2/nsauth3 hardly ever gets hit. groet, Pim -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From jon at menandmice.com Thu Aug 11 21:04:57 2005 From: jon at menandmice.com (Jon Adalsteinsson) Date: Thu, 11 Aug 2005 21:04:57 +0200 Subject: [dns-wg] DNS hardware In-Reply-To: <815E6C9B-23AC-4FC0-848E-164701316F52@rfc1035.com> Message-ID: <1088335376-68413679@mail.menandmice.is> Jim I agree with you. I will keep that in mind for future. cheers jon > -----Original Message----- > From: Jim Reid [mailto:jim at rfc1035.com] > Sent: Thursday, August 11, 2005 5:15 PM > To: Jon Adalsteinsson > Cc: Bobby ?lander; dns-wg at ripe.net; Carsten Strotmann > Subject: Re: [dns-wg] DNS hardware > > Jon, your reply came a little too close to a salespitch IMO. > Please try to make sure that the DNS WG mailing list > maintains a very high signal-to-noise ratio. In other words, > technical discussions, good: > advertising messages, bad. > > > From contact at internetprogress.org Fri Aug 12 04:58:27 2005 From: contact at internetprogress.org (contact at internetprogress.org) Date: Fri, 12 Aug 2005 04:58:27 +0200 Subject: [dns-wg] To post to this list Message-ID: <001d01c59ee9$b6b1c780$6601a8c0@telenet.be> To post to this list, my emailadress : contact at internetprogress.org Sincerely, Guy Lombart -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Aug 11 20:04:39 2005 From: randy at psg.com (Randy Bush) Date: Thu, 11 Aug 2005 08:04:39 -1000 Subject: [dns-wg] DNS hardware References: Message-ID: <17147.37687.460315.829764@roam.psg.com> > I have a question that concerns the hardware in the server that should be > a primary DNS (even the hardware on the secondary DNS could be nice to > know about). how many zones? randy From brettcarr at ripe.net Wed Aug 17 11:47:12 2005 From: brettcarr at ripe.net (Brett Carr) Date: Wed, 17 Aug 2005 11:47:12 +0200 Subject: [dns-wg] ccTLD Mailing List Message-ID: <200508170947.j7H9lCmq012312@birch.ripe.net> The RIPE NCC have setup a new mailing list aimed at ccTLD operators. The aim of the list is to: 1. Enable ccTLD operators to discuss DNS and other operational Internet issues. 2. Enable the RIPE NCC to communicate with many ccTLD operators in a single forum (For issues related to secondary DNS etc) If you are a ccTLD operator please feel free to sign up to the list here: http://www.ripe.net/mailman/listinfo/cctld Regards -- Brett Carr Ripe Network Coordination Centre Systems Engineer -- Operations Group Singel 258 Amsterdam NL GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 From ripe-wgs.cs at schiefner.de Wed Aug 17 12:10:48 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 17 Aug 2005 12:10:48 +0200 Subject: [dns-wg] ccTLD Mailing List In-Reply-To: <200508170947.j7H9lCmq012312@birch.ripe.net> References: <200508170947.j7H9lCmq012312@birch.ripe.net> Message-ID: <43030D28.50709@schiefner.de> Brett, could you please briefly outline by what means this list would distinguish itself from apparently very similar, already existing lists in that area? Thanks and best, Carsten Brett Carr wrote: > The RIPE NCC have setup a new mailing list aimed at ccTLD operators. > > The aim of the list is to: > > 1. Enable ccTLD operators to discuss DNS and other operational Internet > issues. > 2. Enable the RIPE NCC to communicate with many ccTLD operators in a single > forum (For issues related to secondary DNS etc) > > If you are a ccTLD operator please feel free to sign up to the list here: > > http://www.ripe.net/mailman/listinfo/cctld > > Regards > > -- > Brett Carr Ripe Network Coordination Centre > Systems Engineer -- Operations Group Singel 258 Amsterdam NL > GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 From brettcarr at ripe.net Wed Aug 17 13:55:21 2005 From: brettcarr at ripe.net (Brett Carr) Date: Wed, 17 Aug 2005 13:55:21 +0200 Subject: [dns-wg] RE ccTLD Mailing List In-Reply-To: <43030D28.50709@schiefner.de> Message-ID: <200508171155.j7HBtLmq015227@birch.ripe.net> Hi, > -----Original Message----- > From: ncc-services-wg-admin at ripe.net > [mailto:ncc-services-wg-admin at ripe.net] On Behalf Of Carsten Schiefner > Sent: 17 August 2005 12:11 > To: dns-wg at ripe.net; ncc-services-wg at ripe.net > Subject: [ncc-services-wg] ccTLD Mailing List > > Brett, > > could you please briefly outline by what means this list > would distinguish itself from apparently very similar, > already existing lists in that area? > My apologies for any confusion my announcement may of caused. This list is primarily to improve communications between the RIPE NCC and ccTLD's that we provide secondary DNS service for. It is not intended to take away discussions from any other lists all of which do a fine job in their current format. To clarify this is a closed list and you only need to subscribe to it if you are a ccTLD operator and have secondary DNS provided by the NCC. If there is another list which contains a large proportion of the relevant ccTLD operators then I was not aware of it. Regards Brett -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 From Ed.Lewis at neustar.biz Wed Aug 17 15:28:56 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 17 Aug 2005 09:28:56 -0400 Subject: [dns-wg] ccTLD Mailing List In-Reply-To: <43030D28.50709@schiefner.de> References: <200508170947.j7H9lCmq012312@birch.ripe.net> <43030D28.50709@schiefner.de> Message-ID: Carsten, Just so we can self-check, what other lists do you think ccTLD operators should be on? At 12:10 +0200 8/17/05, Carsten Schiefner wrote: >Brett, > >could you please briefly outline by what means this list would >distinguish itself from apparently very similar, already existing >lists in that area? > >Thanks and best, > > Carsten > >Brett Carr wrote: >> The RIPE NCC have setup a new mailing list aimed at ccTLD operators. >> The aim of the list is to: >> 1. Enable ccTLD operators to discuss DNS and other operational Internet >> issues. >> 2. Enable the RIPE NCC to communicate with many ccTLD operators in a single >> forum (For issues related to secondary DNS etc) >> If you are a ccTLD operator please feel free to sign up to the list here: >> http://www.ripe.net/mailman/listinfo/cctld >> Regards >> -- >> Brett Carr Ripe Network Coordination Centre >> Systems Engineer -- Operations Group Singel 258 Amsterdam NL >> GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From ripe-wgs.cs at schiefner.de Fri Aug 19 16:09:59 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 19 Aug 2005 16:09:59 +0200 Subject: [dns-wg] RE ccTLD Mailing List In-Reply-To: <200508171155.j7HBtLmq015227@birch.ripe.net> References: <200508171155.j7HBtLmq015227@birch.ripe.net> Message-ID: <4305E837.60606@schiefner.de> Hi Brett, Brett Carr wrote: >>could you please briefly outline by what means this list >>would distinguish itself from apparently very similar, >>already existing lists in that area? > > My apologies for any confusion my announcement may of caused. > > This list is primarily to improve communications between the RIPE NCC and > ccTLD's that we provide secondary DNS service for. > It is not intended to take away discussions from any other lists all of > which do a fine job in their current format. > To clarify this is a closed list and you only need to subscribe to it if you > are a ccTLD operator and have secondary DNS provided by the NCC. > > If there is another list which contains a large proportion of the relevant > ccTLD operators then I was not aware of it. thanks for the clarification - this settles my concern that a "me too" list is about to be created for stuff that is being covered already elsewhere. In particular the first bullet point in your original email raised that concern. Best - and have a nice weekend, all: Carsten From ripe-wgs.cs at schiefner.de Fri Aug 19 16:14:20 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 19 Aug 2005 16:14:20 +0200 Subject: [dns-wg] ccTLD Mailing List In-Reply-To: References: <200508170947.j7H9lCmq012312@birch.ripe.net> <43030D28.50709@schiefner.de> Message-ID: <4305E93C.3010005@schiefner.de> Hi Ed, Edward Lewis wrote: > Carsten, > > Just so we can self-check, what other lists do you think ccTLD operators > should be on? comes to my mind, for example - this one also covers technical topics of a wider relevance when they occur. Then there are various regional fora, such as CENTR's Tech WG list for example. Although they partly might be restricted to members only. Best, Carsten From sanz at denic.de Tue Aug 23 16:56:49 2005 From: sanz at denic.de (Marcos Sanz/Denic) Date: Tue, 23 Aug 2005 16:56:49 +0200 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: Message-ID: Olaf, Jim, all, > Colleagues, you may recall Olaf posted a proposal to the list a few > weeks ago. It was about changes to the in-addr.arpa delegation > process to accommodate DNSSEC. In other words, updates to the > templates and database to allow for keying material, additional > checks at the NCC, etc, etc. To my eyes the proposal is good and I am happy somebody is taking the plunge. Congratulations. Two comments: http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html To a layman, the meaning of DLV can't be tracked down. A reference missing? http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html I suggest making the ds-rdata attribute an [inverse key] Best regards, Marcos From jim at rfc1035.com Tue Aug 23 17:35:09 2005 From: jim at rfc1035.com (Jim Reid) Date: Tue, 23 Aug 2005 16:35:09 +0100 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: References: Message-ID: > http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html > To a layman, the meaning of DLV can't be tracked down. A reference > missing? Thanks for your comments Marcos. I personally think the reference to DLV needs to be replaced with something more generic. IIUC, so far nothing has been openly published about Domain Lookaside Validation and the code supporting it in BIND9.3 doesn't work. It may be that production quality DLV never sees the light of day or that some other (ad hoc?) mechanisms emerge for establishing DNSSEC trust anchors. And since the NCC is supposed to be neutral, it shouldn't be seen to be favouring one technique/kludge over another. [Even though nothing else like DLV seems to be on the horizon at present.] And since the authors of DLV hope this scheme would be short-lived, it may not be a good idea to explicitly mention DLV in a policy document. Whenever DLV died or got superseded, the document would need to be updated if it mentioned DLV. So from that perspective, it may be better if the text in the proposal was made more generic. Perhaps it should say something like "The NCC would consider publishing its KSKs in appropriate registries that may emerge to facilitate the establishment of DNSSEC trust anchors"? Another suggestion: how about establishing a trust anchor for .arpa and have the NCC's KSKs signed by that? This might help the other RIRs to sign their reverse trees or allow DNSSEC to spread into the IPv6 and ENUM worlds. Any comments? From sanz at denic.de Tue Aug 23 17:52:06 2005 From: sanz at denic.de (Marcos Sanz/Denic) Date: Tue, 23 Aug 2005 17:52:06 +0200 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: Message-ID: Jim, > I personally think the reference to DLV needs to be replaced with > something more generic I concur. > So from that perspective, it may be better if the text in the > proposal was made more generic. Perhaps it should say something like > "The NCC would consider publishing its KSKs in appropriate registries > that may emerge to facilitate the establishment of DNSSEC trust > anchors"? I don't think that would be even necessary. The document already states " Maintenance of these keys is a process that does not scale well. We are working to come up with a solution to this issue." > how about establishing a trust anchor for .arpa > and have the NCC's KSKs signed by that? Is .arpa signed? Regards, Marcos From shane at ripe.net Tue Aug 23 17:54:34 2005 From: shane at ripe.net (Shane Kerr) Date: Tue, 23 Aug 2005 17:54:34 +0200 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: References: Message-ID: <430B46BA.3060801@ripe.net> Marcos, Marcos Sanz/Denic wrote: >http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html >I suggest making the ds-rdata attribute an [inverse key] > > Yes, that makes sense. Unless there are objections, we will implent this in the server. -- Shane Kerr RIPE NCC From jim at rfc1035.com Tue Aug 23 18:12:33 2005 From: jim at rfc1035.com (Jim Reid) Date: Tue, 23 Aug 2005 17:12:33 +0100 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: References: Message-ID: On Aug 23, 2005, at 16:52, Marcos Sanz/Denic wrote: > Is .arpa signed? No. But it should be orders of magnitude easier to do that than get DLV to fly. :-) In principle IAB could sign .arpa tomorrow, assuming someone was able and willing to hold its KSKs. From jaap at NLnetLabs.nl Wed Aug 24 10:30:59 2005 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 24 Aug 2005 10:30:59 +0200 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: References: Message-ID: <20050824103059.3bcb50bd.jaap@NLnetLabs.nl> On Tue, 23 Aug 2005 16:56:49 +0200 Marcos Sanz/Denic wrote: > > To my eyes the proposal is good and I am happy somebody is taking the > plunge. Congratulations. > Two comments: > > http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html > To a layman, the meaning of DLV can't be tracked down. A reference > missing? As far as I know, at that time there wasn't a publication to refer to at the time that the procedure was published. There are now two: an ID from Sam Weiler and an articl in a Journal from Paul Vixie. It describes similar methods which different details. jaap From jaap at NLnetLabs.nl Wed Aug 24 11:21:33 2005 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 24 Aug 2005 11:21:33 +0200 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: <22ED74A5-65F7-4D30-B06B-B990A9795662@rfc1035.com> References: <20050824103059.3bcb50bd.jaap@NLnetLabs.nl> <22ED74A5-65F7-4D30-B06B-B990A9795662@rfc1035.com> Message-ID: <20050824112133.56858e40.jaap@NLnetLabs.nl> On Wed, 24 Aug 2005 09:36:18 +0100 Jim Reid wrote to me: > > As far as I know, at that time there wasn't a publication to refer to > > at the time that the procedure was published. There are now two: an ID > > from Sam Weiler and an articl in a Journal from Paul Vixie. It > > describes similar methods which different details. > > Hi Jaap. Any chance you could dig out the URLs and post them to the > list? In the ietf namedrop archive is an announcement (http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00807.html) which leads to Pauls paper: http://ietcom.oxfordjournals.org/cgi/content/abstract/E88-B/4/1326 and mentions the early version of Weiler's paper (S. Weiler, "Deploying DNSSEC Without a Signed Root", Technical report 1999-19, Information Networking Institute, Carnegie Mellon University, April 2004.). The draft is of course at the usual place: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-andrews-dlv-dns-rr-00.txt. jaap From Ed.Lewis at neustar.biz Fri Aug 26 22:22:18 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 26 Aug 2005 16:22:18 -0400 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: References: Message-ID: At 17:12 +0100 8/23/05, Jim Reid wrote: >On Aug 23, 2005, at 16:52, Marcos Sanz/Denic wrote: > >> Is .arpa signed? > >No. But it should be orders of magnitude easier to do that than get >DLV to fly. >:-) In principle IAB could sign .arpa tomorrow, assuming someone was able and >willing to hold its KSKs. Don't forget "in-addr.arpa." and "ip6.arpa." - they delegate some of NCC's zones. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From randy at psg.com Fri Aug 26 22:26:28 2005 From: randy at psg.com (Randy Bush) Date: Fri, 26 Aug 2005 10:26:28 -1000 Subject: [dns-wg] DNSSEC Policy Development Process References: Message-ID: <17167.31476.248208.366464@roam.psg.com> >>> Is .arpa signed? >> No. But it should be orders of magnitude easier to do that than get >> DLV to fly. >> :-) In principle IAB could sign .arpa tomorrow, assuming someone was able >> and willing to hold its KSKs. > Don't forget "in-addr.arpa." and "ip6.arpa." - they delegate some of > NCC's zones. and don't forget that this does not scale. manual coordination to maintain trusted keys for 292 tlds just does not work. and that assumes that the tlds are signed, not counting all the thrid and ninth level zones that make noise when the zones above them are not signed. this does not fly until the root is signed. and that does not fly until there is a key management plan and technology for it. randy From weiler+lists.dns-wg at watson.org Sat Aug 27 01:24:15 2005 From: weiler+lists.dns-wg at watson.org (Sam Weiler) Date: Fri, 26 Aug 2005 16:24:15 -0700 (PDT) Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: <20050824112133.56858e40.jaap@NLnetLabs.nl> References: <20050824103059.3bcb50bd.jaap@NLnetLabs.nl> <22ED74A5-65F7-4D30-B06B-B990A9795662@rfc1035.com> <20050824112133.56858e40.jaap@NLnetLabs.nl> Message-ID: <20050826162105.M35597@fledge.watson.org> On Wed, 24 Aug 2005, Jaap Akkerhuis wrote: > mentions the early version of Weiler's paper (S. Weiler, "Deploying > DNSSEC Without a Signed Root", Technical report 1999-19, Information > Networking Institute, Carnegie Mellon University, April 2004.). Available here: http://www.watson.org/~weiler/INI1999-19.pdf > The draft is of course at the usual place: > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-andrews-dlv-dns-rr-00.txt. The above i-d only describes the DLV resource record. A more detailed draft specification describing what to do with the RRs was posted to the dnssec-deployment list in May and can be found here: http://www.watson.org/~weiler/dlv/draft-weiler-dnssec-dlv-pre00.txt -- Sam From dogwallah at gmail.com Sat Aug 27 08:35:42 2005 From: dogwallah at gmail.com (McTim) Date: Sat, 27 Aug 2005 09:35:42 +0300 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: References: Message-ID: Hi Jim, If I may bring this thread back on track. I don't know why the WG is asked to comment on procedure as well as policy, but here goes: What does "reasonable" mean in the below sentence on: http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html "Is the signature validity period close to expiring and are the Times To Live (TTLs) a reasonable fraction of the signature validity period?" I'm confused about this para on same page: "Web Interface Restrictions We will develop a web interface to make it easy to create domain objects with the appropriate "ds-rdata:" attributes. It will have some operational restrictions It will use the SEP flag to select the keys for which DSRRs are needed. It will use the "ds-rdata:" attribute of the domain object currently available in the RIPE Whois Database to select the appropriate default DNSKEY RR. It will then select a new "ds-rdata:" attribute." How do you use the "currently available object" to create an object if this object doesn't exist until you create it? I am clearly missing smt, but it escapes me at the moment. I support Jim's suggestion in re: generic replacement of "DLV" mention. The rest looks fine to me, -- Cheers, McTim nic-hdl: TMCG From jim at rfc1035.com Mon Aug 29 16:10:14 2005 From: jim at rfc1035.com (Jim Reid) Date: Mon, 29 Aug 2005 15:10:14 +0100 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: <17167.31476.248208.366464@roam.psg.com> References: <17167.31476.248208.366464@roam.psg.com> Message-ID: <5908CE52-E2CD-4CA7-94CE-365E9C529D4A@rfc1035.com> On Aug 26, 2005, at 21:26, Randy Bush wrote: >>> In principle IAB could sign .arpa tomorrow, assuming someone was >>> able >>> and willing to hold its KSKs. >>> >> Don't forget "in-addr.arpa." and "ip6.arpa." - they delegate some of >> NCC's zones. > > and don't forget that this does not scale. Randy, you've confused me. What aspect of DNSSEC specifically "does not scale"? Do you mean having everyone embed trust anchors in their name server configurations for every signed TLD while we wait for the root to be signed? If so, I agree that's not scalable. But that's not what was under discussion here. At least I hope it wasn't. > manual coordination to maintain trusted keys for 292 tlds just > does not work. and that assumes that the tlds are signed, not > counting all the thrid and ninth level zones that make noise > when the zones above them are not signed. I raised the prospect of getting .arpa signed, not 292 tlds. If this was done, there would be one trust anchor for infrastructure zones and that should simplify things in the context of the NCC's proposals for deploying DNSSEC. Perhaps that might help the other RIRs to follow the NCC's lead. It should also allow us to get operational experience in handling keying material, signing policies and so on that could inform the discussion on getting the root signed. ie Once the layer-9 stuff about that stopped (if it ever will), the lessons learned from gradually deploying DNSSEC in .arpa could provide a valuable knowledge base of practical experience to draw on. > this does not fly until the root is signed. and that does not > fly until there is a key management plan and technology for it. Well yes. But somebody has to start somewhere. IMO signing .arpa could/should be a stepping stone towards that goal. Please note these are my personal opinions and the usual disclaimers apply. From brettcarr at ripe.net Mon Aug 29 17:00:38 2005 From: brettcarr at ripe.net (Brett Carr) Date: Mon, 29 Aug 2005 17:00:38 +0200 (CEST) Subject: [dns-wg] Ripe NCC DNSSEC Deployment Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today (Monday 29/08/2005) the RIPE NCC continued their DNSSEC deployment by beginning to sign the following zones: ripencc.com ripencc.net ripe-ncc.com ripe-ncc.net ripencc.org ripe-ncc.org As we are currently testing the success of this deployment step we have not yet publicly announced the keys. Please do not configure keys until they appear on http://www.ripe.net/projects/disi/keys/ The next step in our deployment plan is: During the first week of September: sign the ripe.net zone and publish the public keys for all signed zones at http://www.ripe.net/projects/disi/keys/ Regards - -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFDEyJ6P/nJBHjtetsRAldiAJ9B38xY+CnGLuZkarvgDcNwnKpROgCeO6vh t/Bf1vrYs0CAO2iGl2h7mys= =yr+J -----END PGP SIGNATURE----- From brettcarr at ripe.net Mon Aug 29 18:34:09 2005 From: brettcarr at ripe.net (Brett Carr) Date: Mon, 29 Aug 2005 18:34:09 +0200 (CEST) Subject: [dns-wg] Ripe NCC DNSSEC Deployment In-Reply-To: References: Message-ID: On Mon, 29 Aug 2005, Fearghas McKay wrote: > Brett > > Would it be possible to send this as an inline text announcement rather > than an attached ascii text file ? > Certainly here you go, and apologies for anybody else who had difficulty reading it in it's original format. Brett -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today (Monday 29/08/2005) the RIPE NCC continued their DNSSEC deployment by beginning to sign the following zones: ripencc.com ripencc.net ripe-ncc.com ripe-ncc.net ripencc.org ripe-ncc.org As we are currently testing the success of this deployment step we have not yet publicly announced the keys. Please do not configure keys until they appear on http://www.ripe.net/projects/disi/keys/ The next step in our deployment plan is: During the first week of September: sign the ripe.net zone and publish the public keys for all signed zones at http://www.ripe.net/projects/disi/keys/ Regards - -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFDEyJ6P/nJBHjtetsRAldiAJ9B38xY+CnGLuZkarvgDcNwnKpROgCeO6vh t/Bf1vrYs0CAO2iGl2h7mys= =yr+J -----END PGP SIGNATURE----- From randy at psg.com Mon Aug 29 19:06:51 2005 From: randy at psg.com (Randy Bush) Date: Mon, 29 Aug 2005 07:06:51 -1000 Subject: [dns-wg] DNSSEC Policy Development Process References: <17167.31476.248208.366464@roam.psg.com> <5908CE52-E2CD-4CA7-94CE-365E9C529D4A@rfc1035.com> Message-ID: <17171.16555.563234.895726@roam.psg.com> > Randy, you've confused me. What aspect of DNSSEC specifically "does > not scale"? Do you mean having everyone embed trust anchors in their > name server configurations for every signed TLD while we wait for the > root to be signed? yep > If so, I agree that's not scalable. But that's not what was under > discussion here. At least I hope it wasn't. no. you just want me to hold the trust keys for the zones you think are important. and, in today's email (for some value of 'today'), brett warns us that he has a handful of third level zones he thinks are important enough. hence "does not scale." randy From jaap at NLnetLabs.nl Tue Aug 30 00:17:42 2005 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 30 Aug 2005 00:17:42 +0200 Subject: [dns-wg] FYI Message-ID: <200508292217.j7TMHgRJ060902@bartok.nlnetlabs.nl> A new Request for Comments is now available in online RFC libraries. BCP 109 RFC 4159 Title: Deprecation of "ip6.int" Author(s): G. Huston Status: Best Current Practice Date: August 2005 Mailbox: gih at apnic.net Pages: 3 Characters: 5353 SeeAlso: BCP0109 I-D Tag: draft-huston-ip6-int-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4159.txt This document advises of the deprecation of the use of "ip6.int" for Standards Conformant IPv6 implementations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO at RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050829145515.RFC at RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4159 --OtherAccess Content-Type: Message/External-body; name="rfc4159.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050829145515.RFC at RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --NextPart-- From olaf at ripe.net Tue Aug 30 09:58:58 2005 From: olaf at ripe.net (Olaf M. Kolkman) Date: Tue, 30 Aug 2005 09:58:58 +0200 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: <17171.16555.563234.895726@roam.psg.com> References: <17167.31476.248208.366464@roam.psg.com> <5908CE52-E2CD-4CA7-94CE-365E9C529D4A@rfc1035.com> <17171.16555.563234.895726@roam.psg.com> Message-ID: <2093AE80-7C10-40CE-9CF6-7A9887AA3FE3@ripe.net> Just extracting one sentence out of Randy's e-mail: > no. you just want me to hold the trust keys for the zones you > think are important. and, in today's email (for some value of > 'today'), brett warns us that he has a handful of third level > zones he thinks are important enough. > > hence "does not scale." RIPE NCC thinks it is important enough to sign the zones. If any of these handful of third level zones is not important enough for your operations to go through the trouble of validating then you do not need to configure them; During early deployment of DNSSEC, there is a burden for the validating clients. I agree that if we do not get to a point where validators only have to configure between one and a handful of trust-anchors and those trust-anchors get automatically rolled DNSSEC will not reach the masses. On the other hand we have to start deploying somewhere. Olaf Kolkman PS: The IETF DNSEXT group has a work item on automatic key-rollover; work is progressing slowly. From olaf at ripe.net Tue Aug 30 10:27:04 2005 From: olaf at ripe.net (Olaf M. Kolkman) Date: Tue, 30 Aug 2005 10:27:04 +0200 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: References: Message-ID: <347AB0B7-9B05-4162-BA35-DE5A50C68C7F@ripe.net> Hello McTim. > I don't know why the WG is asked to comment on procedure as well as > policy, but here goes: > Input on the procedure is more than welcome. Thanks! > What does "reasonable" mean in the below sentence on: > http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html > > "Is the signature validity period close to expiring and are the Times > To Live (TTLs) a reasonable fraction of the signature validity > period?" > This refers to draft-ietf-dnsop-dnssec-operational-practices-04 section 4.1.1. o We suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period. If the TTL would be of similar order as the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section 7.1 of [2] suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL". As a result query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches. To avoid query load peaks we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period. We currently test on the TTL being at least 2 times smaller than the signature validity period. > I'm confused about this para on same page: > > "Web Interface Restrictions > We will develop a web interface to make it easy to create domain > objects with the appropriate "ds-rdata:" attributes. It will have some > operational restrictions > > It will use the SEP flag to select the keys for which DSRRs are > needed. > > It will use the "ds-rdata:" attribute of the domain object currently > available in the RIPE Whois Database to select the appropriate default > DNSKEY RR. It will then select a new "ds-rdata:" attribute." > > How do you use the "currently available object" to create an object if > this object doesn't exist until you create it? > That text applies to when a key rollover is being performed. During the initial upload the default is the DNSKEY RR with the SEP flag set. > I am clearly missing smt, but it escapes me at the moment. > > I support Jim's suggestion in re: generic replacement of "DLV" > mention. On the issue of the DLV registries: the intention is that in the absence of a signed root we will try to participate in initiatives that allow for 'easy' trust anchor maintenance. Since DLV is the only technique currently under discussion so that got hard-wired into the procedure document. As soon as the root and intermediary zones are signed it is probably best to move away from these alternative key distribution mechanism. At this moment there is no working DLV implementation, nor a DLV registry to participate in. I hope this clarifies. --Olaf Kolkman From dogwallah at gmail.com Tue Aug 30 11:11:24 2005 From: dogwallah at gmail.com (McTim) Date: Tue, 30 Aug 2005 12:11:24 +0300 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: <347AB0B7-9B05-4162-BA35-DE5A50C68C7F@ripe.net> References: <347AB0B7-9B05-4162-BA35-DE5A50C68C7F@ripe.net> Message-ID: HI Olafje, On 8/30/05, Olaf M. Kolkman wrote: ttp://www.ripe.net/rs/reverse/dnssec/registry-procedure.html > > > > "Is the signature validity period close to expiring and are the Times > > To Live (TTLs) a reasonable fraction of the signature validity > > period?" > We currently test on the TTL being at least 2 times smaller than the > signature validity period. ok, ta, sounds "reasonable" to me. > > > > I'm confused about this para on same page: > > It will use the "ds-rdata:" attribute of the domain object currently > > available in the RIPE Whois Database to select the appropriate default > > DNSKEY RR. It will then select a new "ds-rdata:" attribute." > > > > How do you use the "currently available object" to create an object if > > this object doesn't exist until you create it? > > > > That text applies to when a key rollover is being performed. During > the initial upload the default is > the DNSKEY RR with the SEP flag set. aha, sorry it wasn't clear to me at the time, it is now. Will it be clear to non-english speakers who try to follow the procedure? Maybe a mention of the key rollover would generate less confusion? > > I hope this clarifies. yes, thnx. -- Greetz, McTim nic-hdl: TMCG From randy at psg.com Tue Aug 30 18:09:38 2005 From: randy at psg.com (Randy Bush) Date: Tue, 30 Aug 2005 06:09:38 -1000 Subject: [dns-wg] DNSSEC Policy Development Process References: <17167.31476.248208.366464@roam.psg.com> <5908CE52-E2CD-4CA7-94CE-365E9C529D4A@rfc1035.com> <17171.16555.563234.895726@roam.psg.com> <2093AE80-7C10-40CE-9CF6-7A9887AA3FE3@ripe.net> Message-ID: <17172.33986.179340.90162@roam.psg.com> > I agree that if we do not get to a point where validators only have > to configure between one and a handful of trust-anchors and those > trust-anchors get automatically rolled DNSSEC will not reach the > masses. > > On the other hand we have to start deploying somewhere. while i do have sympathy for this, when i consider, or try to consider, what the trust model and reliability of low-level roll-out of a hundred or a thousand scattered zones, the mind boggles. as trust keys require manual maintenance, there will be seemingly random failures, real fun debugging, ... and the trust won't distribute, it's SxC. hence, i think of it as more operational practice than deployment. testing whether folk can configure servers and clients, and reconfigure them, and debug them, and ... in a sense, this is a good thing. in another sense, it is expensive at a time when we are not rich. randy From jim at rfc1035.com Tue Aug 30 19:49:45 2005 From: jim at rfc1035.com (Jim Reid) Date: Tue, 30 Aug 2005 18:49:45 +0100 Subject: [dns-wg] DNSSEC Policy Development Process In-Reply-To: <17172.33986.179340.90162@roam.psg.com> References: <17167.31476.248208.366464@roam.psg.com> <5908CE52-E2CD-4CA7-94CE-365E9C529D4A@rfc1035.com> <17171.16555.563234.895726@roam.psg.com> <2093AE80-7C10-40CE-9CF6-7A9887AA3FE3@ripe.net> <17172.33986.179340.90162@roam.psg.com> Message-ID: On Aug 30, 2005, at 17:09, Randy Bush wrote: >> I agree that if we do not get to a point where validators only have >> to configure between one and a handful of trust-anchors and those >> trust-anchors get automatically rolled DNSSEC will not reach the >> masses. >> >> On the other hand we have to start deploying somewhere. > > while i do have sympathy for this, when i consider, or try to > consider, what the trust model and reliability of low-level roll-out > of a hundred or a thousand scattered zones, the mind boggles. as > trust keys require manual maintenance, there will be seemingly random > failures, real fun debugging, ... and the trust won't distribute, > it's SxC. This is why I suggested starting with trying to get .arpa signed. Since it's controlled by the IAB, the zone should be free from the level-9 (and up) issues that infest the root. That would/should mean a single trust anchor for those who wanted to take part in the first faltering steps towards DNSSEC deployment. In the context of what the NCC is proposing, that would mean .arpa signing the KSKs for the stuff delegated by IANA to the NCC. This has to be better than having a bunch of trust anchors for each apex under ip6.arpa and in- addr.arpa -- let's not forget e164.arpa too -- that's managed by the NCC. We appear to agree that path is less than desirable. From ddiaz at satec.es Wed Aug 31 09:21:12 2005 From: ddiaz at satec.es (Daniel Diaz) Date: Wed, 31 Aug 2005 09:21:12 +0200 Subject: [dns-wg] DNSSEC Policy Development Process Message-ID: <20050831072115.C57CC24144@postman.ripe.net> Hi, Afaik, the RIPE NCC has polled the Community?s opinion about securing the reverse delegation tree in different ways and occassions and again afaik, there?s always been consensus on this to go forward. Olaf and other NCC colleagues have been working on this for years now (already when I still was at the NCC). After reading the policy, procedure and documents related, I agree with it and think this is a good staring point. As randy says, I see this more as an operational experience previous to full deployment but imho it?s also the closest the RIPE NCC (or any other RIR) can/could do at the moment. I also agree with Jim in taking .arpa as starting point. Imho, 'e164.arpa." could have been a better way to start and gain operational experience first (just for the size of it and the fact, as Jim points out, that it?s managed by the NCC). Still... I agree with the current RIPE NCC plans and procedures. Looking into the documents and procedures, it could be a good idea to produce a "clueless client" oriented document to make this more available to those willing to sign their zones etc... (my 2 cents). Regards. -- Daniel.Diaz DDL14-RIPE