DNS Negative Caching

[Harshith Mulky]

I have a confusion on how the clients respond to and cache when particularly we receive negative replies from a DNS Server, particularly NXDOMAIN or SERVFAIL responses

on the DNS Zone file we have these records
$ORIGIN e164.arpa.
@   IN     SOA  picardvm2.e164.arpa. e164-contacts.e164.arpa.  (
                                2002022404 ; serial
                                3H ; refresh
                                15 ; retry
                                1w ; expire
                                3h ; minimum
                               )

so 3h is basically the amount of time clients are asked to cache negative results.

Now on the client side at lwresd.conf, if I have

max-ncache-ttl 300

Will the client override the default 3h value sent as response from the DNS Sever for the zone e164.arpa


How are Negative responses usually cached?

Thanks
Harshith

[Reindl Harald]

Am 25.08.2015 um 12:46 schrieb Harshith Mulky:
> I have a confusion on how the clients respond to and cache when
> particularly we receive negative replies from a DNS Server, particularly
> NXDOMAIN or SERVFAIL responses
>
> on the DNS Zone file we have these records
> $ORIGIN e164.arpa.
> @ IN SOA picardvm2.e164.arpa. e164-contacts.e164.arpa. (
> 2002022404 ; serial
> 3H ; refresh
> 15 ; retry
> 1w ; expire

> *3h* ; minimum

> )
>
> so 3h is basically the amount of time clients are asked to cache
> negative results.
>
> Now on the client side at lwresd.conf, if I have
>
> max-ncache-ttl 300
>
> Will the client override the default 3h value sent as response from the
> DNS Sever for the zone e164.arpa

yes, that's the purpose of this setting

> How are Negative responses usually cached?

by TTL while in case of a SERVFAIL i am not sure if it get cached

[Kevin Oberman]

Only authoritative negative responses are cached. SERVFAILs are never authoritative, by definition.

--

Kevin Oberman, Network Engineer, Retired
E-mail: rkob...@gmail.com

PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

[Alan Clegg]

> on the DNS Zone file we have these records
> $ORIGIN e164.arpa.
> @ IN SOA picardvm2.e164.arpa. e164-contacts.e164.arpa. (
> 2002022404 ; serial
> 3H ; refresh
> 15 ; retry
> 1w ; expire
> *3h* ; minimum
> )

I wasn't really following this thread, but now that I see this, I would
like to add that the "expire" timer is also used as the default TTL for
resource records that do not have one specified, and if there is not an
explicit $TTL statement in the zone file.

Personally, I doubt that a 1 week TTL is a good idea.

AlanC
--
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.

[Reindl Harald]

Am 27.08.2015 um 16:08 schrieb Alan Clegg:
>> on the DNS Zone file we have these records
>> $ORIGIN e164.arpa.
>> @ IN SOA picardvm2.e164.arpa. e164-contacts.e164.arpa. (
>> 2002022404 ; serial
>> 3H ; refresh
>> 15 ; retry
>> 1w ; expire
>> *3h* ; minimum
>> )
>
> I wasn't really following this thread, but now that I see this, I would
> like to add that the "expire" timer is also used as the default TTL for
> resource records that do not have one specified, and if there is not an
> explicit $TTL statement in the zone file.
>
> Personally, I doubt that a 1 week TTL is a good idea

it is a damned good idea because it's the value after your slaves start
to drop zones in case of connection / zone-transfer troubles

a zone without an explicit $TTL statement is questionable to say it polite

[Alan Clegg]

On 8/27/15 10:24 AM, Reindl Harald wrote:

>> I wasn't really following this thread, but now that I see this, I would
>> like to add that the "expire" timer is also used as the default TTL for
>> resource records that do not have one specified, and if there is not an
>> explicit $TTL statement in the zone file.
>>
>> Personally, I doubt that a 1 week TTL is a good idea
>
> it is a damned good idea because it's the value after your slaves start
> to drop zones in case of connection / zone-transfer troubles

Oh, what a day... yes, the formatting of the zone snippet threw me.

Yes, EXPIRE should be long (and probably longer than 1w), it's the
MINIMUM (last value in the SOA RDATA) that I was meaning to point out.

Thanks for that..

> a zone without an explicit $TTL statement is questionable to say it polite

But, quite common IRL.

[Barry Margolin]

In article <mailman.2589.1440684...@lists.isc.org>,

Alan Clegg <al...@clegg.com> wrote:

> > on the DNS Zone file we have these records
> > $ORIGIN e164.arpa.
> > @ IN SOA picardvm2.e164.arpa. e164-contacts.e164.arpa. (
> > 2002022404 ; serial
> > 3H ; refresh
> > 15 ; retry
> > 1w ; expire
> > *3h* ; minimum
> > )
>
> I wasn't really following this thread, but now that I see this, I would
> like to add that the "expire" timer is also used as the default TTL for
> resource records that do not have one specified, and if there is not an
> explicit $TTL statement in the zone file.

