[dns-operations] .TH signed

Michael Graff 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...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20090408/2abd9f70/attachment.sig>

More information about the dns-operations mailing list