ietf-mxcomp
[Top] [All Lists]

Re: Potential Work Item: New DNS resource records

2004-03-10 20:05:28

[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