Is that really still true? I thought that use of the Minimum field went
away when it was changed to be the negative cache TTL.

--
Barry Margolin
Arlington, MA

[Chris Buxton]

> Is that really still true? I thought that use of the Minimum field went
> away when it was changed to be the negative cache TTL.

Barry,

Yes, it’s still true. If you don’t set a default TTL, then the last field of the SOA record does double duty as both a default TTL and a negative caching TTL. And no RFC has ever updated its name.

Chris Buxton

[Darcy Kevin (FCA)]

What's in a name? :-)

RFC 2308 said that the use of the last field of the SOA to set negative-caching TTL is "the new defined meaning of the SOA minimum field". So you can *call* it "minimum", but it is *actually* supposed to function as something else...

Eventually I hope BIND will conform to the spirit of RFC 2308 and stop using the last field of the SOA to set the default TTL, as a "fallback" in scenarios where the file would otherwise be illegal (i.e. the first RR has no explicit TTL set, and there is no $TTL directive preceding it). RFC 2308 is so old, that if it were a person, it would be legal to buy cigarettes in some parts of the world. It's long past time for folks to get with the program.

- Kevin

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Barry Margolin]

In article <mailman.2601.1440783...@lists.isc.org>,

"Darcy Kevin (FCA)" <kevin...@fcagroup.com> wrote:

> What's in a name? :-)
>
> RFC 2308 said that the use of the last field of the SOA to set
> negative-caching TTL is "the new defined meaning of the SOA minimum field".
> So you can *call* it "minimum", but it is *actually* supposed to function as
> something else...
>
> Eventually I hope BIND will conform to the spirit of RFC 2308 and stop using
> the last field of the SOA to set the default TTL, as a "fallback" in
> scenarios where the file would otherwise be illegal (i.e. the first RR has no
> explicit TTL set, and there is no $TTL directive preceding it). RFC 2308 is
> so old, that if it were a person, it would be legal to buy cigarettes in some
> parts of the world. It's long past time for folks to get with the program.

Does the RFC specify some other default TTL if there's no $TTL
directive? If not, the software needs to do something, and using the old
method for compatibility is as good anything else (on the assumption
that anyone who didn't put $TTL in the file was depending on this use of
the SOA record).

[Matus UHLAR - fantomas]

On 28.08.15 17:32, Darcy Kevin (FCA) wrote:
>RFC 2308 said that the use of the last field of the SOA to set
> negative-caching TTL is "the new defined meaning of the SOA minimum
> field". So you can *call* it "minimum", but it is *actually* supposed to
> function as something else...
>
>Eventually I hope BIND will conform to the spirit of RFC 2308 and stop
> using the last field of the SOA to set the default TTL, as a "fallback" in
> scenarios where the file would otherwise be illegal (i.e. the first RR
> has no explicit TTL set, and there is no $TTL directive preceding it).
> RFC 2308 is so old, that if it were a person, it would be legal to buy
> cigarettes in some parts of the world. It's long past time for folks to
> get with the program.

what would you expect bind to do in such case, refuse the zone?
The "minimum" value is safe default in most cases.

Note that is only matters on masters, the XFER slaves see the ttl within
each record...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
One OS to rule them all, One OS to find them,
One OS to bring them all and into darkness bind them

[Darcy Kevin (FCA)]

Negative-caching TTL and regular TTL have little to do with each other; it's not a reasonable assumption that one should stand in as a default for the other. I know analogies are frequently dangerous, but to me, that's kind of like saying that the amount of time that normally elapses between replacing one's automobile with a newer vehicle, can be safely assumed to be equal to the amount of time one could go without an automobile at all. The two things are related, of course (in the analogy, they're both about automobiles), but it would be foolish to assume that one time interval is the same as the other. One pertains to the *existence* of something, that needs to be periodically refreshed; the other refers to the duration of an *absence* of something.

As you pointed out (correctly), this isn't an issue which affects anything that goes "on the wire", e.g. master-slave replication via AXFR/IXFR, since, "on the wire" the TTL is always included with the RR. It's only an issue for how the zone files are managed on the master.

My opinion: named on the master should reject illegal zone files.

Note that this is a non-issue if Dynamic Update is being used to manage zones (since then named writes out the zone file), or if a commercial-grade DNS management system is the thing that's generating the zone files (since they should all be compliant to RFC 2308 by now; if not, sue the manufacturer for a product defect). It's perhaps only an issue for some homebrew zonefile-creation scripts that were written a long time ago, and where the administrators have been systematically ignoring the "no TTL specified; using SOA MINTTL instead" errors in their logs, every time named loads or reloads the zones.

- Kevin

