I have a short time slot to discuss these slides on Thursday, http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads/presentation... but I want to try to get comments from people ahead of time. The presentation is trying first collect requirements, not present a solution to a problem in DNSSEC management. Most of the discussion I have had on this is with a smallish circle of people involved in TLD registry operations which I fear is not inclusive enough. In case you don't want to go through the slides, I'd like to ask these questions: 1. If you are planning to receive DS records for any reason, how do you plan to do it? (You don't have to be a TLD to need to do this.) 2. If you are operating DNS for people and are considering DNSSEC, have you thought about how the DS record will be passed to your customers' zones parents? 3. If you operate a recursive server, where to do plan to get DNSSEC public keys (for example, ISC's DLV)? Although I have just 15 mins to run through the 35-odd slides, I really want to get input from various people while RIPE is in session - or via email. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.
On 5 okt 2009, at 15.52, Edward Lewis wrote:
In case you don't want to go through the slides,
True,...sorry...
I'd like to ask these questions:
1. If you are planning to receive DS records for any reason, how do you plan to do it? (You don't have to be a TLD to need to do this.)
As a registrar, via a home-brew protocol. netstring encoded json structures. Simpler than the epp extensions.
2. If you are operating DNS for people and are considering DNSSEC, have you thought about how the DS record will be passed to your customers' zones parents?
For the TLDs I am a registrar, via epp. For other TLDs, via some protocol to the registrar of the domain.
3. If you operate a recursive server, where to do plan to get DNSSEC public keys (for example, ISC's DLV)?
Not a question for me. paf
On Mon, Oct 05, 2009 at 03:52:06PM +0100, Edward Lewis wrote:
I have a short time slot to discuss these slides on Thursday,
http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads/presentation...
but I want to try to get comments from people ahead of time.
i would have commented earlier, but they were presented in an even more propritary format than PDF. comments forthcoming.
The presentation is trying first collect requirements, not present a solution to a problem in DNSSEC management. Most of the discussion I have had on this is with a smallish circle of people involved in TLD registry operations which I fear is not inclusive enough.
In case you don't want to go through the slides, I'd like to ask these questions:
1. If you are planning to receive DS records for any reason, how do you plan to do it? (You don't have to be a TLD to need to do this.)
SYNC protocol.
2. If you are operating DNS for people and are considering DNSSEC, have you thought about how the DS record will be passed to your customers' zones parents?
yes - using SYNC.
3. If you operate a recursive server, where to do plan to get DNSSEC public keys (for example, ISC's DLV)?
the authoritiatve servers.
Although I have just 15 mins to run through the 35-odd slides, I really want to get input from various people while RIPE is in session - or via email.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.
Subject: [dns-wg] DNSSEC - DS RR provisioning Date: Mon, Oct 05, 2009 at 03:52:06PM +0100 Quoting Edward Lewis (Ed.Lewis@neustar.biz):
In case you don't want to go through the slides, I'd like to ask these questions:
1. If you are planning to receive DS records for any reason, how do you plan to do it? (You don't have to be a TLD to need to do this.)
N/A
2. If you are operating DNS for people and are considering DNSSEC, have you thought about how the DS record will be passed to your customers' zones parents?
Manually. I sign the zones and publish the DS via <method> to customer who is responsible for DS submission. Not good, I agree, but for now will have to do.
3. If you operate a recursive server, where to do plan to get DNSSEC public keys (for example, ISC's DLV)?
I keep up with SE manually and otherwise am waiting for ".". -- Måns Nilsson
-----Original Message----- From: dns-wg-admin@ripe.net [mailto:dns-wg-admin@ripe.net] On Behalf Of Edward Lewis Subject: [dns-wg] DNSSEC - DS RR provisioning
The presentation is trying first collect requirements, not present a solution to a problem in DNSSEC management. Most of the discussion I have had on this is with a smallish circle of people involved in TLD registry operations which I fear is not inclusive enough.
I First have a remark on the assumptions that many have about the registry-registrar-registrant model, that is implemented differently in various TLD's. When the RRR model was introduced in .nl in 1996, it was meant to only solve the administrative hurdles of a registry having to talk to many registrants, which was a practical communication matter. There is a difference in a thin and thick registry here, but the RRR model was never meant to solve the technical relationship between a parent and child that exists by definition. My answers are made with this background.
1. If you are planning to receive DS records for any reason, how do you plan to do it? (You don't have to be a TLD to need to do this.)
As a registry, I would like to receive technical updates to the DNS trough a secure channel, directly from, or in sync with the child zone. Since a secure channel does not exist during bootstrapping, I would accept the bootstrapping through the initial administrative channel (EPP or any other administrative initiation) and I would like the updates to use the fastest possible secure channel without manual intervention. I would like the DNS tree under my TLD to be correct. I would not allow interception of the technical updates due to business rules if that would make the DNS less stable or reliable. I would like to implement an update method that could be universally deployed to facilitate any DNS-operator operator of a child zone to use for as many parents as possible. As a general parent, (DNS-operator), not being a TLD, I would like this syncing to be done the same, with a single standard, preferably in the DNS protocol, and not over any EPP or extra external protocol I might not be using. So I would like the update to use the DNS protocol, and I would accept updates directly from the child zone if it has a secure delegation. I would accept DS, NS and glue updates.
2. If you are operating DNS for people and are considering DNSSEC, have you thought about how the DS record will be passed to your customers' zones parents?
As a registrant and DNS-operator, I would like to send updates of my zone directly to the parent without manual intervention. Configuring where to send my updates for a given zone during zone creation will be less work for me than to manually send every update through a RRR interface. As a pure registrar, not being a DNS-operator, I couldn't be bothered less about technical updates. They don't bring in money, don't require communication, but I'm obliged to do work. The only reason for a registar to intercept and pass through technical updates is to be able to control business rules: "If you don't pay, I won't relay your update." Since this is often prohibited by registration rules anyway, I don't see this as a valid reason for interception.
3. If you operate a recursive server, where to do plan to get DNSSEC public keys (for example, ISC's DLV)?
"." Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/
On 6 okt 2009, at 12.30, Antoin Verschuren wrote:
So I would like the update to use the DNS protocol, and I would accept updates directly from the child zone if it has a secure delegation. I would accept DS, NS and glue updates.
Can you expand on this? Using SIG(0) where the public key is signed and in the child zone (for example)? paf
-----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Subject: Re: [dns-wg] DNSSEC - DS RR provisioning
* PGP Signed by an unknown key
On 6 okt 2009, at 12.30, Antoin Verschuren wrote:
So I would like the update to use the DNS protocol, and I would accept updates directly from the child zone if it has a secure delegation. I would accept DS, NS and glue updates.
Can you expand on this? Using SIG(0) where the public key is signed and in the child zone (for example)?
When there is an existing chain of trust between the parent and child zone, that chain can be used to authenticate changes in the child zone to the parent. So the child signals the parent to query the child zone for changes to the DNSKEY, NS or glue records. Since these records are signed, and the parent can trust the signed content in the child zone, it can update the parent zone with any record that needs to be in there. Syncing the content in the child zone with the content in the parent zone. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/
On 6 okt 2009, at 14.54, Antoin Verschuren wrote:
So the child signals the parent to query...
Any thinking on how that should be done technically? I.e. I like your idea. I just want to know all details :-) Patrik
In case you don't want to go through the slides, I'd like to ask these questions:
1. If you are planning to receive DS records for any reason, how do you plan to do it? (You don't have to be a TLD to need to do this.) SIG(0) authenticated DNS updates
2. If you are operating DNS for people and are considering DNSSEC, have you thought about how the DS record will be passed to your customers' zones parents? I would like to use the same method as above. The initial public key exchange should be done via EPP/RRI or web frontend.
3. If you operate a recursive server, where to do plan to get DNSSEC public keys (for example, ISC's DLV)? The manually configured root key where key rollover is handled via RFC5011.
+--On 5 octobre 2009 15:52:06 +0100 Edward Lewis <Ed.Lewis@neustar.biz> wrote: | In case you don't want to go through the slides, I'd like to ask these | questions: | | 1. If you are planning to receive DS records for any reason, how do you | plan to do it? (You don't have to be a TLD to need to do this.) As a registry, through EPP or other home brewed registry/registrar interface. As a standard parent, through a home brewed web interface. | 2. If you are operating DNS for people and are considering DNSSEC, have | you thought about how the DS record will be passed to your customers' | zones parents? about the same as above. | 3. If you operate a recursive server, where to do plan to get DNSSEC | public keys (for example, ISC's DLV)? Well, obviously, there are two cases here : 1) the root is signed, that's the only key I'll ever need (sight), and I'll get it through the proper channels that will be put up at that time. 2) the root is not, DLV is a very nice thing. -- Mathieu Arnold
On Fri, 13 Nov 2009, Mathieu Arnold wrote:
| 3. If you operate a recursive server, where to do plan to get DNSSEC | public keys (for example, ISC's DLV)?
Well, obviously, there are two cases here : 1) the root is signed, that's the only key I'll ever need (sight), and I'll get it through the proper channels that will be put up at that time.
Only if you're willing to wait 2 years on .com to get signed. DLV is still useful after the root is signed and before .com is signed. The same applies for other unsigned TLD's, but most people will ignore those. Paul
On Fri, Nov 13, 2009 at 05:57:36PM -0500, Paul Wouters <paul@xelerance.com> wrote a message of 15 lines which said:
Only if you're willing to wait 2 years on .com to get signed.
If you have a ".com", you will need to wait for ".com" to be signed + for ".com" to accept DS records (for most TLD which were signed, there was a non-trivial delay here) + for your registrar to accept and relay DS records (the experience with AAAA glue records makes me pessimistic here). So, yes, saying we won't need DLV after the root is signed is short-sighted.
+--On 14 novembre 2009 10:52:00 +0900 Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote: | On Fri, Nov 13, 2009 at 05:57:36PM -0500, | Paul Wouters <paul@xelerance.com> wrote | a message of 15 lines which said: | |> Only if you're willing to wait 2 years on .com to get signed. | | If you have a ".com", you will need to wait for ".com" to be signed + | for ".com" to accept DS records (for most TLD which were signed, there | was a non-trivial delay here) + for your registrar to accept and relay | DS records (the experience with AAAA glue records makes me pessimistic | here). | | So, yes, saying we won't need DLV after the root is signed is | short-sighted. Ok, I should have been more specific, I meant when the root is signed and I can verify the signatures all the way down. Of course DLV will be very useful in the years to come. -- Mathieu Arnold who's just had to remove DNSSEC from a few zones because of qmail.
From: dns-wg-admin@ripe.net [mailto:dns-wg-admin@ripe.net] On Behalf Of Edward Lewis Sent: den 5 oktober 2009 16:52
1. If you are planning to receive DS records for any reason, how do you plan to do it? (You don't have to be a TLD to need to do this.)
N/A
2. If you are operating DNS for people and are considering DNSSEC, have you thought about how the DS record will be passed to your customers' zones parents?
Yes, but no solution execept for the domains we are registrar for.
3. If you operate a recursive server, where to do plan to get DNSSEC public keys (for example, ISC's DLV)?
Currently, .SE key only. When DNSsec is in production for the root and .SE has DS records in the root zone, the root key only. Mats ------------------------------------------ Mats Dufberg TeliaSonera BBS P&P AP SP Internet +46-70-2582588 mats.dufberg@teliasonera.com ------------------------------------------
participants (10)
-
Antoin Verschuren -
bmanning＠vacation.karoshi.com -
Edward Lewis -
Holger Zuleger -
Mans Nilsson -
Mathieu Arnold -
Mats.Dufberg＠teliasonera.com -
Patrik Fältström -
Paul Wouters -
Stephane Bortzmeyer