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