ietf-clear
[Top] [All Lists]

[clear] Comparing CSV and SPF

2005-04-05 13:53:30
At 01:00 PM 4/5/2005 -0400, John Leslie wrote:
David MacQuigg <dmquigg-clear(_at_)yahoo(_dot_)com> wrote:

If I'm setting up a rack of machines to be used for nothing but outgoing
mail, why do these machines need to have *any* DNS records?  Sorry if this
is a dumb question, my understanding of DNS still has gaps.  Even if we
don't count the A records as part of the required setup, we still need one
SRV record per machine.

   CSV needs one SRV record per HELO domain-name. (We in fact recommend
each machine have its own HELO string.) This is intended as the level of
granularity of CSV -- which we consider a benefit, in that problems on
one outgoing MTA need not compromise the reputation of any other MTAs

Public mail servers should have static addresses.

   In fact, most mail servers _do_ change IP addresses when the upstream
provider changes. We consider that to be often enough to worry about the
possibility of records getting out of sync.

This might save some time for a small domain with one server having 
both MX
and SRV records, but the scenario I'm thinking of would be racks of 
servers
dedicated to outgoing mail only.  I would rather not have to change any
individual address records at all.

   I may be missing your point. If the IP address of a MTA changes, you're
going to have to change _something_ in DNS. CSV adds nothing that needs
to change when the assigned IP address changes.

Can't a mail server have no entries in DNS?  Zombies do it.

If, OTOH, you mean you'd rather not have to publish a SRV record in
the first place for every MTA, we're talking the same issue of nuisance
versus granularity. We consider the nuisance small, and the granularity
valuable.

OK, we're in agreement.  The only thing I would question is the need to 
enforce that granularity.  If rr.com wants to authorize 2000 servers with 
one centralized DNS record, that should be their choice.

How do you find the authentication records without digging when the HELO
name is server6.rack5.room4.bldg3.company2.com ???

   You do a single DNS query for "server6.rack5.room4.bldg3.company2.com."

(In the absence of anything cached, this goes to the root servers and
gets nameservers for "company2.com", and a the query is automatically
repeated to one of those, which most likely will give the answer. Unless
"company2.com" _both_ delegates a "bldg3" subdomain _and_ fails to act
as secondary for it, there's no reason for more DNS traffic.)

I'm not sure what to believe.  Two other experts told me DNS caching is 
never done on the server side.  What you are saying makes sense.  Why would 
company2 *not* cache all the DNS records from its subdomains?  That would 
save a lot of unnecessary referrals and repeated queries.

I would still like to find a good description somewhere of how DNS caching 
works on the server side.  Books like "DNS & BIND" tell me how things could 
work, but not much about actual practice.  One of the experts I mentioned 
was an admin at a large domain that *doesn't* cache DNS records for its 
subdomains.

I think the problem might be that the large domain considers DNS services 
to be the responsibility of its subdomains, and doesn't want to handle that 
load.  Root domains caching records for their subdomains would reduce the 
traffic on the Internet, but not total loads within the domain.  Its just a 
transfer of loads from subdomains to the root domain.

I'll proceed for now on the assumption that the queries stop at company2, 
or at least at bldg3, and SPF has no advantage over CSV in the initial 
query for authentication records.  That still leaves open the question of 
caching on the client side.

Let's assume a 3600 second TTL, and 5000 emails from commpany2.com during 
that hour.  We might get a few emails from server6... but most of the 5000 
will be from all over company2.com.  The hundreds of cached SRV and A 
records will be nearly useless.  We will need fresh queries with almost 
every email from company2.com.

Let's see how this compares to a real domain using SPF.  Go to 
mxtoolbox.com and look at the SPF record for rr.com.  233 bytes total, 
easily fitting in one 512-byte DNS packet, and this is a huge domain with 
many subdomains and thousands of servers all over the USA.

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

Assuming the same 3600 second TTL, we need to repeat the query to rr.com 
once every hour.  The 5000 emails during that hour come from various 
subdomains like austin.rr.com, but as long as they are using an IP address 
from one of the above blocks, we can authenticate them as rr.com using only 
the local cache.

Looks to me like SPF can have better caching, and less DNS traffic.  Notice 
I say *can*.  Many SPF records indulge in all the inefficient and 
unnecessary features that SPF has to offer.  Note also that SPF *can* have 
as fine a granularity as CSV, but nobody chooses to do it that way.

Another problem with granularity being forced at the lowest level - how do 
we track the reputations of individual servers in company2.com?  You can't 
just lump all of company2 in one reputation.  When  company2 acquires a new 
division, it may want to keep the reputation of that division separate from 
the company as a whole.  It should be able to do that by simply having the 
mail servers from the new company declare their identity as 
new_division.company2.com.

One query to company2.com should get all authentication records for the
entire company.

But how would you know to query for "company2.com"? SPF knows because
it got it from an email address. CSV can't know, because it only works
on the HELO string. (Did I mention the benefits of granularity?)

Whatever benefits granularity might have, this restriction in CSV is not 
one of them.

What I would suggest is allowing the sender to *declare* its identity, 
either by flagging an existing name with a string like *ID*, or by adding a 
new one ( HELO server6.rack5.room4.bldg3.company2.com ID=company2.com 
).  This will fit right in with whatever standard emerges, assuming that 
standard does not favor one authentication method over another.

Let's not make the mistake of assuming that *everything* in SPF is bad,
because it has a few unsafe features.  In fact, the good features can
actually *reduce* the DNS load much lower that what I understand CVS will
generate.

This may actually be possible -- in a world where all MTAs are managed
by folks both clueful and considerate.  Alas, that is not the world we
live in. :^(

I wholeheartedly agree.  Whatever technical problems the different methods 
have, they aren't the reason we have no standard.  The real barriers are 
political and social.

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


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