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