From cet1 at cam.ac.uk Tue Feb 2 16:31:10 2010 From: cet1 at cam.ac.uk (Chris Thompson) Date: 02 Feb 2010 15:31:10 +0000 Subject: [dns-wg] RIPE - ARIN cooperation when registering signed legacy reverse zones? Message-ID: I hope this is the appropriate place to raise this. There are legacy network allocations whose reverse zone is managed via RIPE, but actually delegated from higher level reverse zones run by ARIN. To take a specific example, 131.111/16 is allocated to the University of Cambridge, we manage the delegation info for 111.131.in-addr.arpa via RIPE, but 131.in-addr.arpa belongs to ARIN. Now 111.131.in-addr.arpa is signed (since September 2009), and currently registered at dlv.isc.org. Along with the other high-level ARIN reverse zones, 131.in-addr.arpa is also signed, and https://www.arin.net/resources/dnssec/ indicates that they may be accepting signed delegations Fairly Soon Now (depending on what you think "the first part of 2010" means). Is it understood yet how (or even if) this will work for legacy network allocations? Ideally, this would just be a matter of supplying RIPE with the "ds-rdata" attributes as described in https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html and they would get transferred seamlessly into the ARIN zones (and signed there). -- Chris Thompson University of Cambridge Computing Service, Email: cet1 at ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From andrei at ripe.net Tue Feb 2 19:49:31 2010 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 02 Feb 2010 19:49:31 +0100 Subject: [dns-wg] RIPE - ARIN cooperation when registering signed legacy reverse zones? In-Reply-To: References: Message-ID: <4B6873BB.7010400@ripe.net> Dear Chris, Chris Thompson wrote on 02-02-2010 16:31: > I hope this is the appropriate place to raise this. > > There are legacy network allocations whose reverse zone is managed via > RIPE, but actually delegated from higher level reverse zones run by ARIN. > To take a specific example, 131.111/16 is allocated to the University of > Cambridge, we manage the delegation info for 111.131.in-addr.arpa via > RIPE, but 131.in-addr.arpa belongs to ARIN. > > Now 111.131.in-addr.arpa is signed (since September 2009), and currently > registered at dlv.isc.org. Along with the other high-level ARIN reverse > zones, 131.in-addr.arpa is also signed, and > > https://www.arin.net/resources/dnssec/ > > indicates that they may be accepting signed delegations Fairly Soon Now > (depending on what you think "the first part of 2010" means). > > Is it understood yet how (or even if) this will work for legacy network > allocations? Ideally, this would just be a matter of supplying RIPE with > the "ds-rdata" attributes as described in > > https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html > > and they would get transferred seamlessly into the ARIN zones > (and signed there). > Yes, that's the idea. The RIRs are looking at necessary changes that need to be done to the management of the shared reverse zones to support this. There is no timeline yet, but we should have a better idea mid 2010. Regards, Andrei Robachevsky CTO, RIPE NCC From Woeber at CC.UniVie.ac.at Wed Feb 3 12:14:49 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 03 Feb 2010 11:14:49 +0000 Subject: [dns-wg] RIPE - ARIN cooperation when registering signed legacy reverse zones? In-Reply-To: References: Message-ID: <4B695AA9.7030904@CC.UniVie.ac.at> Chris Thompson wrote: > I hope this is the appropriate place to raise this. I think so :-) > There are legacy network allocations whose reverse zone is managed via > RIPE, but actually delegated from higher level reverse zones run by ARIN. > To take a specific example, 131.111/16 is allocated to the University of > Cambridge, we manage the delegation info for 111.131.in-addr.arpa via > RIPE, but 131.in-addr.arpa belongs to ARIN. > > Now 111.131.in-addr.arpa is signed (since September 2009), and currently > registered at dlv.isc.org. Along with the other high-level ARIN reverse > zones, 131.in-addr.arpa is also signed, and > > https://www.arin.net/resources/dnssec/ Looking at this from a slightly different angle (with ERX in mind) ... Excerpt from the above webpage: "Today, delegations under in-addr.arpa are served by servers operated by ARIN and its contractors,..." Seems to indicate that ARIN has the complete and exclusive control over the full (IPv4-) Reverse Tree? If so, what's the situation for IP6.ARPA? > indicates that they may be accepting signed delegations Fairly Soon Now > (depending on what you think "the first part of 2010" means). > > Is it understood yet how (or even if) this will work for legacy network > allocations? Ideally, this would just be a matter of supplying RIPE with > the "ds-rdata" attributes as described in > > https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html > > and they would get transferred seamlessly into the ARIN zones > (and signed there). Wilfried From bmanning at vacation.karoshi.com Wed Feb 3 12:40:32 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 3 Feb 2010 11:40:32 +0000 Subject: [dns-wg] RIPE - ARIN cooperation when registering signed legacy reverse zones? In-Reply-To: <4B695AA9.7030904@CC.UniVie.ac.at> References: <4B695AA9.7030904@CC.UniVie.ac.at> Message-ID: <20100203114032.GB6588@vacation.karoshi.com.> > > Now 111.131.in-addr.arpa is signed (since September 2009), and currently > > registered at dlv.isc.org. Along with the other high-level ARIN reverse > > zones, 131.in-addr.arpa is also signed, and > > > > https://www.arin.net/resources/dnssec/ > > Looking at this from a slightly different angle (with ERX in mind) ... > > Excerpt from the above webpage: > > "Today, delegations under in-addr.arpa are served by servers operated by > ARIN and its contractors,..." > > Seems to indicate that ARIN has the complete and exclusive control over > the full (IPv4-) Reverse Tree? If so, what's the situation for IP6.ARPA? > > Wilfried plz see the ietf - Protocol Action: 'Nameservers for IPv4 and IPv6 Reverse Zones' to BCP --bill From Woeber at CC.UniVie.ac.at Wed Feb 3 13:28:24 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 03 Feb 2010 12:28:24 +0000 Subject: [dns-wg] RIPE - ARIN cooperation when registering signed legacy reverse zones? In-Reply-To: <20100203114032.GB6588@vacation.karoshi.com.> References: <4B695AA9.7030904@CC.UniVie.ac.at> <20100203114032.GB6588@vacation.karoshi.com.> Message-ID: <4B696BE8.2020106@CC.UniVie.ac.at> Bill, thanks for the pointer to http://www.ietf.org/id/draft-jabley-reverse-servers-01.txt ! I feel that my question was not properly worded :-( bmanning at vacation.karoshi.com wrote: >>>Now 111.131.in-addr.arpa is signed (since September 2009), and currently >>>registered at dlv.isc.org. Along with the other high-level ARIN reverse >>>zones, 131.in-addr.arpa is also signed, and >>> >>> https://www.arin.net/resources/dnssec/ >> >>Looking at this from a slightly different angle (with ERX in mind) ... >> >>Excerpt from the above webpage: >> >>"Today, delegations under in-addr.arpa are served by servers operated by >> ARIN and its contractors,..." >> >>Seems to indicate that ARIN has the complete and exclusive control over >>the full (IPv4-) Reverse Tree? If so, what's the situation for IP6.ARPA? My reading was or rather is: ARIN is managing all zones/master servers for the complete set of 1. level delegation points *below* in-addr.arpa and ip6.arpa. Apologies for still using flawed DNS terminology, maybe, and/or misreading the quoted paragraph! >>Wilfried > > > plz see the ietf - Protocol Action: 'Nameservers for IPv4 and IPv6 Reverse Zones' to BCP > > --bill Wilfried. From daniel.karrenberg at ripe.net Fri Feb 5 11:08:39 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 5 Feb 2010 11:08:39 +0100 Subject: [dns-wg] Measuring DNS Transfer Sizes - First Results Message-ID: <20100205100839.GB21040@reiftel.karrenberg.net> Apologies for the inevitable duplicates. You might be interested in reading about our measurements of real obtained DNS transfer sizes in relation to clients requesting DNSSEC responses. See here http://labs.ripe.net/content/measuring-dns-transfer-sizes-first-results Daniel From anandb at ripe.net Fri Feb 5 14:23:51 2010 From: anandb at ripe.net (Anand Buddhdev) Date: Fri, 05 Feb 2010 14:23:51 +0100 Subject: [dns-wg] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories Message-ID: <4B6C1BE7.9050400@ripe.net> [Apologies for duplicates] Dear Colleagues, We have discovered that recent versions of the Fedora Linux distribution are shipping with a package called "dnssec-conf", which contains the RIPE NCC's DNSSEC trust anchors. This package is installed by default as a dependency of BIND, and it configures BIND to do DNSSEC validation. Unfortunately, the current version of this package (1.21) is outdated and contains old trust anchors. On 16 December 2009, we had a key roll-over event, where we removed the old Key-Signing Keys (KSKs). From that time, BIND resolvers running on Fedora Linux distributions could not validate any signed responses in the RIPE NCC's reverse zones. If you are running Fedora Linux with the standard BIND package, please edit the file "/etc/pki/dnssec-keys//named.dnssec.keys", and comment out all the lines in it containing the directory path "production/reverse". Then restart BIND. This will stop BIND from using the outdated trust anchors. If you do want to use the RIPE NCC's trust anchors to validate our signed zones, we recommend that you fetch the latest trust anchor file from our website and reconfigure BIND to use it instead of the ones distributed in the dnssec-conf package: https://www.ripe.net/projects/disi/keys/index.html Please remember to check frequently for updates to our trust anchor file, as we introduce new Key-Signing Keys (KSKs) every 6 months. Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC From dns at fl1ger.de Fri Feb 5 15:18:46 2010 From: dns at fl1ger.de (Ralf Weber) Date: Fri, 5 Feb 2010 15:18:46 +0100 Subject: [dns-wg] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories In-Reply-To: <4B6C1BE7.9050400@ripe.net> References: <4B6C1BE7.9050400@ripe.net> Message-ID: <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> Moin! On 05.02.2010, at 14:23, Anand Buddhdev wrote: > Please remember to check frequently for updates to our trust anchor > file, as we introduce new Key-Signing Keys (KSKs) every 6 months. With the root planning for much longer time frames on KSK rollovers maybe RIPE NCC should think about increasing it's KSK life times. SO long -Ralf --- Ralf Weber (Internet Citizen) e: dns at fl1ger.de From jim at rfc1035.com Fri Feb 5 15:58:12 2010 From: jim at rfc1035.com (Jim Reid) Date: Fri, 5 Feb 2010 14:58:12 +0000 Subject: [dns-wg] KSK lifetimes In-Reply-To: <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> Message-ID: On 5 Feb 2010, at 14:18, Ralf Weber wrote: > With the root planning for much longer time frames on KSK rollovers > maybe RIPE NCC should think about increasing it's KSK life times. Ralf, I don't follow you. Could you please explain why the NCC should increase the lifetime of its KSKs? Just because "the root's going to have long KSK lifetimes" isn't an answer. :-) As I'm sure you know, there are all sorts of trade-offs that have to be made when choosing key sizes and rollover intervals. And every zone has its own set of requirements and operational criteria. So what's good for one zone may not be so suitable for another. I'd like to hear the reasoning why key management by the NCC should be the same as that for the root, particularly if it goes beyond the usual "if it's good enough for the root, it's good enough for me". FWIW, I regularly make that case when people ask me what DNS software they should run. What I do think would be helpful is a document explaining how the eventual parameters were chosen and the trade-offs/thinking that went into those choices. This is needed for DNSSEC generally as well as for the root zone and the NCC's bits of the .arpa tree. From dns at fl1ger.de Fri Feb 5 16:39:27 2010 From: dns at fl1ger.de (Ralf Weber) Date: Fri, 5 Feb 2010 16:39:27 +0100 Subject: [dns-wg] KSK lifetimes In-Reply-To: References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> Message-ID: Moin! On 05.02.2010, at 15:58, Jim Reid wrote: > On 5 Feb 2010, at 14:18, Ralf Weber wrote: > >> With the root planning for much longer time frames on KSK rollovers >> maybe RIPE NCC should think about increasing it's KSK life times. > > Ralf, I don't follow you. Could you please explain why the NCC should increase the lifetime of its KSKs? Just because "the root's going to have long KSK lifetimes" isn't an answer. :-) As I'm sure you know, there are all sorts of trade-offs that have to be made when choosing key sizes and rollover intervals. And every zone has its own set of requirements and operational criteria. So what's good for one zone may not be so suitable for another. Well the original reason was Anands mail that Fedora delivered an old ripe key. This would not be the case with a key life time of say two years. I always thought that RIPEs schedule was to aggressive wrt to key rollovers. As even in this industry it takes time with people/OS vendors to act. > I'd like to hear the reasoning why key management by the NCC should be the same as that for the root, particularly if it goes beyond the usual "if it's good enough for the root, it's good enough for me". FWIW, I regularly make that case when people ask me what DNS software they should run. I didn't say that and there are good reasons for not having it the same especially not rolling all the keys at the same time. I however think that long term with more zones (think millions) signed there probably will be a best practices for leaf zones. > What I do think would be helpful is a document explaining how the eventual parameters were chosen and the trade-offs/thinking that went into those choices. This is needed for DNSSEC generally as well as for the root zone and the NCC's bits of the .arpa tree. Agreed it would be great to have that. So long -Ralf --- Ralf Weber (Internet Citizen) e: dns at fl1ger.de From jim at rfc1035.com Fri Feb 5 17:05:29 2010 From: jim at rfc1035.com (Jim Reid) Date: Fri, 5 Feb 2010 16:05:29 +0000 Subject: [dns-wg] KSK lifetimes In-Reply-To: References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> Message-ID: On 5 Feb 2010, at 15:39, Ralf Weber wrote: > Well the original reason was Anands mail that Fedora delivered an > old ripe key. This would not be the case with a key life time of > say two years. It would always be a problem if Fedora shipped something with the old keys, no matter what their lifetime was. Stale keys are still stale keys. This sort of problem is always a nuisance on for an OS that depends on informal, volunteer efforts. If the guys working on some tool/project drag their feet or give up, stale code and obsolete configuration data can end up in the distros and repositories. In any case, these alternate trust anchors should hopefully be dead and buried soon. Assuming we have a signed root this summer.... So, given that we should have a signed root Real Soon Now (=> alternate trust anchor schemes fade into oblivion), what impact does that have on the NCC's KSK rollover policy? Will the current schedule be too aggressive or unreasonable when this happens? [And .arpa gets signed of course...] Why? I'd welcome some discussion about this. From Ed.Lewis at neustar.biz Fri Feb 5 16:46:23 2010 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 5 Feb 2010 10:46:23 -0500 Subject: [dns-wg] KSK lifetimes In-Reply-To: References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> Message-ID: At 14:58 +0000 2/5/10, Jim Reid wrote: >On 5 Feb 2010, at 14:18, Ralf Weber wrote: > >> With the root planning for much longer time frames on KSK rollovers >> maybe RIPE NCC should think about increasing it's KSK life times. > >Ralf, I don't follow you. Could you please explain why the NCC should >increase the lifetime of its KSKs? I do not read the message as suggesting that the RIPE NCC match the root zone key management parameters. Instead I read that "there's a new data point available on what the parameters for key management should be, so maybe it is a good time to rethink the RIPE NCC parameters." >Just because "the root's going to have long KSK lifetimes" isn't an >answer. :-) Maybe it is. Odds are that the work being done to sign the root is being carried out by a top-notch staff of individuals - if they emerge with some surprising results, it's worth looking into why. But you are also right, there's no need to match the results. >I'd like to hear the reasoning why key management by the NCC should be the >same as that for the root, particularly if it goes beyond the usual "if it's >good enough for the root, it's good enough for me". FWIW, I regularly make >that case when people ask me what DNS software they should run. Frankly, it's far easier to make the case why not. >What I do think would be helpful is a document explaining how the eventual >parameters were chosen and the trade-offs/thinking that went into those >choices. This is needed for DNSSEC generally as well as for the root zone >and the NCC's bits of the .arpa tree. The reason I jumped in with this reply is that in the last month or so there was an interesting thread in the IETF about the relationship of key size and key effectivity periods. (I.e., is a key of 1024 bits good for a year, a key of 2048 good for 2?) The outcome of the thread was that, if left up to the cryptographic issues, there would be no need to change keys until a key was detected as being broken. This is because the effective lifetime of a key is not determined by the key itself but rather by the determination of the attackers. The moral - you only need to change the key in an emergency. But, as a good operator you know that you never do anything in an emergency you don't do on a regular basis - whether that means regularly exercise the plan in production, in practice, or in drills. So, the parameters for key change fall under the domain of operational cycles and not cryptographic considerations. And, for operators in large organizations, "regularly" means on a strict periodic schedule (such as monthly) - something that can be easily programmed into cron. The realization that it isn't the cryptography limiting the usefulness of the key to me is "new thinking." All along I thought that the limitation on the effectivity of a key was the cryptography - but for "good enough keys" the limitation is how comfortable I am going without changing it and how much does it cost to change it. Based on that discussion, and the fact that root zone is willing to use longer term keys, I'd rethink the 6 month changes of the KSK. Or maybe just because the root will be signed soon and the RIPE NCC DNSSEC keys will ultimately be chained from there (modulo the reverse map's intermediate zones). Further, when we automate all of the registration interfaces, the cost/pain of rolling the KSK goes to almost 0 - maybe frequently change it. OTOH, if we only have to worry about attacks and abuse, maybe we hardly ever change it. As we progress operationally with DNSSEC, we will be learning a lot more. There's no shame in being the first out the door and then learning you can or should adjust your parameters based on the follower's experiences. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From anandb at ripe.net Fri Feb 5 17:26:38 2010 From: anandb at ripe.net (Anand Buddhdev) Date: Fri, 05 Feb 2010 17:26:38 +0100 Subject: [dns-wg] Re: KSK lifetimes In-Reply-To: References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> Message-ID: <4B6C46BE.1030002@ripe.net> On 05/02/2010 15:58, Jim Reid wrote: > What I do think would be helpful is a document explaining how the > eventual parameters were chosen and the trade-offs/thinking that went > into those choices. This is needed for DNSSEC generally as well as for > the root zone and the NCC's bits of the .arpa tree. The RIPE NCC was an early adopter of DNSSEC way back in 2005, and at the time, there was very little operational experience. It was important to exercise the various processes, including key roll-overs. A relatively short roll-over period of 6 months allowed us to invoke our roll-over procedures more frequently. This is especially important as some of our processes are still manual. Things are a bit different now. DNSSEC toolsets have improved, and there are both commercial and open-source products available to handle a lot of the heavy-lifting needed to maintain DNSSEC-signed zones. It would probably be okay to have longer key lifetimes now. Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC From cet1 at cam.ac.uk Fri Feb 5 17:32:20 2010 From: cet1 at cam.ac.uk (Chris Thompson) Date: 05 Feb 2010 16:32:20 +0000 Subject: [dns-wg] KSK lifetimes In-Reply-To: References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> Message-ID: On Feb 5 2010, Jim Reid wrote: [...] >In any case, these alternate trust anchors should hopefully be dead >and buried soon. Assuming we have a signed root this summer.... And a signed arpa, and a signed in-addr.arpa ... ? No announced time scale for *those* yet :-( [I suggested on the dnssec-deployment list a few months ago that removing one or both of the zone cuts between the root and in-addr.arpa might not be a bad thing, but ID draft-jabley-reverse-servers-01 is veering off in a quite different direction...] -- Chris Thompson University of Cambridge Computing Service, Email: cet1 at ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From paul at xelerance.com Fri Feb 5 17:55:04 2010 From: paul at xelerance.com (Paul Wouters) Date: Fri, 5 Feb 2010 11:55:04 -0500 (EST) Subject: [dns-wg] KSK lifetimes In-Reply-To: References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> Message-ID: On Fri, 5 Feb 2010, Edward Lewis wrote: > The outcome of the thread was that, if left up to the cryptographic issues, > there would be no need to change keys until a key was detected as being > broken. This is because the effective lifetime of a key is not determined by > the key itself but rather by the determination of the attackers. The moral - > you only need to change the key in an emergency. I don't think that was the outcome at all. As I read it, the outcome was "cryptographers are even more conservative then DNS operators, because key strength is a function of math & money, but the IETF suggested lifetimes were very safe". > The realization that it isn't the cryptography limiting the usefulness of the > key to me is "new thinking." All along I thought that the limitation on the > effectivity of a key was the cryptography - but for "good enough keys" the > limitation is how comfortable I am going without changing it and how much > does it cost to change it. To that I agree. Paul From paul at xelerance.com Fri Feb 5 17:33:23 2010 From: paul at xelerance.com (Paul Wouters) Date: Fri, 5 Feb 2010 11:33:23 -0500 (EST) Subject: [dns-wg] Re: KSK lifetimes In-Reply-To: <4B6C46BE.1030002@ripe.net> References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> <4B6C46BE.1030002@ripe.net> Message-ID: On Fri, 5 Feb 2010, Anand Buddhdev wrote: > Things are a bit different now. DNSSEC toolsets have improved, and there > are both commercial and open-source products available to handle a lot > of the heavy-lifting needed to maintain DNSSEC-signed zones. It would > probably be okay to have longer key lifetimes now. I think the suggestion was to extend the current keys until July, so that the next rollover would be "covered" by the signed root. Paul From pk at DENIC.DE Fri Feb 5 20:38:56 2010 From: pk at DENIC.DE (Peter Koch) Date: Fri, 5 Feb 2010 20:38:56 +0100 Subject: [dns-wg] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories In-Reply-To: <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> Message-ID: <20100205193856.GA27593@x27.adm.denic.de> On Fri, Feb 05, 2010 at 03:18:46PM +0100, Ralf Weber wrote: > With the root planning for much longer time frames on KSK rollovers > maybe RIPE NCC should think about increasing it's KSK life times. ... or emphasize the point that the NCC's repository of the NCC's trust anchors is the true one and only authoritative repository for the NCC's trust anchors. -Peter From bortzmeyer at nic.fr Mon Feb 8 09:01:23 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 8 Feb 2010 09:01:23 +0100 Subject: [dns-wg] Re: Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories In-Reply-To: <20100205193856.GA27593@x27.adm.denic.de> References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> <20100205193856.GA27593@x27.adm.denic.de> Message-ID: <20100208080123.GA28860@nic.fr> On Fri, Feb 05, 2010 at 08:38:56PM +0100, Peter Koch wrote a message of 10 lines which said: > ... or emphasize the point that the NCC's repository of the NCC's > trust anchors is the true one and only authoritative repository for > the NCC's trust anchors. Very bad idea because it does not scale: I, sysadmin of a validating resolver, certainly cannot go to 42 different https Web pages to extract the one and only authoritative information. From pk at DENIC.DE Mon Feb 8 15:12:40 2010 From: pk at DENIC.DE (Peter Koch) Date: Mon, 8 Feb 2010 15:12:40 +0100 Subject: [dns-wg] Re: Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories In-Reply-To: <20100208080123.GA28860@nic.fr> References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> <20100205193856.GA27593@x27.adm.denic.de> <20100208080123.GA28860@nic.fr> Message-ID: <20100208141240.GM30969@x27.adm.denic.de> On Mon, Feb 08, 2010 at 09:01:23AM +0100, Stephane Bortzmeyer wrote: > Very bad idea because it does not scale: I, sysadmin of a validating > resolver, certainly cannot go to 42 different https Web pages to > extract the one and only authoritative information. well, this may not lead anywhere useful. If you "cannot" make the conscious decision to configure and maintain a set of trust anchors, then there's a variety of options, including "do nothing". This WG has made a statement regarding the unsolicited inclusion of trust anchors in "some" distribution mechanisms in the past and there was also the list of requirements for TARs, which included prior consent of the party responsible for the KSK/TA. Unfortunately, helpful deployment initiatives have turned into obstacles more than once. -Peter From Ed.Lewis at neustar.biz Mon Feb 8 15:33:36 2010 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 8 Feb 2010 09:33:36 -0500 Subject: [dns-wg] Re: Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories In-Reply-To: <20100208141240.GM30969@x27.adm.denic.de> References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> <20100205193856.GA27593@x27.adm.denic.de> <20100208080123.GA28860@nic.fr> <20100208141240.GM30969@x27.adm.denic.de> Message-ID: At 15:12 +0100 2/8/10, Peter Koch wrote: >well, this may not lead anywhere useful. Regretfully I agree with Peter on this point and in that way. ;) No matter how long the Secure Entry Points (aka KSK) are in use, there will be a on-the-shelf piece of equipment that is turned on after the keys are history. Bill Manning made attempts to characterize that problem years ago - the most recent San Diego IETF if I recall correctly. Every time someone has a case that solves for up to N, there's a case for N+1. (Months, zones, servers, years, you name it.) Remember that DNSSEC is there to protect the resolver. I don't think there is any (or going to be any) one way that is manageable, scale-able, non-commercial (and/or open-source), quick, cheap, in-line, dynamic and convenient for zone operators to use to inform all recursive servers that there are new SEPs - whether just for the root zone or for all the zones, or even just for the roots of DNSSEC-ized subtrees. Well, no "one way" known in advance of deployment. Perhaps in two or three years we'll have an answer. Or in two or three years network administrators will just put up with "the jungle out there." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From jaap at NLnetLabs.nl Mon Feb 8 16:01:26 2010 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Mon, 08 Feb 2010 16:01:26 +0100 Subject: [dns-wg] Re: Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories In-Reply-To: References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> <20100205193856.GA27593@x27.adm.denic.de> <20100208080123.GA28860@nic.fr> <20100208141240.GM30969@x27.adm.denic.de> Message-ID: <201002081501.o18F1Qi5024849@bartok.nlnetlabs.nl> The I-D draft-wijngaards-dnsop-trust-history-02.txt by Wijngaards & Kolkman is addressing these type of problems. jaap From bmanning at vacation.karoshi.com Mon Feb 8 16:22:52 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 8 Feb 2010 15:22:52 +0000 Subject: [dns-wg] Re: Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories In-Reply-To: References: <4B6C1BE7.9050400@ripe.net> <3B39BF6A-9537-428C-9123-06E6C40D4EA0@fl1ger.de> <20100205193856.GA27593@x27.adm.denic.de> <20100208080123.GA28860@nic.fr> <20100208141240.GM30969@x27.adm.denic.de> Message-ID: <20100208152252.GA31900@vacation.karoshi.com.> morning Ed - thanks for reminding me. in that vein, there is a pending proposal to provide a proof of concept implementation of Internet-based "over the air" re-keying to facilitate un-scheduled key rollover. We've not (yet) augmented it to inculde an MofN set of hooks - but that would go a -long- way toward the "on the shelf" problem that RFC 5011 does not address well. Once we get it working, it is possible that we might bring it to the IETF for consideration. --bill On Mon, Feb 08, 2010 at 09:33:36AM -0500, Edward Lewis wrote: > At 15:12 +0100 2/8/10, Peter Koch wrote: > > >well, this may not lead anywhere useful. > > Regretfully I agree with Peter on this point and in that way. > > ;) > > No matter how long the Secure Entry Points (aka KSK) are in use, > there will be a on-the-shelf piece of equipment that is turned on > after the keys are history. > > Bill Manning made attempts to characterize that problem years ago - > the most recent San Diego IETF if I recall correctly. Every time > someone has a case that solves for up to N, there's a case for N+1. > (Months, zones, servers, years, you name it.) > > Remember that DNSSEC is there to protect the resolver. I don't think > there is any (or going to be any) one way that is manageable, > scale-able, non-commercial (and/or open-source), quick, cheap, > in-line, dynamic and convenient for zone operators to use to inform > all recursive servers that there are new SEPs - whether just for the > root zone or for all the zones, or even just for the roots of > DNSSEC-ized subtrees. > > Well, no "one way" known in advance of deployment. > > Perhaps in two or three years we'll have an answer. Or in two or > three years network administrators will just put up with "the jungle > out there." > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > As with IPv6, the problem with the deployment of frictionless surfaces is > that they're not getting traction. From brettlists at gmail.com Thu Feb 11 23:27:44 2010 From: brettlists at gmail.com (B C) Date: Thu, 11 Feb 2010 22:27:44 +0000 Subject: [dns-wg] RIPE - ARIN cooperation when registering signed legacy reverse zones? In-Reply-To: <4B696BE8.2020106@CC.UniVie.ac.at> References: <4B695AA9.7030904@CC.UniVie.ac.at> <20100203114032.GB6588@vacation.karoshi.com.> <4B696BE8.2020106@CC.UniVie.ac.at> Message-ID: <5c494b511002111427geaa7cc7u9f88079c9627502d@mail.gmail.com> On Wed, Feb 3, 2010 at 12:28 PM, Wilfried Woeber, UniVie/ACOnet wrote: > Bill, > > thanks for the pointer to http://www.ietf.org/id/draft-jabley-reverse-servers-01.txt ! > > I feel that my question was not properly worded :-( > > bmanning at vacation.karoshi.com wrote: > >>>>Now 111.131.in-addr.arpa is signed (since September 2009), and currently >>>>registered at dlv.isc.org. Along with the other high-level ARIN reverse >>>>zones, 131.in-addr.arpa is also signed, and >>>> >>>> https://www.arin.net/resources/dnssec/ >>> >>>Looking at this from a slightly different angle (with ERX in mind) ... >>> >>>Excerpt from the above webpage: >>> >>>"Today, delegations under in-addr.arpa are served by servers operated by >>> ARIN and its contractors,..." >>> >>>Seems to indicate that ARIN has the complete and exclusive control over >>>the full (IPv4-) Reverse Tree? If so, what's the situation for IP6.ARPA? > > My reading was or rather is: > > ARIN is managing all zones/master servers for the complete set of 1. level > delegation points *below* in-addr.arpa and ip6.arpa. > > Apologies for still using flawed DNS terminology, maybe, and/or misreading > the quoted paragraph! > Well The sentence on the ARIN web page quoted: "Today, delegations under in-addr.arpa are served by servers operated by ARIN and its contractors" Seems incorrect to me, I think the other RIR's might be surprised to find they are contractors to ARIN. I guess you might regard those bit's of the space that are shared between the RIR's as kind of contracted out in some way but it still seems like a bizarre way of describing it to me. It does seem strange that in-addr.arpa is delegated to the root servers but ip6.arpa is delegated to ICANN but I suspect there is some history and/or a story here :) Brett From jim at rfc1035.com Fri Feb 12 01:03:10 2010 From: jim at rfc1035.com (Jim Reid) Date: Fri, 12 Feb 2010 00:03:10 +0000 Subject: [dns-wg] ARIN and in-addr.arpa In-Reply-To: <5c494b511002111427geaa7cc7u9f88079c9627502d@mail.gmail.com> References: <4B695AA9.7030904@CC.UniVie.ac.at> <20100203114032.GB6588@vacation.karoshi.com.> <4B696BE8.2020106@CC.UniVie.ac.at> <5c494b511002111427geaa7cc7u9f88079c9627502d@mail.gmail.com> Message-ID: On 11 Feb 2010, at 22:27, B C wrote: > "Today, delegations under in-addr.arpa are served by servers operated > by ARIN and its contractors" > > Seems incorrect to me, I think the other RIR's might be surprised to > find they are contractors to ARIN. Brett, IMO it would have been better if ARIN had used the word "partners" instead of "contractors". I'm fairly sure that's what ARIN meant even if it wasn't what they said in the statement you quoted. ARIN will know that the other RIRs are not contractors to ARIN when it comes to reverse DNS space. As do the other RIRs. Who will presumably be happy to remind their cousins at ARIN of that fact. The situation with DNS service for in-addr.arpa doesn't lend itself to soundbites. So I wouldn't worry too much about soundbites on a web page which by definition won't tell the whole story in painstaking detail. As I'm sure you know, some parts of the tree are managed by the other RIRs (who then have mutual arrangements for DNS service for "their" domains). [As an example, 195.in-addr.arpa is managed by the NCC and the zone's NSRRset includes name servers operated by APNIC and ARIN.] Other parts are handled by ARIN's name servers and its contractors (Neustar/Ultra IIRC). Then there's the AS112 project for RFC1918 space. And the unallocated or reserved space, etc, etc. Now someone could explain all of this in fine detail. But would it help or hinder understanding of whar ARIN's doing wrt DNSSEC? From brettlists at gmail.com Fri Feb 12 17:09:33 2010 From: brettlists at gmail.com (Brett Carr) Date: Fri, 12 Feb 2010 16:09:33 +0000 Subject: [dns-wg] Re: ARIN and in-addr.arpa In-Reply-To: References: <4B695AA9.7030904@CC.UniVie.ac.at> <20100203114032.GB6588@vacation.karoshi.com.> <4B696BE8.2020106@CC.UniVie.ac.at> <5c494b511002111427geaa7cc7u9f88079c9627502d@mail.gmail.com> Message-ID: <5c494b511002120809k7c908874n71af42fc306d1e4f@mail.gmail.com> On Fri, Feb 12, 2010 at 12:03 AM, Jim Reid wrote: > On 11 Feb 2010, at 22:27, B C wrote: > >> "Today, delegations under in-addr.arpa are served by servers operated >> by ARIN and its contractors" >> >> Seems incorrect to me, I think the other RIR's might be surprised to >> find they are contractors to ARIN. > > Brett, IMO it would have been better if ARIN had used the word "partners" > instead of "contractors". I'm fairly sure that's what ARIN meant even if it > wasn't what they said in the statement you quoted. ARIN will know that the > other RIRs are not contractors to ARIN when it comes to reverse DNS space. > As do the other RIRs. Who will presumably be happy to remind their cousins > at ARIN of that fact. Indeed of course I am aware of this already just thought it was worth replying to Wilfreds e-mail for the benefit of other people on the list who may be confused and/or interested. > > The situation with DNS service for in-addr.arpa doesn't lend itself to > soundbites. So I wouldn't worry too much about soundbites on a web page > which by definition won't tell the whole story in painstaking detail. As I'm > sure you know, some parts of the tree are managed by the other RIRs (who > then have mutual arrangements for DNS service for "their" domains). [As an > example, 195.in-addr.arpa is managed by the NCC and the zone's NSRRset > includes name servers operated by APNIC and ARIN.] Other parts are handled > by ARIN's name servers and its contractors (Neustar/Ultra IIRC). Then > there's the AS112 project for RFC1918 space. And the unallocated or reserved > space, etc, etc. > > Now someone could explain all of this in fine detail. But would it help or > hinder understanding of whar ARIN's doing wrt DNSSEC? Well no not directly but being accurate and explaining some of this in detail (in the correct place) could help people who are new to this wg or the industry in general understand what is going on, that was my point I guess, maybe I didn't get it across well enough but hey that's e-mail for you :) Brett From andrei at ripe.net Thu Feb 18 16:52:12 2010 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 18 Feb 2010 16:52:12 +0100 Subject: [dns-wg] DNSSEC Signer Replacement Project Message-ID: <4B7D622C.5090304@ripe.net> Dear Colleagues, As noted during RIPE 59, the RIPE NCC is upgrading the current DNSSEC provisioning infrastructure. This project includes the replacement of current software signers with a more secure hardware solution. During this migration, an exception will be made to the double signing policy outlined in our key maintenance procedure, which is available at: https://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html In order to reduce the likelihood of validation errors as much as possible during the migration, a one-time exception will be made to the policy of double signing our Key Signing Keys (KSKs). This is because it is not possible to exchange keys between our old and new signers. To prevent signing all our zones on two signers and then merging the results, we will pre-publish the new KSK in March 2010 as a one-time exception. The DNSSEC signer migration will involve the steps detailed below. The dates align with our standard key rollover timings, as detailed on our website at: https://www.ripe.net/projects/disi//keys/ On Tuesday, 2 March 2010, our signer will switch to the currently pre-published Zone Signing Key (ZSK). This ZSK will not be rolled over again until Monday, 14 June 2010. No new trust anchors need to be configured for resolvers at this point. On Tuesday, 23 March 2010, we will pre-publish a new KSK and ZSK in our zones. The new KSK will be available in our trust anchor repository, also available at: https://www.ripe.net/projects/disi//keys/ One KSK will be in use, but both KSKs must be configured as trust anchors in DNSSEC validating resolvers. On Monday, 14 June 2010, the old KSK and ZSK will be deprecated. Only the new keys will be able to validate. One KSK will be in use. On Tuesday, 21 September 2010, we will publish a new KSK on our website and continue with our usual double signing policy. Two keys will then be in use. Given that the parent zones of the RIPE NCC's zones are likely to be signed in the near future, we will continue to follow the current key maintenance procedure and lifetimes after the migration in completed. This will allow us to make a more informed decision on the RIPE NCC's key lifetimes when the policies for our parent zones are known. Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC From subs at arahmantech.com Thu Feb 25 11:58:41 2010 From: subs at arahmantech.com (Athiqur Rahman) Date: Thu, 25 Feb 2010 10:58:41 +0000 Subject: [dns-wg] specify dns for reverse lookup Message-ID: <4B8657E1.7050304@arahmantech.com> I have the 217.73.64.0/20 IP block assigned to me. I am trying to setup some reverse DNS records. I created the zone 64.73.217.in-addr.arpa which is answering queries fine. However when I create any other zone files withing that /20, they do not answer the queries. I have logged into the RIPE website and am trying to find where the DNS is specified for an IP range but can not seem to find it. Any advice on how to proceed with this problem? From anandb at ripe.net Thu Feb 25 12:20:07 2010 From: anandb at ripe.net (Anand Buddhdev) Date: Thu, 25 Feb 2010 12:20:07 +0100 Subject: [dns-wg] Re: specify dns for reverse lookup In-Reply-To: <4B8657E1.7050304@arahmantech.com> References: <4B8657E1.7050304@arahmantech.com> Message-ID: <4B865CE7.3030904@ripe.net> On 25/02/2010 11:58, Athiqur Rahman wrote: Hello Athiqur, > I have the 217.73.64.0/20 IP block assigned to me. I am trying to setup > some reverse DNS records. > > I created the zone 64.73.217.in-addr.arpa which is answering queries > fine. However when I create any other zone files withing that /20, they > do not answer the queries. > I have logged into the RIPE website and am trying to find where the DNS > is specified for an IP range but can not seem to find it. > > Any advice on how to proceed with this problem? You have to create a zone for each /24 block of address space within your /20 allocation. So you'll need to set up zones like 64.73.217.in-addr.arpa, 65.73.217.in-addr.arpa and so on until 79.73.217.in-addr.arpa. After that, you'll need to create domain objects in the RIPE Database to get delegation for these zones to your name servers. Please see the reverse DNS howto on the RIPE NCC website at: http://www.ripe.net/rs/reverse/reverse_howto.html Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC