At 05:07 PM 4/4/2005 -0700, Douglas Otis wrote:
On Mon, 2005-04-04 at 16:29 -0700, David MacQuigg wrote:
At 09:30 AM 4/4/2005 -0700, Doug Otis wrote:
The SRV record does not require the administrator to enter any address
whatsoever. SRV records are strictly name based associations. This
also ensures only a single DNS lookup is needed to resolve the
authorization and authentication associated with the SMTP client's
connection. This simplifies the maintenance of these records, and
lowers the risk of publication error.
I don't see how CSV avoids entering IP addresses, or how it simplifies
maintenance, especially for a large domain with hundreds of public mail
servers. Don't you need both an SRV record (name) and an A record (IP
address) for each one of those servers? Fundamentally, you always have to
make an association between a name and an address.
The SMTP clients will already have an A record. The SRV record simply
uses the name of the A record as a Target. Therefore, DNS
administrators do not enter an address for the SRV record, just the
name. The association is between HELO and Target name, not addresses.
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.
Would it not be simpler to have one record list all the mail-serving IP
blocks for an entire domain? Take a look at the SPF record for
rr.com. They list all their mail servers in 12 blocks of 256 IPs
each. That would allow maybe 2000 servers to be moved freely among the
3072 possible IP addresses, so there isn't a maintenance problem that I
can
see.
With CSV, there is an assurance all required information will be within
a single DNS lookup.
What if the server is six levels down at
server6.rack5.room4.bldg3.company2.com? Doesn't that require a DNS query
at each level? Won't caching be less effective at the lower levels, where
you are likely to get a different server for each email. Compare this to
caching one record from rr.com, then using that same record to authenticate
5000 emails from 500 different servers in 12 different subdomains.
You REALLY don't care about all the other SMTP
clients that may be used. You only want to know about the current SMTP
client.
You get the entire list of rr.com IP addresses in one query. The ones you
don't care about are free, and if you keep them in a cache, the next 5000
emails from any server at rr.com can be authenticated from the cached record.
Addresses are not static, not even blocks of addresses.
Public mail servers should have static addresses. Moving them would be a
lot less hassle without having to change all those A and SRV records. I've
never done this, so tell me if I'm guessing wrong. The scenario I have in
mind is moving a room full of servers to another building. First add the
new IP block to the main SPF record at rr.com. After a few days, when all
the servers have been moved, delete the old IP block. A mail server
declaring the identity rr.com can send from any address in one of rr.com's
authorized blocks.
Large blocks of addresses also requires parsing using a script language.
This has got to be an insignificant cost, certainly less than a DNS query
for each address.
Prior to the effort to distill these thousands of addresses to CIDR
notation, there was 78 DNS lookups to obtain the address list for rr.com
when using name references. Hand manipulating thousands of addresses is
still a maintenance headache.
The compilation, sorting, and compaction of address blocks is done once by
the sending domain using a tool with a nice user interface. Input is
something convenient, like CIDR notation, and output is a compact string
ready for the DNS server. The user is cautioned never to attempt hand
editing of the compiled record.
By using name associations, changing the
individual address record will update all related records, whether these
are the MX or the SRV records. No special tools are required.
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.
This SRV record, used in conjunction with a reputation service, may
provide DoS protections. SPF, for example, requires more than one
hundred DNS lookups, as a minimum, to ensure all clients that may send
from a particular domain can be resolved. Rather than retaining just an
manually generated address listing, (which is error prone) SPF has opted
to extend the number of queries to allow references by name for specific
clients. SRV already provides this name based reference feature.
The latest developments involve an "SPF compiler" to produce a simple list
of IP blocks from the more complex SPF "source record". This works for
most mechanisms, but there will still be problems with some. My guess is
that the troublesome mechanisms will eventually be deprecated, and SPF
will
arrive at an optimum by backing off on some of their over-design.
Start with a square stone, chip away at the corners, and eventually you
will reinvent the wheel.
Great analogy!! SPF has a bunch of corners that need to be rounded
off. CSV needs some ball bearings to make it roll with less friction.
For HELO, SRV already provides this "compiled"
list of addresses. This is done at the lowest level of complexity
possible; the single SMTP client.
"Compiling" the address blocks saves time and space if you have a lot of
similar information to compile, like racks of dedicated outgoing
servers. For single servers, it seems like SPF and CSV will both require
attention to individual server records.
In addition, the need to list all
associated addresses vanishes when DomainKeys is used, as the signature
can better associate all related sources. Bulk emailers simply sign
their mail to achieve the same result, while not having problems with
forwarded accounts, etc.
I think it would be advantageous even with signature-authenticated messages
to do a quick IP authentication at each hop. That will reject most
forgeries at the earliest opportunity and minimize Internet traffic. Since
a forwarder will not know without a DNS query whether a message uses
signature or IP authentication, at least one DNS query at each hop will be
necessary anyway. One query should get whatever authentication information
a domain provides, including a compact list of IP address blocks.
The use of the SRV record avoids complexity by keeping within the
designed scale of DNS by attempting to only resolve the client
associated with the HELO, rather than answer a much more expansive (and
impossible) question regarding all the possible clients that send a
specific mailbox-domain.
It seems like the choice now is between CSV with a large number of
single-server records, and SPF with far fewer records but the potential
for
abuse of its whiz-bang features. What I'm looking for is an optimum that
has the safety of CSV and just a few of the features of SPF. The ability
to authorize hundreds of servers in a domain, using one cacheable DNS
record, seems like a feature that CSV could use. It would be easier on
DNS
than digging down six levels to query every server, and I don't see any
potential for abuse.
The HELO should prevent any digging.
How do you find the authentication records without digging when the HELO
name is server6.rack5.room4.bldg3.company2.com ???
When CSV is not supported, there
may be a desire to do a few more queries.
One query to company2.com should get all authentication records for the
entire company. The exception is SPF, where it may be necessary to follow
a chain of "redirects" to other records. The latest development is a
compiler that generates a "mask" for an entire chain of SPF records. That
mask goes in the first record, and allows a quick FAIL of 99% of the
forgeries, which won't have an address that is "close" to an allowed
address. Confirming a PASS still requires following the redirects,
however. :>(
< snip discussion of Domain Assertions for Signatures >
It seems to me the fundamental advantage of CSV over SPF is that CSV
doesn't try to associate domain names with IP addresses outside of that
domain. The disadvantage, and it doesn't seem fundamental, is that you
can't set up just one simple record to authorize all the servers in a
domain.
Funny, that seems to be its advantage. It provides DoS protection, in
conjunction with domain based reputations, that SPF can never provide.
??? The disadvantage is the effort to set up all the DNS records
authorizing a large number of servers. I don't see the connection to DoS
protection.
On the DoS vulnerability issue, I think what you are referring to is the
risk arising from the macros, redirects, and includes in the SPF syntax,
all of which can generate of lot of DNS traffic, but none of which are
necessary to define a set of IP blocks.
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. A properly set up SPF record can deliver the authentication
information for an entire large domain in one query. A poorly set up SPF
record can be an opportunity for a DoS attack. I would like to see CSV
adopt the good features of SPF.
-- 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 *
************************************************************ *