Subject: TECH-ERROR: Misuse of DNS Records

From: Douglas Otis <[email-masked]>
Date: Fri, 27 Aug 2004 11:06:29 -0700

Overview:

The Protocol draft mandates a minimum of 10 DNS text script macro
evaluations. These scripts may reference any number of A, AAAA, MX, PTR,
TXT, and SPF2 resource record types. The many functions implemented by
these scripts include error message construction, mailbox local-part
address evaluation, label construction, among others, to provide
features well beyond the basic assessment of the PRA mailbox domain. The
scripting definitions also mandate bypassing extended functions and
features beyond what is defined for the record revision. Should the
number of scripts linking to other scripts exceed a majority, the total
number of scripts becomes unbounded. Linked text scripts to separately
administered domains runs a risk of the aggregate increasing
unexpectedly beyond a total allowed. 

The Protocol draft also allows for “open-ended” definitions by appending
notation such as “+all” or “?all” to allow a differentiation of messages
inside a prescribed mail channel from those outside. This notation
requests messages outside the prescribed channel be accepted “as if”
they were inside, or accepted “as if” there were no records available,
respectably. This differentiation assumes messages are not being relayed
on the outbound path through shared MTAs, but this is not clarified in
the draft.  This notation allows for a common use where the entire
record set must be evaluated, to arrive at the result. The Protocol
draft does not prevent use of wildcards. One motivation for the use of
wildcards would be to mirror a similar technique used for MX records.
The other motivation would be to provide an evaluation of “-all” for all
undefined sub-domains, possibly to differentiate results from records
that provided “?all” results.

A common ploy used by spammers is to include several randomly generated
sub-domains that reference a wildcard DNS record. Should a domain use
wildcard records and offer “open-ended” results by appending “?all”, as
example, then references to this record will always result in a
“neutral” result, but each new reference to what amounts in the access
of the same record will invoke new query wasting the DNS cache, and
consuming time that may have been saved, had the record not employed a
wildcard technique.

Problem:

The draft also allows truncation of the DNS query process at 20 seconds
per script for an aggregate minimum of 200 seconds allotted for this
process. The resulting DNS lookups to resolve the content of the text
script could invoke a sequence of dozens of record lookups that may also
link to other text script records. The normal timeout for initial DNS
queries is 5 seconds. Each timeout then invokes an doubling (exponential
increase) in the timeout period. It is not unusual for there to be a 5%
packet loss rate for intensive DNS use.  A 20 second limit may not allow
a recovery following any packet loss and could lead to a reduction of
the communication integrity. 

The amount of DNS traffic could be relatively high, even assuming a 80%
cache hit rate should these records grow to even half of the allowed
size. With a higher UDP prevalence, the packet loss rate will increase
as UDP does not offer congestion avoidance other than by means of
exponential back-off. The draft however allows these DNS lookups to be
truncated, where there may still be packets in transit and where the
back-off period has not been achieved. This means there is NO congestion
avoidance as a result of this technique. 

This condition could become progressively worse as features are added to
these scripts growing their size and complexity. The expectations of the
DNS cache being a salvation may be overestimated, especially with bad
behaviors of spammers that may attempt to exploit these records. The
complexity of these records, the large sequential lookups, and the
indeterminate labels and record types may invite unexpected avenues for
DNS hijacking found through either cache poisoning or by spoofing. 
There should be some warning about sourcing DNS from random ports. 

Should the DNS be allotted full back-off periods, the current record
allowances may require hours to resolve. There is an alternative that
does not suffer from most of these risks but can provide the basic
features of prescribing the mail channel as defined in the MPR draft.
This approach could also avoid the IPR problems as well and was provided
to serve as an illustrative example of the potential solutions for
problems facing the implementation of Sender-ID.

Solution:

http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt

-Doug

---

From: Mark Lentczner <[email-masked]>
Date: Fri, 27 Aug 2004 13:43:35 -0700

