At 07:27 PM 6/24/2005 +0000, John Levine wrote:
That's a poor assumption. As I think we've mentioned several times
recently, CSV records are designed to identify client hosts, not
domains, and a normal setup would be to have a CSV record per mail
client.
Nevertheless hosts are multi-homed, and have multiple names. It's not
entirely insane to want to be able to use multiple SRV records for that
reason.
Sure, but the question is who does the work to track the configuration
of a complex host. SPF goes all the way to one extreme of pushing the
job off to runtime. Meng has said that he did it this way because SPF
records are written by zillions of mail admins, while SPF interpreters
are only written by a handful of MTA geeks, so only the geeks have to
understand how to interpret all the glop. I think we can fairly say
that hasn't worked out very well, since it makes SPF records extremely
fragile and it requires that clients use all sorts of heuristics
against complex SPF data that can have the side effect of making SPF
checks fail in unexpected and hard to predict ways.
I don't think that CSV is in any danger of becoming as baroque as SPF,
but I do think we need to face the question of whose job it is to
track the structure of complex network setups. My feeling is pretty
simple: it's your network, so it's your job, and I don't want to know
about it. Hence my suggestion for CSV is equally simple.
I propose that any given name can have at most one CSV record. The
name it refers to can have as many A records as needed. If your mail
host hops from place to place, that's fine, you collect the A records
and publish them. If the A records change, that's still fine, you can
update what you publish. If your setup is so complex that the A records
won't fit into a UDP packet, you have worse problems than CSV.
If there's more than one CSV record, that's a mistake, the behavior is
unspecified, we encourage but do not require that clients diagnose it.
This simplifies the lookup code and lets us promise that a CSV check
will take at most two DNS lookups, no matter what.
Re Tony's suggestion that the record fit in a UDP packet, I don't
think that's such a great idea for a couple of reasons. One is that
it's a fragile heuristic which can break if, for example, an authority
record grows. In the presence of EDNS0 which is implemented in a lot
of places, it's not even clear what fitting in a UDP packet means, 512
bytes or what an EDNS0 client says. So again, I'd rather skip the
whole argument and say one record, period.
Seems like the fundamental requirements for an ideal authentication record are:
1) Fit well within one 512-byte DNS packet, including some margin for later
expansion of other sections of that record.
2) Accommodate any reasonable number of IP addresses in a multi-homed host
setup.
3) Maximize the efficiency of DNS caching by encouraging aggregation of IP
addresses into one record.
4) Avoid problems with unexpected variations in the response to a query,
problems like incomplete record sets.
5) Avoid the temptation of including hosts outside the direct and immediate
control of the sender.
6) Avoid opportunities for abuse, especially anything involving DNS.
How about allowing one CIDR block?
I am not an expert, just an outsider with what I hope are some fresh ideas.
--
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 *
************************************************************ *