The SPFbis document improperly conflates DNS terminology with identical terms
invented by this document. Examples are terms used to describe mechanisms
having the same identifier differentiated between mechanisms and DNS resource
records by using lower and upper case respectively. References to SPF records
are differentiated by a textual prefix and not by TYPE as defined by DNS.
In addition, the MARID WG NEVER reached consensus. A follow-on group operating
outside of the IETF required a promise of support to subscribe to their mailing
list. When one looks at how SPF is commonly used, the pre-existing APL
resource record offered an effective alternative, but was oppose by a
particular vendor unwilling to fully implement DNS. Currently this vendor is
seldom used to directly interface with MTAs on the Internet and no longer
justifies the use of the TXT records. As such, the SPF Resource Record should
not have been deprecated.
This draft should be made Informational and not Standards Track.
Section 4.6.4 fails to offer a sufficiently clear warning about potential
magnitudes of DNS transactions initiated by a single SPF evaluation where two
are recommended to occur one for the separate identifiers. In fact, this
section appears to make assurances no more that 10 DNS queries will result and
is widely misunderstood.
4.6.4. DNS Lookup Limits
Was:
,--
SPF implementations MUST limit the total number of mechanisms and
modifiers ("terms") that cause any DNS query to 10 during SPF
evaluation.
'--
Change to:
,---
SPF evaluation must limit the number of mechanisms, and the modifier
term 'redirect' to occur in no more than10 instances within the
evaluation process. The mechanisms 'ip4', ip6', and 'all' are
excluded from this instance limitation. Each mechanism is permitted
to resolve subsequent resource record sets (RRsets) that MUST not
contain more than 10 resource records to complete a match check.
When the number of instances exceeds 10, or when subsequent
resolutions exceeds 10, check_host() MUST produce a “permerror”
result.
The maximum number of DNS transactions initiated by an SPF
evaluation is therefore 1 for the initial SPF resource record, 10 for
each mechanism times 10 transactions needed to complete a matching
process for a total of 111 DNS transactions. This number excludes
those required by DNS to fulfill a request and those required by an
EXP modifier.
The recommended 20 second evaluation timeout imposes a maximum
network distance of less than 27,000 kilometers or a little more than
half the circumference of the Earth. Even a 60 millisecond delay can
result in more than a 6.6 seconds consumed by the round trip
overhead needed for each SPF evaluation.
The overall resulting maximum number of DNS transactions for
both "HELO" and "MAIL FROM" is 222 DNS transactions. Since
check_host() introduces macros and name expansions that
combine mechanisms and modifiers in a manner not directly
supported by DNS, the entire set and sequence of SPF based
DNS transactions is required for each evaluation. While SPF now
has a 2 limit of void lookups, use of synthetic domains has become
a popular technique for tracking traffic which can be used by
malefactors to overcome this SPF void lookup limit.
Once DNSsec becomes a requirement, SPF will have created an
inordinate number of transactions and overall traffic per message
exchange that will impose a SIGNIFICANT reflected amplification risk.
'---
Related information:
<random-string>cdr-ds.metric.gstatic.com
<random-string>.g.vm.akamaistream.net
are domains on sizable networks that act as a wildcards. In the second
instance, the wildcard points to a CNAME that then resolves an A record. Such
use compared against http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01
produces a much larger amplification than the x320 gain estimated. Use of
DNSsec further increases this gain estimate. Although details differ from case
to case, the synthetic domain technique is seeing greater use. One of the
initial reasons for using TXT records without any prefix was to permit use of
wildcards. This dangerous feature means SPF allows malefactors to leverage any
large TXT resource record that otherwise would not have been problematic.
Again this risk increases when DNSsec becomes required and represents another
reason for not deprecating the SPF resource record type.
Remove this misleading paragraph within section 4.6.4:
,---
When evaluating the "mx" mechanism, the number of "MX" resource
records queried is included in the overall limit of 10 mechanisms/
modifiers that cause DNS lookups described above. The evaluation of
each "MX" record MUST NOT result in querying more than 10 address
records, either "A" or "AAAA" resource records. If this limit is
exceeded, the "mx" mechanism MUST produce a "permerror" result.
'---
MX resource records do not contain IP addresses.
Per RFC1035 the structure for an MX record is roughly as follows:
A 16 bit PREFERENCE (distance) value followed by an MTA hostname.
A DNS MX reply may offer A records for the hostnames in the Additional Section
however per:
Per RFC2181 Section 5.4:
,---
Servers must never merge RRs from a response with RRs in their
cache to form an RRSet. If a response contains data that would form
an RRSet with data in a server's cache the server must either ignore
the RRs in the response, or discard the entire RRSet currently in the
cache, as appropriate.
'---
This will not prove ideal for SPF with respect to effective use of DNS.
Also hostnames contained within MX resource record might be within any domain,
and not necessarily the same domain as that of the base SPF record.
Per RFC2181 5.4.1. Ranking data
An authoritative answer from a reply should replace cached data that had been
obtained from additional information in an earlier reply. However additional
information from a reply will be ignored if the cache contains data from an
authoritative answer or a zone file.
Mistake.
Section 3.4
Second paragraph:
Similarly, the sizes for replies to all queries related to SPF have to be
evaluated to fit in a single 512 octet UDP packet.
s/UDP packet/DNS message/
Per RFC1035
Section 2.3.4. Size limits
UDP messages 512 octets or less
Section 4.2.1. UDP usage
Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP
headers).
The DNS message size limitation is not the same as a UDP packet limit as
suggested in Section 3.4.
The SPFbis WG charter permitted removal of unused protocol elements where the
“ptr” mechanism was deprecated and the SPF resource type was removed. Use of
SPF’s very dangerous macro feature currently has less than 0.053% of the
domains making use of these macros and clearly falls below the WG removal
threshold. We have also been told by a few very large providers that SPF
records containing any macro reference are ignored for reasons related to both
efficiency and security. Marcos also inhibit the primary use by large
providers which is to compile the domain’s IP address list.
The WG should have been told to focus on security and at better insuring
interchange to achieve a safer stance moving forward.
Regards,
Douglas Otis