zero SOA TTL - still best practice?

[Karl Auer]

Some time ago (at least six years) I wrote a program that, among many
other related operations, creates new zones for a nameserver. This
program creates new zones that have a TTL value of zero for the SOA
record.

That's what RFC1035 seems to say it should do. When describing TTLs, it
says "For example, SOA records are always distributed with a zero TTL to
prohibit caching."

That isn't very prescriptive, now that I think about it. It doesn't say
that it should or must happen - just that it happens. But it does make
sense to me, now as then - why would anyone want to cache an SOA?

There's a sort-of-related BIND config item, "zero-no-soa-ttl", the
description of which states:

   "When returning authoritative negative responses to SOA queries set
    the TTL of the SOA record returned in the authority section to
    zero. The default is yes."

That's only for negative responses, and only for SOA queries. Still, it
does seem to suggest that other people think there's generally no need
to cache SOA records, and especially not negatively.

Anyway, I just received an email from someone who runs a secondary for
us saying that he was getting a constant 50 qps for a non-existent RR.
He says that if our SOA had a non-zero TTL, it would get cached and the
problem would move downstream and that would be nice. He *also* says
that the SOA TTL acts as an upper bound for the negative caching TTL.

I don't think he is right on either count. The querying nameserver gets
an SOA record returned, and in that record is the negative caching TTL
it should use. That is, it may not cache the SOA, but it isn't *looking*
for the SOA. It's getting one as a side effect of looking up something
that doesn't exist. The TTL of the SOA is not having any effect here.

That said, a non-zero SOA TTL certainly seems to be common, perhaps the
norm.

So to my questions:

- have I got totally and completely the wrong end of the stick here?

- should I update my program to allow non-zero SOA TTLs?
        
Regards, K.

PS: The specific query is for "swisstime.ee.ethz.ch aaaa".

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100826/d183ff65/attachment.bin>