spf-discuss
[Top] [All Lists]

Re: Long SPF Records

2005-03-27 12:33:48
On Fri, 25 Mar 2005, at 12:12, David MacQuigg wrote:

Todd,

Thanks for your excellent and authoritative answer to my questions.  My use
of the rr.com example was not to imply there was a problem with your setup,
which appears to be very well managed.  I was using it as an example of a
large domain with many sub-domains, the kind of situation where we might
expect a problem to occur if there were some future SPF-doom virus.

It strikes me that the pain felt from an SPF-doom virus would be
felt on the SMTP and DNS servers of the domain handling the
inbound email connections, and not necessarily the DNS servers of
the domain being spoofed in the attack.  For example, if a
million virus-infected hosts were to simultaneously send email
spoofed to be from rr.com to an unknown number of SPF-checking
domains, the sum total of DNS queries sent to the rr.com
authoritative DNS servers should equal no more than the number of
SPF-checking domains being hit with this mail, and will likely be
much less than that.  This presumes, of course, that domains doing
SPF checking on inbound mail are also going to be doing the right
thing with regard to caching the answers and honoring the TTLs on
the answers they receive from rr.com's authoritative servers; I
have to believe that almost all, if not all, domains doing
inbound SPF checking are honoring TTLs.  Our TTLs on our SPF
records are really too low at present, and I'll be making
recommendations to change them in the near future.  We don't need
short TTLs on our records, because our outbound server deployment
is such that new servers would be placed in networks that are
already published as part of our current SPF records.

Those who would attempt to launch a DoS attack against our (or
anyone's) authoritative name servers don't necessarily need to
use an SPF-related vector to do so.  Any large-scale query load
directed at DNS servers, regardless of resource record type, can
accomplish that goal.


The choice you have made, delegating all DNS responsibilities to your
subdomains, seems like the right way to manage a large domain, and also the
best way to minimize problems with excessively long or complex SPF
records.  I'm still wondering, however, if we can expect other large
domains to do the same.  Can we really say to these domains, "Don't nag us
about needing more complex or longer SPF records.  Do your setup like
rr.com has done it."

I think we're an outlier here.  If I understand SPF records, at
their core they're about announcing the likely (or only) sources
from which email purporting to be from a given domain may
originate.  I am not aware of other large providers who give
customers email addresses that go deeper than two levels;
aol.com, yahoo.com, comcast.net, adelphia.net, etc.  Even large
employers tend to stay at the second-level domain with their
email addresses.

Road Runner grew up as a joint venture, with several stakeholders
and a decentralized structure for managing and offering services.
In recent years, things have streamlined somewhat
organizationally, but we're still a service that is sold by forty
or so local Time Warner Cable franchises, and so we have our
email anchored in the sub-domains that we have.


On the question of rr.com caching records for its subdomains, if I
understand you correctly, you are saying its possible, but not necessary,
and you actually do better by distributing the load to nameservers in the
subdomains.  Your expectation is that queries to rr.com will be cached by
the client's nameserver, so an SPF-doom attack would be amplified very
little from the few extra queries to rr.com.  That seems reasonable, but
maybe Radu could comment on this.  I can imagine rr.com being included,
just because it has a long, though perfectly legal, SPF record.

See above regarding the amplification of the attack.

On the expectation of caching answers to queries, my expectation
is shared by everyone who runs an authoritative name server for
any part of the DNS name space.  Remote resolvers will be asked
by their clients to get an answer to a DNS query (hostname to
IP mapping; MX, NS, or TXT records for a domain; IP to hostname
mapping, etc.) and the remote resolver will issue a series of
queries until it gets an authoritative answer from a server
deemed to be authoritative for the given part of the namespace.
With that answer will come a TTL, which in essence will say,
"Trust this answer for $TTL seconds".  Properly designed
resolvers will honor this TTL and provide subsequent answers for
this query from their own cache until the TTL expires[1].  This
is the way the DNS is designed to work.

What you seem to be looking for here is that our (or anyone's)
authoritative name servers provide answers with TTL values of
zero seconds; that's not going to happen.  If it were to happen,
every time someone at your site wanted to send email to, say,
aol.com, your DNS or mail server would have to issue queries to
the root nameservers to find the servers for .com; issue queries
to the .com servers to find the servers for aol.com; issue
queries to the aol.com servers for the MX records for AOL; and
then issue more queries to the AOL servers for the IP addresses
of the mail servers.  Add another layer of queries for email to
$foo.rr.com, because all you're going to get from the rr.com
authoritative name servers is the NS records for $foo.rr.com.
Lather, rinse, repeat for each subsequent email sent to aol.com,
or to any other domain, or each time someone tried to surf to (or
reload) a given webpage, etc.  Watch the network bandwidth not
currently clogged with spam fill up with DNS traffic, and watch
the Internet die an ugly death.


On another question, what do you think of the proposal to include the
sender's IP address in every SPF query?  That would add a few bytes to the
query, but would allow you to instantly detect forgery attempts against
your domain, new zombies within your domain, or a legitimate server that
somehow got left out of your SPF record.  The extra information might also
be useful in other future scenarios, like maybe prioritizing DNS requests
during a DDoS storm.  Any query without an IP gets lower priority.

Our AUP doesn't forbid our customers from running mail servers
(or any kind of server), even in our dynamic space.  (There is a
persistence to the IP address enjoyed by our cable modem
customers, given the always-on nature of their connection, that
one may not find in a dynamic dialup pool, for instance.)  I can
assure you that we did not leave out any Road Runner-managed SMTP
servers from our SPF record.

It strikes me that including IP addresses in the query doesn't
buy us much, really, because our SPF records don't end in "-all".
Even if they did, it might be interesting to know who's trying to
forge email from us from outside our networks, but there's no
guarantee that the owners of those outside networks would be
interested in doing anything to take action against the forgers.
We'd be powerless to stop them, because we presumably would have
no control over the network connection being used by the person
forging email from rr.com, yes?

Of course, if we were to change our AUP in the future[2] and
change our SPF records to end in "-all", then there is value in
the IP address being included in the quere.

[1] There are cases where a resolver will get buried by queries
    which will cause it to exhaust its available resources for
    storing its cache, and the resolver may expire entries from
    its cache before the TTL expires.  Usually, the logic used by
    the resolver for this emergency maintenance will focus on
    removing entries that have been asked for least recently.

[2] Do not read that statement to mean that Road Runner will be
    changing its AUP in the future.  Also, do not infer from that
    statement that Road Runner will be blocking outbound port 25
    from its customer space in the future.  I have no idea if
    such plans are currently in the works here.  I am merely
    speaking in hypotheticals at this point.

-- 
Todd Herr
Senior Security Policy Specialist/Postmaster      V: 703.345.2447
Time Warner Cable IP Security                     M: 571.344.8619
therr(_at_)security(_dot_)rr(_dot_)com                           AIM:  
RRCorpSecTH


<Prev in Thread] Current Thread [Next in Thread>