ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] protecting domains that don't exist

2008-04-11 22:49:39
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