-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16-07-12 22:37, Patrik Fältström wrote:
Just back from holidays, some aditions: > JUST talk about things like: > > 1. we have registry, registrar, registrant and DNS operator" In the DNSSEC transfer issues we discussed, we did enter a reseller, so the administrative chain that is general enough for any current relationship is: Registry-Registrar-Reseller-Registrant-DNS_operator. Where there may be 0-1 Registrars and 0-multiple resellers in the administrative chain. The more general mistake is that one entity can play multiple roles. So one entity may act as both Registrar and DNS_operator for a certain delegation where in another delegation one entity may be both registrant and DNS_operator. So they are roles, not players. This is often not understood in discussions. (you may even have entities that combine registrar and multiple reseller roles). > 2. any of those might give the right to a third party to act on > their behalf > > 3. we only know there are direct connections and knowledge between > registry-registrar, registrar-registrant and registrant-dns > operator The issue for the administrative chain is the question as to who offers the authoritative data. For a Registry, the registry database IS the authoritative data, which is fed into the DNS parent zone. So from the point of view of the parent zone, it only accepts changes from the Registry database and not from another source. Or to put it in pictures: Registrant/Reseller/Registrar => Registry database => DNS Parent zone If we only look technically at the DNS, what we're trying to do here is: Parent zone <=> Child zone To keep them both in sync. But this leads to problems in the administrative chain: Registrant/Reseller/Registrar => Registry database <=> DNS parent zone Which data is authoritative for the Registry database, The registrar's input, or the DNS input ? Registrars claim they are always right, we DNS people claim DNS is always right. We need the registrar's input for bootstrapping the delegation at least. The question is who is authoritative for the delegation after that. DNS or the registrar's input. > What we MUST have is: > > - Enough data in the registry so that DS can be created that refer > to key material used to sign the zone published by the dns > operator > > Today we know that we have cases like: > > A. The DS is passed to the registry > > B. The DNSKEY is passed to the registry that create the DS > > C. The DNSKEY is fetched from the zone of the DNS operator and the > DS is created > > We have the following plus and minuses: > > bla bla bla > > Patrik > > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQDqwxAAoJEDqHrM883AgnMw4H/Rzwxyomgr5AjzvQ8iLAYCgW mDHCP99T6IX2N2qzTjxb3yCxuSenFYSjXEIjY+qCWj02ilVpDkaaj1OYoeA3QNax aVckUbkDGXkIvT3Y9BNrMeNTRLovBZ8Tkt6YlkUM2QHCirvkkCnZ0FCRFxQZlXWj V5jWkHtr7M+m5f965JutGSs+2P4JcqijAJAMXy+SNVpNJhwt2RxTARvzFLIeAZ0S jH9/PAzyAcIF6gV5sTaIwz404VfY23dEJZ8GL5arQ3JEfGOBIQsRv2eaCwX29kaD ziirytFdy/p4S0WQeF/K/4z4TFI9XQg3FiRJBBnIk34SD5cHu/JERQRpkOALgck= =fmXB -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
