At 10:17 +0100 12/29/04, Olaf M. Kolkman wrote:
Concluding: the only argument for having the DNSKEY at the parent is to store it in the WHOIS together with the DS in order to allow for out of band troubleshooting. Is that important enough to allow for the DNSKEY to travel over EPP?
I'd still say no.
As registries grow to over 1 million objects and the number of different implementations of DNS grow, troubleshooting like this will disappear. If the registrant hands in a DS to a registrar, who then passes it opaquely to the registrar - what's to troubleshoot? If what went in = what is there, the problem is then all on the registrant's side. If there is processing in the registrar or registry - then there is something to troubleshoot.
I like the philosophy that neither half of the public/private key gets to the registry. It keeps a very federated, decentralized feel to the security model. I'm not sure that this is quantifiable though. Let the registry collect only what it must - after all, it's going to be a large collection already.
Keep in mind that if the DNSKEY were to be totally removed from EPP, there is still DNS to move the key from child to parent - barring bad firewall configurations, nasty NAT's, etc.
DNSKEY as an attribute of the DS element is a fine method to acomplish this as there is even a more direct link between the DNSKEY and the DS record.
I think it is appropriate to keep it that way - because the *only* reason to leave DNSKEY in EEP at all is to counter layering violations in other protocols and devices. (Speaking of the problems of firewalls, NAT's, etc.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
