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

[Jim Fenton]

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