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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop