[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Andrew
Newton
Query load is only one aspect. Truncation and cache bloat are others.
Eric Hall did a pretty good analysis of cache bloat with regard to
Caller-ID during the MARID days.
If every email user is given a key, then we have a problem.
However, I
doubt that will be the case.
I agree up to a point.
If the records are at the domain level I don't see any problem, DKIIM is
simply a linear increase in existing DNS loads. I think that it is
entirely reasonable to expect people to upgrade their DNS hardware
periodically to cope with increasing load as the net expands and use of
the net intensifies.
Going to per user keying means that we have a non-linear branch point
that causes the DNS load to grow according to a completely different
characteristic, moving from tracking server growth to tracking the
number of users and the number of emails sent.
If the only problem is cache bloat then a reasonable response would be
for the companies with large DNS installations likely to be affected by
the cache bloat to upgrade their DNS server to something with a better
cache algorithm. Since we are using prefixing the RRs are pretty easily
identified.
There are other problems that I think have to be considered, in
particular the management aspect of the whole scheme. It is quite
practical for a company like VeriSign to put in DKIIM records for our
corporate mail gateways, the infrastructure that generates automatic
mails, outsourced campaigns etc. and manage that infrastructure. We are
talking about maybe 100 records total, all of which track business
processes and can be integrated into the existing process.
If we track users we need a lot more mechanism and infrastructure, we
have to track something like 4,000 user accounts with a turnover of
maybe 1500 a year. It is quite surprising how many very short term
contractors and employees end up with mail accounts.
I don't think that people will want to manage their DNS in that fashion.