spf-discuss
[Top] [All Lists]

Re: Long SPF Records

2005-03-25 14:11:48
I've got some thoughts on these points, but no time to answer
right now.  I'll respond, but it may not be till Monday.

Sorry.

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.

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."

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.

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.

-- Dave
*************************************************************     *
* David MacQuigg, PhD          * email: dmquigg-spf(_at_)yahoo(_dot_)com     
*  *
* IC Design Engineer           * phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *

At 12:34 PM 3/25/2005 -0500, you wrote:

On Fri, 25 Mar 2005, at 05:43, David MacQuigg wrote:

Are long SPF records really necessary?  Can we expect large domains like
rr.com, with many subdomains like austin.rr.com to simply delegate all DNS
records to their subdomains, thus keeping them short and simple.  The
admins at rr.com could still keep everything centralized if they wished,
but to the outside world, it would appear that austin.rr.com is an
independent mail server with its own DNS records.

The likelihood of anyone sending email from an address ending in
@rr.com is so small as to be almost non-existent.  The rr.com SPF
record exists for the most part so that we have a standards-based
way to communicate to other ISPs the answer to a question that
human representatives of those ISPs sometimes ask, to wit:

  "Can you tell me where your outbound email servers are so that
   we may take steps to ensure we don't reflexively block them?"

Road Runner customers currently all have email addresses ending
in @$foo.rr.com, where $foo is a subdomain of rr.com that
represents the local Time Warner Cable division from which they
have purchased Road Runner service.  Because all of our customers
(and employees) will send email from @$foo.rr.com, we have
published SPF records for each of these domains.

rr.com's SPF record seems to be well within the 512 byte limit,
and is also well under the currently discussed 10 method limit,
is it not?

# dig +sho rr.com txt
"v=spf1 ip4:24.30.203.0/24 ip4:24.28.200.0/24 ip4:24.28.204.0/24
ip4:24.30.218.0/24 ip4:24.93.47.0/24 ip4:24.25.9.0/24
ip4:65.24.5.0/24 ip4:24.94.166.0/24 ip4:24.29.109.0/24
ip4:66.75.162.0/24 ip4:24.24.2.0/24 ip4:65.32.5.0/24 +mx ~all"

Why does it keep getting mentioned in this thread?


There is a question about caching that was answered earlier, but I think
the answer may be wrong, so I'll ask again.  Can a DNS server at rr.com
cache the records from austin.rr.com, and thereby minimize the DNS traffic
to its subdomains, or is caching limited to *only* the nameserver at the
host making the query?  Section 14.7 Caching, in Stevens TCP/IP 
Illustrated
says "To reduce the DNS traffic on the Internet, all name servers employ a
cache."  The word *all* here makes this a pretty strong statement.  Also,
it makes sense that rr.com would cache austin.rr.com.  Even with thousands
of subdomains, it would be more efficient for rr.com to handle all the
queries directly.

The problem with Mr. Stevens' pronouncement here is that it was
likely written during a time when it was not unusual for DNS
servers to perform the function of both being authoritative for
the local parts of the DNS name space at a site and for providing
DNS resolution services for clients at that site, and perhaps
others.  Things have changed since that book was written,
especially at large sites.

The authoritative servers for rr.com are not there to provide
recursive answers to queries from the rest of the Internet, or
even from our own customers, really.  They delegate authority for
different parts of our name space to various and sundry
nameservers at various and sundry data centers scattered across
the country; these various and sundry nameservers are managed by
people local to those various and sundry data centers.  Our
customers are provided with caching-only DNS servers to use to
resolve any DNS queries that they may generate during the course
of their using their Internet connection.

It is not necessarily the responsibility of the rr.com
authoritative nameservers to cache anything, even for parts of
our own name space; it is their responsibility to provide
authoritative answers for rr.com, and those answers can correctly
include referrals to other nameservers for sub-domains of rr.com:

# dig +sho rr.com ns
dns3.rr.com.
dns4.rr.com.
dns1.rr.com.
dns2.rr.com.

# dig +sho austin.rr.com ns @dns2.rr.com
dns-sec-02.texas.rr.com.
dns-pri-01.texas.rr.com.

This is an absolutely correct method for managing our part of the
DNS name space.

We are not interested in minimizing traffic to our subdomains; we
are interested in distibuting the traffic across many servers in
various parts of the country, where the local knowledge of the
namespace is maintained.

"To reduce the DNS traffic on the Internet, all name servers
employ a cache."  - All name servers here include the resolving
nameservers that need to find authoritative answers for remote
domains, but are not themselves authoritative for those remote
domains.  Every query gets an answer that includes a Time To Live
(TTL) value, and that comes with two expectations:

1. The resolving name server will trust that answer to be true,
   and will answer subsequent queries for that record from its
   own cache, until the TTL expires. This is the reduction in
   DNS traffic on the Internet that Stevens wrote about.

2. The authoritative name server will trust that it will take
   at least the duration of the TTL for changes made to a given
   record to propagate to the rest of the Internet.  This means
   that the authoritative servers must manage change to records
   carefully, with planning beforehand and reduction of TTL
   values to very short durations long before the change it to
   take place.

We (RR) expect that remote DNS servers will cache answers about
rr.com, austin.rr.com, and everything else that they query our
authoritative servers for for the duration of the TTL that we
provide with our answers.  We are not alone in this expectation;
everyone who runs an authoritative DNS server for any part of the
DNS namespace shares this expectation for the answers they
provide.

--
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


-------
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


-- 
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>