zero SOA TTL - still best practice?

[Josh Littlefield]

 Confirming, RFC 2308 makes it clear that the negative caching of all
records for a zone is limited to the minimum of the SOA TTL and the SOA
"minimum" TTL field (which was given this new negative caching TTL role
in RFC 2308).  If you put a 0 TTL on your SOA records, no one can cache
your negative answers, which can cause you and them a bit of pain.

The SOA record should have a reasonable TTL, and the "minimum" field in
the SOA should also be set to a reasonable value, no larger than the SOA
TTL.  If you don't change your zone data often, then you should let
people cache your negative answers for a useful amount of time (hours,
days).

-josh

On 8/26/2010 10:52 AM, Alexander Gall wrote:
> Hello Karl
>
> On Thu, 26 Aug 2010 23:17:29 +1000, Karl Auer <kauer at biplane.com.au> said:
>
>> 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."
> RFC 2181 section 7.2 clarifies that this advice should be ignored.
>
>> 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'm that guy :]
>
>> 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.
> RFC 2308, section 3
>
>    The TTL of this [SOA record in authority section of negative response]
>    record is set from the minimum of the MINIMUM field of the SOA record
>    and the TTL of the SOA itself, and indicates how long a resolver may
>    cache the negative answer. 
>
>> That said, a non-zero SOA TTL certainly seems to be common, perhaps the
>> norm.
> I don't think so.  This was an issue for the org zone as well (with
> further implications for DNSKEY records), see
> <https://lists.dns-oarc.net/pipermail/dns-operations/2009-June/thread.html#4018>
>> So to my questions:
>> - have I got totally and completely the wrong end of the stick here?
> My reading of the specs would suggest that.
>
>> - should I update my program to allow non-zero SOA TTLs?
>         
> Yes, unless I'm the one with the wrong end of the stick :)
>

-- 
Josh Littlefield                                  Cisco Systems, Inc.
joshl at cisco.com                             1414 Massachusetts Avenue
Phone: +1 978-936-0001                     Boxborough, MA  01719-2205