The suggestion is to define a DNSKEY as an attribute of the DS element.
The goals of this are to:
1) Allow access to keys where they might not otherwise be, meaning: In some situations name servers for delegated zones are not reachable by the parent zone's networks. (Yes, I know that this ought never happen, but it's an operational reality. I have found many of these when studying lame delegations.)
2) Encourage deployments to use the DS as the main mode of transfer. Meaning: imagine one registry asking for keys of its registrars and another registry asking for DS's of its registrars. The operational nightmare would be if the two sets were distinct for some time and then the two communities merged.
3) Removes the need to define a second element (DNSKEY) in the protocol, removes the RRSIG completely from the discussion. By doing this, getting the document produced (to RFC as a Proposed Standard) will be a shorter effort.
Comments?
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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
