Re: Example of stupid inconsistencies between registries
"Gould, James" <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <CB7A3A2D.197B3%[email protected]> |
Klaus, Yes, the gaining registrar could delete and reset the DS or Key Data after the transfer, but if the interface was consistent for the registry no update would be required of the DNSSEC data after transfer. Supporting a mix of server-generated DS with the Key Data Interface as well as client specified DS with the DS Data Interface across domain names or within domain names of a single registry will add undue complexity for the client and the server. I believe if there is support for "thin" (DS Data Interface) and "fat" (Key Data Interface) DNSSEC models in the protocol that a server should choose just one model / interface. Requiring the "thin" model in the protocol would result in registries that want to support the "fat" DNSSEC model to create custom extensions that would not be beneficial to anyone. -- JG James Gould Principal Software Engineer [email protected] 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/5/12 9:29 AM, "Klaus Malorny" <[email protected]> wrote: >On 05/03/12 14:49, Gould, James wrote: >> Michael, >> >> I'm not voting but simply covering how the two interfaces made it into >>the RFC. >> I can see the basis for both interfaces, but I certainty don't believe >>that a >> mix in a single registry is workable. >> > >Why? The only problematic situation is the transfer of a domain. But the >DNSSEC >related data is not deleted during the transfer, so it stays as long as >the new >registrar desires. And if the registrar wants to update the DNSSEC data, >he can >specify to delete all previous data (be it DS or DNSKEY) and replace it >with his >preferable representation. > >Generally, I think the topic is overestimated -- I think it is more >critical >that the various registries allow different sets of algorithms for the >DNSKEY >and I cannot choose the same algorithm for all my domains. > >Klaus > > > > _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg