Stuart D. Gathman wrote:
The SPF record at rr.com requires 78 DNS lookups before hitting the
~all at the end by my count (which counts getting an SPF record or
MX set as one lookup even though multiple queries may be needed).
As a result, I upped my DNS lookup limit from 50 to 100. Is rr.com
reasonable? If not, how should they rewrite their record?
rr.com IN TXT "v=spf1 include:biz.rr.com include:texas.rr.com
include:southeast.rr.com include:ohiordc.rr.com include:rdc-kc.rr.com
include:rdc-nyc.rr.com include:orange.rr.com include:nyroc.rr.com
include:tampabay.rr.com +mx ~all"
And the 78 lookups:
[...]
Here's how their SPF record maps out:
/* DNS load analysis by evaluating SPF @rr.com from any IP */
+-------------------+ :::::::::::::::::::::::::::::::::::::::
| library init | : SPF Load on DNS: Legend :
| | : top - State Name :
+-------------------+ : 2,3,4: - lookups: min-max limit :
|| : mid - (possible exits) :
|| : bottom - ** current result ** :
|| : M = match ? = TRY_AGAIN :
|| : ! = NXDOMAIN - = NO_DATA :
|| : () = never done due to DoS limit :
|| : For this screen, 100 lookups max. :
|| :::::::::::::::::::::::::::::::::::::::
\/
+---------------------------------+
|DNS Lookup: root SPF record |
| (TempError/nxdomain/none) |
| TXT rr.com |
+---------------------------------+
|| +--------------------------------------------------+
|| | Total queries: 1-75 limit 40 DNS lookups |
|| | A: 0-56 lim 10, PTR: 0-0 lim 10, |
|| | MX: 0-10 lim 10, TXT: 1-9 |
|| | mechanisms: 1-19 lim 10 1 matches |
|| |--------------------------------------------------|
|| | WARNING: Some of the lookups shown here will |
|| | never actually be performed due to |
|| | exceeded Denial-of-Service limits |
|| | They are marked in brackets () |
|| | The limits in effect are shown above |
|| | !! PermError may be returned intermittently !! |
|| |--------------------------------------------------|
***>>> || | ** PermError ** |
|| | +TXT-inc biz.rr.com |
|| | +MX biz.rr.com |
|| | +A mx1.biz.rr.com |
|| | +A mx2.biz.rr.com |
|| | +TXT-inc texas.rr.com |
|| | +MX texas.rr.com |
|| | +A hrndva-02.mgw.rr.com |
|| | +A austtx-01.mgw.rr.com |
|| | +A austtx-02.mgw.rr.com |
|| | +A orngca-01.mgw.rr.com |
|| | +A orngca-02.mgw.rr.com |
|| | +A hrndva-01.mgw.rr.com |
|| | +TXT-inc southeast.rr.com |
|| | +MX southeast.rr.com |
|| | +A hrndva-02.mgw.rr.com |
|| | +A austtx-01.mgw.rr.com |
|| | +(A) austtx-02.mgw.rr.com |
|| | +(A) orngca-01.mgw.rr.com |
|| | +(A) orngca-02.mgw.rr.com |
|| | +(A) hrndva-01.mgw.rr.com |
|| | +TXT-inc ohiordc.rr.com |
|| | +MX ohiordc.rr.com |
|| | +(A) orngca-02.mgw.rr.com |
|| | +(A) hrndva-01.mgw.rr.com |
|| | +(A) hrndva-02.mgw.rr.com |
|| | +(A) mx-server.mgw.rr.com |
|| | +(A) clmboh-01.mgw.rr.com |
|| | +(A) clmboh-02.mgw.rr.com |
|| | +(A) orngca-01.mgw.rr.com |
|| | +TXT-inc rdc-kc.rr.com |
|| | +MX rdc-kc.rr.com |
|| | +(A) kc.mgw.rr.com |
|| | +(A) vamx02.mgw.rr.com |
|| | +(A) kcmx01.mgw.rr.com |
|| | +(A) kcmx02.mgw.rr.com |
|| | +(A) lamx01.mgw.rr.com |
|| | +(A) lamx02.mgw.rr.com |
|| | +(TXT-inc) rdc-nyc.rr.com |
|| | +(MX) rdc-nyc.rr.com |
|| | +(A) nymx-1.nyroc.rr.com |
|| | +(A) nymx-2.nyroc.rr.com |
|| | +(A) nycmx01.mgw.rr.com |
|| | +(A) nycmx02.mgw.rr.com |
|| | +(A) nycmx03.mgw.rr.com |
|| | +(TXT-inc) orange.rr.com |
|| | +(MX) orange.rr.com |
|| | +(A) lamx02.mgw.rr.com |
|| | +(A) lamx03.mgw.rr.com |
|| | +(A) kcmx01.mgw.rr.com |
|| | +(A) kcmx02.mgw.rr.com |
|| | +(A) orange.mgw.rr.com |
|| | +(A) lamx01.mgw.rr.com |
|| | +(TXT-inc) nyroc.rr.com |
|| | +(MX) nyroc.rr.com |
|| | +(A) usny.mgw.rr.com |
|| | +(A) vamx02.mgw.rr.com |
|| | +(A) nymx-1.nyroc.rr.com |
|| | +(A) nymx-2.nyroc.rr.com |
|| | +(A) nymx05.mgw.rr.com |
|| | +(A) nycmx01.mgw.rr.com |
|| | +(A) nycmx02.mgw.rr.com |
|| | +(TXT-inc) tampabay.rr.com |
|| | +(MX) tampabay.rr.com |
|| | +(A) florida.mgw.rr.com |
|| | +(A) vamx02.mgw.rr.com |
|| | +(A) flmx-1.tampabay.rr.com |
|| | +(A) flmx-2.tampabay.rr.com |
|| | +(A) txmx-1.texas.rr.com |
|| | +(A) txmx-2.texas.rr.com |
|| | +(MX) rr.com |
|| | +(A) vamx02.mgw.rr.com |
|| | +(A) herndon.mgw.rr.com |
|| | +(A) vamx04.mgw.rr.com |
|| | +(A) vamx01.mgw.rr.com |
|| | +(A) vamx03.mgw.rr.com |
|| +--------------------------------------------------+
|| || (recursively) /\
\/ \/ ||
+---------------------------------------------------------------------+
| Sender's SPF record evaluation |
| Default result : softfail |
+---------------------------------------------------------------------+
This is the output of the "spfquery -ip 1.1.1.1 -sender=rr.com -load"
that will be included with libspf2 1.0.6, which I will release soon.
I was going to mention this too, because I think it's unreasonable for
the library defaults to allow any more than 10 queries by default.
For a domain that needs this much mail infrastructure, there are a few
easy ways to reduce the DNS load:
1. implement a real-time DNS lookup table that can be accessed with the
exists:%{ir}.mailhosts.rr.com for instance.
2. add a single "A" record that resolves to a long list of IPs.
3. Use includes and specify the mail servers by IP address, the way
hotmail is doing it.
Also, I think the spec should recommend a (small) minumum number of
lookups that should be done by a checking host. Currently, only a
maximum (111) is specified to mitigate DoS, but there's no minumum.
A mail admin would need to know what the highest number of lookups he
can count on for his domain's SPF resolution such that his mail passes
SPF checks reliably at all receivers.
Out of the domains participating to this mail-list, here are some DNS
load statistics below. What are the legitimate scenarios that make it
necessary to publish such expensive SPF records? (The "queries min-max"
column indicates the fewest number of queries necessary to find the
first IP address, and the max is the number of queries needed to
evaluate all mechs - ie, to get to the -all).
Domain |Queries min-max| TXT | PTR | A | MX |
---------------------+---------------+-------+-------+-------+-------+
6o4.ca | 04-07 | 01-01 | 00-01 | 01-03 | 01-01 |
ashtonwoodshomes.com | 01-09 | 00-03 | 00-01 | 00-03 | 00-01 |
dumbo.pobox.com | 02-07 | 00-00 | 00-00 | 01-04 | 00-02 |
irislink.com | 03-11 | 01-05 | 00-00 | 01-04 | 00-01 |
kitterman.com | 02-18 | 01-02 | 00-01 | 00-12 | 00-02 |
leave-it-to-grace.co | 02-10 | 00-00 | 00-00 | 01-06 | 00-03 |
pobox.com | 03-23 | 00-01 | 00-00 | 01-18 | 01-03 |
v2.listbox.com | 04-12 | 01-02 | 00-01 | 01-06 | 01-02 |
w3.org | 02-19 | 00-00 | 00-01 | 01-14 | 00-03 |
Greetings,
Radu.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
radu.vcf
Description: Vcard