In message <4b916ab6.6060...@dougbarton.us>, Doug Barton writes: > On 3/4/2010 11:03 PM, Alex Bligh wrote: > > Sure. And I don't want to expand a one-liner into more than it is > > worth, nor start a discussion on the merits of various registry > > models. All I was saying was that in a thin model, as the registry > > has no direct contact with registrants, and as the canonical source > > of zone data is in essence the registrar (that's who the registrant > > gives his NS and DS records to), the DS (and, for that matter the NS) > > records have more change to "get lost" when moving between registrars > > than in a thick registry. > > I don't want to belabor the point either, the problem (and I apologize > if I haven't been clear) is that just about everything you wrote in that > paragraph is wrong, and I think it's really important that the members > of the WG have the correct information so that they can make informed > choices about proposals in this area. > > 1. The canonical source of information about NS records is ALWAYS the > registry. Whether the data passes through a registrar on its way from > the registrant to the registry or not. (Whether or not the registrar is > the canonical source of information about the registrant is a can of > worms I don't want to open here.) > > 2. Thick vs. thin is simply a description of where the data is stored > (and in an ancillary way how whois lookups work), it has no predictive > value for whether or not the registrant has a direct relationship with > the registry or not. There are thick registries who use registrars in > both the g and cc TLD worlds. > > > As you point out that means that ICANN involvement may be > > necessary/desirable to fix that, and all I was saying was there may > > be less need for such involvement in a thick registry model. > > If you substitute "registry that communicates directly with registrants" > for "think registry model" (which is what I think you actually mean) > than I agree with you. However, those registries are very much in the > minority. > > I'm sorry to be so pedantic on this, but I think it's crucial that we > get the terminology right. The issue of how to correctly pass DS records > when a secure domain is transferred between registrars is really > important, and we are going to need to interface with both the RRR folks > and ICANN on this in order to figure out a model that will work. If we > go into that process without speaking the language it's not only going > to make us look foolish, but more importantly it's going to start us off > a few squares back before we even get started.
As long as they both support DS it should be a non-issue. Changing registrars, by itself, does NOT change DNS data. If the registrar is doing DNS hosting then one has to transition from one DNS host to the next DNS host. The simplest way that I can see and maintain the secure status of the zone is to have the loosing DNS host enter DNSKEYs the gaining DNS host supplies into their zone and have DS records published for them. Once the old DS and DNSKEY RRsets have flush from caches the loosing DNS host slaves the new zone content and the NS RRset is updated in the parent and the old DS records are remove from the parent. Once the old NS RRsets have flushed from caches the loosing DNS host removes the zone from their servers. Remove all the DNSSEC from the above and you have how plain DNS zones should be transfers from one DNS host to another. Unfortunately this doesn't happen as often as it should. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
