In <20050803163533(_dot_)17201(_dot_)qmail(_at_)xuxa(_dot_)iecc(_dot_)com> John
Levine <johnl(_at_)iecc(_dot_)com> writes:
will get roundly flamed since it is a smop to run through your zone
files and create the necessary records to cover all existing names,
and you are not allowed to care that it doubles or triples the size of
your zones. [snip]
I agree with most of what John said here, and these are almost certainly
the types of things that the DNS gurus will say.
That said, when the namedropper folks used the "smop to add records"
line of argument with me about SPF's wildcarding solution, I really
couldn't come up with a good argument about why adding records to each
node was really that bad. Yeah, it could cause the size of your zone
file to grow a lot. Yeah, it initially struck me as very ugly. But
think abou this:
Say we have an argument that all those extra records in the zone file
*really* does cause a problem. Doesn't that mean that those same
records, once fetched individually via DNS lookups, will also cause
problems for DNS caches? And, haven't we already decided that the
effects on DNS caches isn't that bad?
People who deal with just a few small zone files can easily add the
extra records by hand. People who deal with lots of zone files, or
very large zone files are likely already to have some sort of program
to manage them. Only people who want to support DKIM (or SPF) need to
deal with adding these records.
Adding the records to the zone file doesn't require any changes to the
over-the-wire DNS protocol. On the server side, zone files are stored
on disk in one large, continuous block. They are transfered to
secondaries in those same blocks. I haven't delved into how name
servers deal with zone files in memory, but I really doubt that they
are less efficient at storing zone files than storing the equivalent
information as individual records in a cache.
So, before you go arguing that there needs to be a tree-walk, or a new
DSN wildcard and that you can't just add duplicate records, well,
think hard about it.
For SPF, we went with the "you have to create duplicate records"
method, mostly because existing SPF implementations didn't do the
zone-cut wildcarding and were were trying to document existing
practices. DKIM, I think, still has the freedom to choose.
-wayne