Thw following assumes that you have read previous two RFCs I pointed or
understood enough from quoted text. I propose that NAPTR record be used
for MARID lookups in this form:
The key for lookup of the NAPTR is "extended" email address of the form
marid://email(_at_)host(_dot_)domain(_dot_)com/service
Where
1. marid is new proposed URN type
2. email(_at_)host(_dot_)domain(_dot_)com is full email address that we're
trying to validate
3. "/service" are optional parameter specifying what kind of marid record
this is
This key is used when looking up NAPTR record for host.domain.com. Since
NAPTR is standard DNS type, the wildcards are possibly just like with
MX, so you can enter just one set of "NAPTR" records and the actual
location to lookup the data is extracted by using NAPTR regular express
substitution with full email address and full host name used. Using
regular expressions will also make it possible to setup per-user records
but without doing in a way that exposes email address. The result of
regular expression substitution the NAPTR records will provide back
dns name that can validate use of the email address or host name. This
pointer can be to domain location with "TXT" record with spfid record
entered in its own _marid.domain.com location. It can also be singular
pointer to dns name containing valid ip address entered in A record
(NAPTR protocol key "A") or to extended list of ip addresses (see RFC
3123 and APL record type, NAPTR will have to be extended with new
protocol key to support this).
The "/service" can be used to extend MARID lookups to different types of
email data, for example checking on valid EHLO host name might be done by
looking up "marid://helloname.domain.com/ehlo".
Let me know what you think and if its workable. Also would be interesting
to know how may dns servers and clients actually support NAPTR right now
or will be able to quickly add support for it if necessary.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net