[dns-wg] DNSSEC - DS RR provisioning
- Previous message (by thread): [dns-wg] DNSSEC - DS RR provisioning
- Next message (by thread): [dns-wg] DNSSEC - DS RR provisioning
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Antoin Verschuren
Antoin.Verschuren at sidn.nl
Tue Oct 6 13:30:14 CEST 2009
> -----Original Message----- > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at 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 at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/
- Previous message (by thread): [dns-wg] DNSSEC - DS RR provisioning
- Next message (by thread): [dns-wg] DNSSEC - DS RR provisioning
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]