ietf-mxcomp
[Top] [All Lists]

Re: I-D ACTION:draft-ietf-marid-core-02.txt

2004-07-26 18:24:55

On Thu, 2004-07-22 at 08:23, Mark Lentczner wrote:
On Jul 22, 2004, at 6:17 AM, Douglas Otis wrote:

It would appear information was removed regarding the maximal number of
DNS queries allowed and the time limit for these queries.  Is there an
expectation these limits are to be individual choices?

This information was moved to the draft-ietf-marid-protocol-00.txt, 
which is the draft that deals with making DNS queries.  Furthermore, 
the limits have been reduced from prior drafts we had written.

The following are draft references marked with -------.  Notes are
indicated with -*-*-

-------
Core version 01 definition of processing limits:

9.5 MTA Implementers

   MTAs that are acting as SMTP servers SHOULD implement the checks
   described in this document.

   An MTA SHOULD limit the number of DNS lookups (or the time spent
   performing the lookup) that it will perform in the process of
   checking a message. Such a limit SHOULD permit at least 20 DNS
   lookups.


-------
Protocol version 00 processing limits:

6.2 Processing Limits

   During processing, an check_host() may require additional evaluations
   of check_host() due to the Include mechanism and/or the Redirect
   modifier.

   Implementations must be prepared to handle records that are set up
   incorrectly or maliciously.  Implementations MUST perform loop
   detection, limit additional evaluations, or both.  If an
   implementation chooses to limit additional evaluations, then at least
   a total of 10 evaluations of check_host() for a single query MUST be
   supported.  (This number should be enough for even the most
   complicated configurations.)

   If a loop is detected, or evaluation limit of an implementation is
   reached, check_host() MUST abort processing and return the result
   "PermError".

   MTAs or other processors MAY also impose a limit on the maximum
   amount of elapsed time to evaluate check_host().  Such a limit SHOULD
   allow at least 20 seconds.  If such a limit is exceeded, the result
   of authentication SHOULD be "TempError".

-*-*-
Although this may appear to represent a smaller number of DNS lookups,
as this does not refer specifically to a DNS lookup, the number of
lookups contained within a check_host() is undefined but may include a
dozen such lookups without invoking a redirection modifier as specified
within the draft.
-*-*-

   The check_host() function fetches published records, parses them, and
   interprets them to evaluate if a particular host is or is not
   permitted to send mail in a given context.

...

4.2 "include"

      include = "include" ":" domain-spec

   The "include" mechanism triggers a recursive evaluation of
   check_host().  The domain-spec is expanded as per section 7.  Then
   check_host() is evaluated with the resulting string as the <domain>.
   The <ip> and <sender> arguments remain the same as current evaluation
   of check_host().

   "Include" makes it possible for one domain to designate multiple
   administratively independent domains.


These DNS lookups are contained within a check_host() lookup.

4.3 "a"

   This mechanism matches if <ip> is one of the <target-name>'s IP
   addresses.

      A = "a" [ ":" domain-spec ] [ dual-cidr-length ]

   The <ip> is compared to the IP address(es) of the <target-name>.  If
   any address matches, the mechanism matches.

4.4 "mx"

   This mechanism matches if <ip> is one of the MX hosts for a domain
   name.

      MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]

   check_host() first performs an MX lookup on the <target-name>.  Then
   perform an A lookup on each MX name returned, in order of MX
   priority.  The <ip> is compared to each returned IP address.  If any
   address matches, the mechanism matches.

   Note Regarding Implicit MXes: If the <target-name> has no MX records,
   check_host() MUST NOT pretend the target is its single MX, and MUST
   NOT default to an A lookup on the <target-name> directly.  This
   behavior breaks with the legacy "implicit MX" rule.  See [RFC 2821]
   Section 5.  If such behavior is desired, the publisher should specify
   an "a" directive.

4.5 "ptr"

   This mechanism tests if <ip>'s name is within a particular domain.

      PTR = "ptr" [ ":" domain-spec ]

   First the <ip>'s name is looked up using this procedure: perform a
   PTR lookup against <ip>.  For each record returned, validate the host
   name by looking up its IP address.  If <ip> is among the returned IP
   addresses, then that host name is validated.  In pseudocode:

     sending-host_names := ptr_lookup(sending-host_IP);
     for each name in (sending-host_names) {
       IP_addresses := a_lookup(name);
       if the sending-host_IP is one of the IP_addresses {

         validated_sending-host_names += name;
     } }

   Check all validated hostnames to see if they end in the <target-name>
   domain.  If any do, this mechanism matches.  If no validated hostname
   can be found, or if none of the validated hostnames end in the
   <target-name>, this mechanism fails to match.

   Pseudocode:
     for each name in (validated_sending-host_names) {
       if name ends in <domain-spec>, return match.
       if name is <domain-spec>, return match.
     }
     return no-match.

   This mechanism matches if the <target-name> is an ancestor of the
   name of <ip>, or if the <target-name> and the name of <ip> are the
   same.  For example: "mail.example.com" is within the domain
   "example.com", but "mail.bad-example.com" is not.  If a validated
   hostname is the <target-name>, a match results.

   Note: This mechanism represents a burden on the reverse DNS tree.
   Therefore, it should be used only as a last resort, if domain policy
   cannot be expressed using alternative mechanisms.  If a domain
   decides to use it, it should ensure it has the proper PTR records in
   place for its hosts.

-*-*-
Due to address sorting and long lists, A, AAAA, and MX records may not
provide a complete list of addresses and may be useless as a means of
authentication.  Another concern is that PTR records could be used to
poison the DNS cache.  (MX and SRV records do not allow use of an
aliased name.)

Network integrity is significantly reduced, as the typical timeout
defaults to 5 seconds for unknown DNS server, a 20 second timeout could
be tripped by two packets lost out of an untold number.  If there is 10
RR references per SPF RR accessed by the Check_Host() function, then the
amount of DNS traffic is not reduced by this specification, but could
exceed more than 100 DNS queries!  It would appear by specifying a limit
in this manner, the effect is to greatly increase the possible DNS
queries required to support this scheme.  This is not a reduction as you
suggest.  DNS is not HTTP.

-Doug


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