[dns-operations] .TH signed
michael_graff at isc.org
Wed Apr 8 19:04:02 UTC 2009
Edward Lewis wrote:
> When Scott Hollenbeck put together RFC 4310, I did some testing to
> support it. We discussed the issue of "submit a key or submit a DS." We
> sided on submitting a DS as the right way to go because (and this is the
> point), a registry ought to be explicitly be told to "associate/register
> this resource (attributes) with this identity." (DNSKEY is also in RFC
> 4310 to achieve wider consensus.) We came to this informal,
> undocumented "theorem:"
When I submit name servers for my domains, I submit money (heh) and name
server hosts, and IP addresses. I never submit "NS records" nor "A
records." I don't know or care about the method these are published,
nor their format.
I don't see why one could not accept DNSKEYs directly, rather than a DS.
After all, I don't submit a representation of the name servers, I
submit their names. Why not submit the key record, and how it is
published is up to the publisher? I know it is too late for 4310.
DLV used to require the user to enter DLV records, or email them in back
when we did it manually. I deemed this an error-prone and unnecessary
step -- I can compute the DLV records we publish from the key -- and
users should not have to care about converting from what they want
(their DNSKEY to be used) to an arbitrary format (DLV, DS, etc).
> A registry shouldn't be trying to infer something, anything, about
> registrants. A registry should take what a registrant (or the agent
> of/registrar) explicitly says to register and record the association -
> modulo authentication, authorization, etc.
See above. The binding between what the user submits and what is
published does not have to be 1:1, IMHO. It already is not, in fact.
Plus, having the key submitted allows one to publish DS or DLV records
with any type of hash desired -- SHA1, SHA256, whatever. It decouples
the data the user sees from the data the publisher generates, which
decouples the user from the technology used to bind the parent/child
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 257 bytes
Desc: OpenPGP digital signature
More information about the dns-operations