zero SOA TTL - still best practice?

Kevin Oberman oberman at es.net
Thu Aug 26 17:23:44 UTC 2010


It makes the tread hard to follow
> Why not?
> > Please don't top post!

> 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 :)
> >
> Date: Thu, 26 Aug 2010 11:23:00 -0400
> From: Josh Littlefield <joshl at cisco.com>
> Sender: bind-users-bounces+oberman=es.net at lists.isc.org
> 
>  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).

I really question the desirability of a negative cache TTL of days. If
something is not in DNS when it is first queried for, it will be
negatively cached and will stay that way for a very long time. It is not
unheard of for some information on a new web page to be leaked (at least
internally) prior to the insertion of the record into DNS. An
excessively long negative cache time will keep it unavailable for fat
too long.

I remember discussions in the DNSEXT WG back when negative caching was
fist implemented as to whether the negative cache time should be limited
and, if so, to how many MINUTES.

The purpose of the negative cache is to keep servers from being
continually beaten on and reducing queries from some broken piece of
software from hundreds of queries/second to 4 or 5 per minute. (And
there were and probably are things still making hundreds of
queries/second because some resolvers are badly broken.) Making it
hours or days long will do little to off-load the root, ccTLD, gTLD, or
any other servers while increasing the opportunity to shoot oneself in
the foot. This has little or no link to how often your data changes
(unless you are very confident that new entries will never be made.

Note! This is not an argument for a short SOA TTL, but for a short
minimum TTL in the SOA.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



More information about the bind-users mailing list