-----Original Message-----
From: bind-user...@lists.isc.org [mailto:bind-user...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas
Sent: Friday, August 28, 2015 3:49 PM
To: bind-...@lists.isc.org
Subject: Re: DNS Negative Caching

One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them _______________________________________________

[Barry Margolin]

In article <mailman.2604.1440796...@lists.isc.org>,

"Darcy Kevin (FCA)" <kevin...@fcagroup.com> wrote:

> Negative-caching TTL and regular TTL have little to do with each other; it's
> not a reasonable assumption that one should stand in as a default for the
> other.

True, but that's water long under the bridge.

Note that if a server is authoritative-only, caching is mostly
irrelevant, so the negative cache TTL doesn't much apply. In this case,
the SOA Minimum is just being used as the default TTL.

> My opinion: named on the master should reject illegal zone files.

As far as I can tell, nothing in RFC 2308 says that $TTL is required. I
don't even see a SHOULD, let alone a MUST. Is there a later RFC that
adds this requirement? If not, then a zone file without $TTL is legal.
And for backward compatibility, it should continue to use the SOA
Minimum field as the default TTL.

[Dave Warren]

On 2015-08-28 14:15, Darcy Kevin (FCA) wrote:
> As you pointed out (correctly), this isn't an issue which affects anything that goes "on the wire", e.g. master-slave replication via AXFR/IXFR, since, "on the wire" the TTL is always included with the RR. It's only an issue for how the zone files are managed on the master.
>

> My opinion: named on the master should reject illegal zone files.

Agreed. Could you please cite where in RFC 2308 $TTL is a MUST, or even
a SHOULD? Or was this made mandatory elsewhere?

RFC 2308 is clear on what should happen after a $TTL directive, but
seems silent on how to handle resource records prior to, or in the
absence of a $TTL directive, but it does note that the "minimum TTL"
field has traditionally had three uses:

First: as a minimum. Result? "is hereby deprecated"

Second: Result? No change in status.

Third: "The remaining of the current meanings, of being the TTL to be
used for negative responses, is the new defined meaning of the SOA
minimum field." -- This almost goes far enough to depreciate the second,
but given the explicit language depreciating the first, I would think
that the author would have used similar language had they intended to
depreciate the second.

The closest we get is section 4, "Where a server does not require RRs to
include the TTL value explicitly, it should provide a mechanism, not
being the value of the MINIMUM field of the SOA record, from which the
missing TTL values are obtained."

That's a "should" (not even a "SHOULD"), but in the absence of this
specified minimum (either by lack of implementation, or lack of
configuration), the SOA MINIMUM field would seem to be better than
failing outright.

> It's perhaps only an issue for some homebrew zonefile-creation scripts that were written a long time ago, and where the administrators have been systematically ignoring the "no TTL specified; using SOA MINTTL instead" errors in their logs, every time named loads or reloads the zones.

I'm not suggesting I'm going to start writing or recommending zone files
without a $TTL directive, or that this is even a big deal in the real
world, but I'm struggling to find a case where the absence of a $TTL
directive would result in a zone file being illegal, and so falling back
on the SOA's "minimum" field would seem to be a more sane choice than
making one up or refusing the zone, if only as a nod to the legacy use
of this field.

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

[Chris Buxton]

On Aug 28, 2015, at 5:27 PM, Barry Margolin <bar...@alum.mit.edu> wrote:

> Note that if a server is authoritative-only, caching is mostly
> irrelevant, so the negative cache TTL doesn't much apply. In this case,
> the SOA Minimum is just being used as the default TTL.

No, that is not correct. When responding negatively, the authoritative server uses the negative caching TTL (the Minimum field) as the TTL of the SOA record in the authority section.

Chris

[Rich Goodson]

I have a feeling that the discussion regarding SOA fields didn’t really answer your question, Harshith.

Yes, negative results (NXDOMAIN) are usually cached for the amount of time specified in the last field of the SOA. This field was originally named “Minimum”, but is since used for NXDOMAIN TTL.

The default amount of time that NXDOMAIN answers will be cached on iterative resolvers for the zone shown below is 3 hours.  

In your lwresd config file, however, you have man-ncache-ttl defined as 300 seconds.  I have not used lwresd much, but I know it supports BIND style config files, so I assume that  lwresd will override the value sent by the authoritative server and only cache NXDOMAIN answers for your zone for 5 minutes, just like BIND would do, given that same config directive.

You can test this behavior by doing ‘dig’ commands against your lightweight resolver to see what TTL it has cached for a particular zone or RR.

—Rich

On Aug 25, 2015, at 5:46 AM, Harshith Mulky <harshit...@outlook.com> wrote:

I have a confusion on how the clients respond to and cache when particularly we receive negative replies from a DNS Server, particularly NXDOMAIN or SERVFAIL responses

on the DNS Zone file we have these records
$ORIGIN e164.arpa.
@   IN     SOA  picardvm2.e164.arpa. e164-contacts.e164.arpa.  (
                                2002022404 ; serial
                                3H ; refresh
                                15 ; retry
                                1w ; expire

                                3h ; minimum

                               )

so 3h is basically the amount of time clients are asked to cache negative results.

Now on the client side at lwresd.conf, if I have 

max-ncache-ttl 300

Will the client override the default 3h value sent as response from the DNS Sever for the zone e164.arpa

How are Negative responses usually cached?

Thanks
Harshith