ietf-mxcomp
[Top] [All Lists]

Thought on DNS record types.

2004-05-27 18:27:58


I wanted to share a couple of thought on the sorts of records that
could be stored in the DNS for MARID.
As I understand it, there are three approaches that have been
discussed.

1/ New record type.  This is (arguably) the best from an aesthetic
       perspective, but has practical problems for many sites.
2/ TXT record in the domain (used by SPF).  This is (arguably) the 
       simplest but collides badly with other uses of TXT.
3/ TXT record in a well known subdomain, such as _ep.$DOMAIN used
       by MS-Caller-ID.  This removes the collision problem of 2,
       but, it is said, does not work for wild card domains.

My comments are:

 1/ _ep.$DOMAIN  can still work quite well for wild carded $DOMAIN.
    If I have
        *.example.com IN MX mya.mydomain.org
    then I can also have
        *.example.com IN TXT "MARID: ........."

    and when checking mail from "eg.example.com", if a server looks
    for a TXT in "_ep.eg.example.com", they will find the correct TXT
    record.

    There will only still be a problem for zones with both wildcards
    and multiple uses for TXT records.  Is this likely to be a big
    enough set to cause a problem?


2/ I would like to suggest a 4th approach.  Using MX records.
   Suppose we registered a domain like "marid.arpa" or "spf.int" or
   whatever was appropriate and declared that a record like:

        example.com IN MX 9999 {sometext}.marid.arpa.

   Should have a special meaning to MARID checking software.
   (note that marid.arpa could never have A or CNAME records, so
    the record will be ignored by normally processing)
   Some possible examples for {sometext} could be:

    r27
       Use the 27th standard MARID record.  The SPF experience seems
       to suggest that a very large majority of MARID records will be
       taken from a very small, predictable set.  Listing these in a
       standard and referencing them by number makes for very short
       records.
    ip24.mx24.ptr
       This might be equivalent to the default SPF guess. There is a lot
       of SPF that couldn't be conveniently encoded this way, but
       there is equally a lot that could.
    MARID
       This would indicate that the full record is stored in the new MARID
       record for the domain
    TXT 
       A TXT lookup should be done on the domain to get a textual
       MARID record.
    _ep
       a TXT lookup should be on the _ep subdomain of the domain
       to find a textual MARID record.

    One advantage of this approach is that if you do an MX lookup on
    the domain of any incoming mail (as many servers to), you get this
    record for free, and it may will provide complete information.
    Another advantage is that while there are (apparently) a lot of
    web based domain management systems that don't let you set TXT
    records, they are much more likely to let you set MX records.

    I confess that this is a bit of a kludge, but it could well be a
    very practical one.

2a/ Following a similar line of thought it may be reasonable to 
    have a special interpretation for records like:

     128-191.241.94.129.in-addr.arpa. IN NS compliant.marid.int

    When you get an SMTP connection from an IP address, you do a
    PTR lookup in the IP address.  If the authority section contains
    an NS record like the above, that can be taken as a statement that
    all IP addresses in that range are known to be MARID
    compliant.  If you then get mail that does not appear to be
    compliant (for some suitable definition of compliance), you are
    free to drop it.
    This could provide functionality similar to MTAMark.


NeilBrown


<Prev in Thread] Current Thread [Next in Thread>