Op donderdag 14-10-2010 om 09:42 uur [tijdzone +0200], schreef Fredrik Ljunggren: > Antoin, > > Isn't the Zone Maintainer (DNS operator) really just a delegate of the > registrant and not a separate role? The registrants should be in control of > their domain name and responsible for managing the keys.
In the administrative Registry-registrar-registrant contractual model, you're absolutely right > However, many (but certainly not all) may delegate or outsource the function > of operating the DNS server to an external party, and maybe also signing. And the error that is often made is the wrong assumption that the registrar by definition the only technical dns-operator that the function is outsourced to. > It is probably just a matter of how you look at the relations. I think > introducing the DNS operator as a separate entity complicates matters in many > cases. Can you give an example where the DNS operations can not fall within > the registrants responsibility? It's not about giving the DNS-operator a role in the administrative contractual relationship between registry-registrar-reseller-registrant. But if we define a resolver operator (1.3.4. Relying Party) as an entity that is affected by DNSSEC, then we should also state that authoritative DNS operators are affected by DNSSEC, and explain what their role is in the process. > If there are circumstances that require this role to be defined, it is also > perfectly fine to add that as a subcomponent of the registrant while still > being in full compliance with the framework. The dns-operator is needed for a number of registry processes where a change of dns-operator for the authoritative nameservers for a child zone happen. This MAY be (but not necessarily): -domain transfers (changing registrar) -domain hand-overs (changing registrant) -nameserver changes -turning DNSSEC on/off In these cases, we want to describe what the role of registry-registrar-registrant is, and who should do what. In case of describing the responsibilities of the registrant, we want to state that he is responsible for zone maintenance, including key maintenance, even if he outsources that to a 3th party dns-operator. To be able to state what a registrant should do, and how things work, we cannot do without defining what a registrant can outsource to a dns-operator, and what a registrant should be aware of when entering in such a bilateral contract with a dns-operator. What contractual responsibilities he transfers when he does not control the zone himself. > -- Fredrik > > > On 2010-10-13, at 22:47, Antoin Verschuren wrote: > > > Op donderdag 30-09-2010 om 16:39 uur [tijdzone +0100], schreef Stephen > > Morris: > >> > >> The working group adopted the draft last year but since then there has > >> been little discussion of it on the list. With DNSSEC at last looking as > >> if it is really starting to take off, this is a timely document. Please > >> have a look at it and give feedback. > > > > We have used the draft dps framework to write down our DPS when we > > introduced DNSSEC for .nl. > > We are currently rewriting our DPS to include DS/DNSKEY submission into > > our zone, and we encountered a missing comunity in the outline in > > section 5. In our DPS, we are defining a dns-operator as an entity that > > needs to be defined seperately from an administrative > > registry/registrar/registrant definition as sugested in the outline. I > > would strongly suggest to include a technical dns-operator definition in > > the outline, so that section 3 of the outline will be: > > 1.3. Community and Applicability > > 1.3.1. Registry > > 1.3.2. Registrar > > 1.3.3. Registrant > > 1.3.4. Zone maintainer > > 1.3.5. Relying Party > > 1.3.6. Auditor > > 1.3.7. Applicability > > We're still in discussion if we need to separate zone operator (only > > running the DNS server infrastructure) and zone maintainer (who is able to > > change the zone's content), or that we can come up with a definition that > > clearly defines the entity that is controlling the access to the zone, and > > can insert RR's and reload the zone when necessary for DNSSEC maintenance. > > My personal opinion is that we need to define an entity that can > > add/remove/change DNSKEY RR's and can push the button to resign the zone, > > and when he does, can communicate that to the parent zone through > > registrar, registrant, registry or any combination of those. > > > > > > > > -- > > 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.verschu...@sidn.nl xmpp:ant...@jabber.sidn.nl > > http://www.sidn.nl/ > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > -- 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.verschu...@sidn.nl xmpp:ant...@jabber.sidn.nl http://www.sidn.nl/
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
