[I am not writing this as chair of the BOF or anything, but as an
individual]
On 2004-03-11, at 10.37, Gordon Fecyk wrote:
The DNS folks made it clear that (ab)using existing record types would
be
unacceptable. So whatever data we want stored in the DNS cannot use
existing
record types and, ideally, not be stored in hard-defined name spaces
like
_vsf or _smtp-client or whatever. Wildcards were also generally a Bad
Idea[tm].
Yes, I think this should be a work item, and we should let DNS people
do the work. I am probably "almost" one such person, and have initial
comments below.
When sending a query for a DNS record, you send a triple consisting of
(Owner, Type, Class). One of the reasons for not using for example TXT
record is that the client when issuing a query can not select only the
TXT records for the given domain name used for this application without
also getting other TXT records.
I.e. one of the three items in the triple must be unique.
Four alternatives:
[1] Change the class
Bad idea. Changing of class imply creating a new root in the DNS tree.
I will not go into the details here.
[2] Add a suffix to the owner (i.e. for example.com, query for
example.com.service.)
Also very bad idea. Also creates a new root in the DNS tree.
[3] Add a prefix to the owner (i.e. _foo.example.com.)
Problematic for two reasons:
If we have
example.com. IN MX 10 mail.example.com.
it is for me much better to have the same owner for the "RMX" resource
record as the MX because then we know for sure both MX and the "RMX" is
in the same zone, and have to be signed by the same owner/mechanism.
Second problem has to do with wildcards.
If one have
*.example.com. IN MX 10 mail.example.com.
then one can have still
*.example.com. IN RMX ...
But, if one use _foo.example.com for the mechanism, we can not have:
_foo.*.example.com.
[4] Change the resource record type
See previous bullet, it forces the MX and the "RMX" to be in the same
zone, which in turn forces the records to be managed by the same
entity.
This for me personally make things much more stable and "correct" and
also partially answers the question Ted had about DNSSEC.
paf