Hi Alex On 3/03/2010, at 8:46 PM, Alex Bligh wrote:
>> I'm sure we could and an automated update of DS records is a good idea. >> But my point is that in the absence of a similar automated mechanism for >> NS records we use cut and paste and it works fine and there is nothing >> about DS records that is any more complicated so cut and paste would work >> fine there too. > > I thought that yesterday. Ed convinced me otherwise. I think I have > about 20 or 30 domains registered (meaning I look after the registrar > interaction and the DNS for them) with variety of registrars. I don't > think the NS entries for any of them have changed in the past ten > years, and they are all either pair {a,b} or pair {c,d}. If they > had DS records, this would not apply. Ed gave two reasons - one was timing and the other was difficulty. I agreed with timing, which is the implicit issue in your para above, but not with difficulty. Timing is a sufficient reason alone for this work but I would suggest that difficulty is a red-herring. > Moreover, I suspect for the vast majority of zones, some third party > DNS service is going to be signing the zones and producing the DS > records. Unless there is an automated mechanism to move DNS, we > going to make it difficult for any third part authoritative DNS > service to exist unless they are also the registry operator. In your example above I personally would only use one set of keys for all those domains, it would make my life so much easier. I suspect some DNS providers will similarly share keys across their customers (or per server) if they know they can control generation of RRs. > To be clear though, I agree entirely with an automated mechanism to move DS records, I just would not want "difficulty of cut and paste" to appear as a justification when it is both spurious and unnecessary. Timing issues are more than sufficient justification. cheers Jay > > My non-bar-based straw-man contribution is this (perhaps using a proper > record rather than TXT) > _DSKEY IN TXT "[DSKEY]:[HASH]" > where [HASH] is a truncated hash of the DS key and a secret shared > (once) between registrar/y and the registrant/DNS operator. Obviously > the record needs to then pass the normal signing checks too. If it > doesn't check out, the previous DS key stays. > > -- > Alex Bligh -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop