On 24 jul 2012, at 16:07, Antoin Verschuren wrote: > 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.
My point is that you complicate things by including reseller. A reseller can be viewed as the down-facing portion of the registrar. The problem is not there, The problem is the gap between the others (see below). > The more general mistake is that one entity can play multiple roles. Yes. And too many do believe the registrar do run DNS, in the form of saying "registrar" when they mean "DNS operator". > 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. Agree, but that is a different issue from what I am talking about. I am talking about the problem that you have one path like this: dns operator - registrant registrant - registrar registrar - registry ...as the three connections we know we have to create a chain between dns operator and registry. Then you have the potential difference between what the dns operator have and what is in the zone that the registry produces from the content of their database. Now, if you create a mechanism where the parent zone is produced by data fetched from a merge between what is in the registry database and in the child zone, then you still must recognize that the only data you have to bridge that gap are the three connections I list above. And btw, this is not something new for DNSSEC, as we have same issue with NS record or glue in the cases that is needed. > 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. Correct as a goal. > 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 ? I do not see that as a problem, although I agree that is one. What is the problem is for the registry (or mechanism that produces the parent zone) to know what is the correct DNS child. > 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 I am talking about is how the registry knows that the child DNS is really the child DNS. If you do, then of course you can as parent "just" fetch the data from there. Patrik > > 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/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
