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.
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.
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.
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.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html