I think your message contains two distinct issues:

On Aug 27, 2004, at 11:06 AM, Douglas Otis wrote:
> TXT, and SPF2 resource record types. ...
This seems to be a concern that the type of processing limits in the 
draft are unsuitable for keeping the amount of DNS traffic down to a 
reasonable level.  Several other people (Wayne in particular) have 
suggested other types of processing limits for the draft that would 
more precisely limit DNS queries.  Do you have a particular proposal in 
mind?

> notation such as “+all” or “?all”
I think you are concerned here that the draft allows domains to publish 
what you would argue are unsafe and detrimental records.  Do you have a 
specific proposal for changing the draft to address this issue?

> http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt
If your concerns are truly TECH-ERROR concerns with the protocol draft, 
please suggest specific ways to fix them.  If your concern is that the 
draft is so broken that the working group should abandon it and proceed 
with discussing your draft, then that is much more than a TECH-ERROR 
issue.  Perhaps it is a DEPLOY level issue, or perhaps a meta-level 
issue to be brought up with the working group chairs.

	- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 28 Aug 2004 07:51:41 -0700 (PDT)

"Mark Lentczner" <[email-masked]> wrote:
>> evaluations. These scripts may reference any number of A, AAAA, MX,
>> PTR, TXT, and SPF2 resource record types. ...
>

I view this task as finding solutions that obtain the following goals:

1) A suitable identity for performing MTA reputation checks.
2) Allow the domain to constrain their mail to sets of MTA servers.
3) Allow the domain to list typical MTA servers, if not constrained.
4) Allow a means to recommend a listing service.
5) Minimize the impact upon the existing mail infrastructure.

Contrary to a view this must be done by applying a Band-Aid, there should
be a change in how this is structured.  This change in structure will
arrive at these goals.  A side benefit in doing this is that the IPR
problem is avoided as well.

>> The Protocol draft also allows for “open-ended” definitions by
>> appending notation such as “+all” or “?all”
>

Sender-ID does not properly provide for goals 2 and 3.  Sender-ID attempts
to combine the MTA authorization with the Mailbox Domain authorization. 
This creates a problem.  Mail is often relayed through a series of servers
and is not always end-to-end.  By combining these functions, this creates
a problem of "validation promotion" where at one server, the message would
be seen as outside the prescribed Mail Channel, but at the next, the
message would be seen as inside the prescribed Mail Channel.  Users will
find that by offering an "open-ended" list to achieve the lesser goal 3,
may also find these records being exploited to send spam using their
identity, but now as fully validated.  Expecting checks made at each MTA
as a means to protect the integrity of the RFC2822 information is also a
problem.

Splitting the message authorization from the MTA authorization solves the
problem with the number of DNS lookups.  Authenticate the MTA and validate
its authorization.  The MTA authentication and authorization can be done
without adding any additional DNS lookups.  MTA authentication provides a
domain that CAN safely be used for Goal 1.  By having the Mailbox Domain
reference a list of MTA domains, either as a restriction or to indicate a
nominal, this is achieved using a non-sequential DNS lookup.  This solves
the problem of "open-ended" lists being exploited by spammers.  This
solves the problem of "validation promotion".  This solves the problem of
ISPs needing to include Resent-From headers.  This allows the MTA to be
authenticated without breaking the operation of list servers or
forwarding.

> please suggest specific ways to fix them.

I have suggested very specific ways to fix them.

> If your concern is that the draft is so broken that the working group
> should abandon it and proceed with discussing your draft, then that is
> much more than a TECH-ERROR issue.  Perhaps it is a DEPLOY level issue, or
> perhaps a meta-level issue to be brought up with the working group chairs.

The draft has been transformed dramatically several times in its recent
history.  As I see it now, the current structure is unworkable.  Changing
the structure provides virtually all the same features far better but with
MUCH less overhead and damage to the existing system.  By making these
changes, it would also dramatically reduce the cost of tracking spammers.

-Doug