John Levine wrote:
I said:
The current version of ADSP has a one level tree walk that modestly
decreases the number of records you have to add, in exchange for
making every ADSP lookup more complicated.
Jim said:
... Whether the decrease in the number of records you have is modest
or not depends a lot on your domain: If you have a small domain,
it's very modest. But some domains have tens or hundreds of thousands
of labels such as hostnames, and the prospect of publishing an ADSP
record for each one is non-trivial.
Indeed it's non-trivial if your DNS managers aren't capable of
automating it, but if your domain names are more than one deep, it's
also mandatory.
You do need to publish records for the immediate parents of all names
you intend to cover, so if you have a.foo.example.com you need to
publish at least foo.example.com. But this is still a substantial
savings over having to publish for all leaf nodes, because it is the
rare domain that has multilevel names that don't have some relationship
to each other, i.e., it's rare to have a.foo.example.com and not (other
things).foo.example.com. So you're saving by covering all of
foo.example.com with a single record.
The current optimization is useful IF you have a lot of first level
subdomains AND you don't have any lower level subdomains AND you have
hostile DNS managers who won't automate the process of creating the
ADSP records. While I don't doubt that there are domains like that,
it strikes me as a severe case of premature optimization to design
with them in mind.
I'm not aware of any tools currently in existence that would automate
this process, so the practical requirement to have such tools would be a
major obstacle to getting complete ADSP coverage for many large
domains. As I said above, the optimization is still effective if you do
have lower level subdomains; it just requires the publication of ADSP
records for those subdomains that would in turn cover the terminal nodes
within those subdomains. This is still a very substantial optimization
in most cases, even though it does not optimize to publishing just one
record.
These records also cache individually, so it might be interesting if
someone spoofs a large number of hostnames within a domain, such as a
DHCP address pool.
Assuming the cache does proper RFC 2308 negative caching, if you have
an explicit record, it'll be cached, if not you'll have a negative
cache entry where the record would have been, along with a second
lookup (which with luck will hit the cache) for the upper level
record. The load and performance with the tree walk is if anything
marginally worse. I also note that a lot of DHCP address pools have
names several levels deep, e.g. cpe-74-72-193-44.nyc.res.rr.com, so
the tree walk would be of minimal help anyway.
The caching argument was not well thought out, I'll admit. I'm not too
worried about the load if it's only marginally worse, if it makes it
practical for domains to publish ADSP records. But the name
cpe-74-72-193-44.nyc.res.rr.com could be covered by an ADSP record
published at nyc.res.rr.com, which would cover a large number of such
names with a single record, so there is a substantial savings in records
published.
As someone pointed out, you can interchange steps 1 and 2 in the
specification, putting the existence check first. And then, of
course, you can decide that the existence check is done outside
ADSP. If the existence check is removed, I would advocate putting in
language that says an existence check SHOULD be performed before
doing ADSP.
That seems reasonable. My objection (and I think also Dave's) is not
that it's a bad idea, but that it's not part of DKIM or ADSP.
My problem is that the existence check isn't specified anywhere else, so
should be specified in ADSP.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html