RE: DNS Negative Caching (Harshith)

[Harshith Mulky]

I thank you all for providing me such valuable information on DNS Negative 
Caching
I would have never thought that so many things would be Applied in deciding 
what would be cached

I once again thank each one of you and appreciate for the time and valuable 
feedback

Cheers
Harshith

> From: bind-users-requ...@lists.isc.org
> Subject: bind-users Digest, Vol 2189, Issue 1
> To: bind-users@lists.isc.org
> Date: Tue, 1 Sep 2015 12:00:01 +
> 
> Send bind-users mailing list submissions to
>   bind-users@lists.isc.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
>   bind-users-requ...@lists.isc.org
> 
> You can reach the person managing the list at
>   bind-users-ow...@lists.isc.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bind-users digest..."
> 
> 
> Today's Topics:
> 
>1. Re: DNS Negative Caching (Chris Buxton)
>2. How does named log update request (liumingxing)
>3. Re: DNS Negative Caching (Rich Goodson)
>4. Re: DNSSEC ZSK rollover (Tony Finch)
>5. Re: How does named log update request (Tony Finch)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 31 Aug 2015 07:19:33 -0700
> From: Chris Buxton <cli...@buxtonfamily.us>
> To: Barry Margolin <bar...@alum.mit.edu>
> Cc: comp-protocols-dns-b...@isc.org
> Subject: Re: DNS Negative Caching
> Message-ID: <9ca7db5c-6e06-4ec8-a216-16a926cba...@buxtonfamily.us>
> Content-Type: text/plain; charset=us-ascii
> 
> 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
> 
> --
> 
> Message: 2
> Date: Mon, 31 Aug 2015 22:36:30 +0800
> From: liumingxing <liumingx...@cnnic.cn>
> To: bind-users <bind-users@lists.isc.org>
> Subject: How does named log update request
> Message-ID: <2015083122362973447...@cnnic.cn>
> Content-Type: text/plain; charset="gb2312"
> 
> hi,
> In my server, I found update need longer time, So I want to check why by 
> checking logs.
>   As we know, named Logging of all dynamic update transactions. In the update 
> channel file, how I can know when the server receives update request?
> 
> 
> 
> 
> 
> 
> Mingxing, Liu
>  
> mail?liumingx...@cnnic.cn
> tel??010?58812467
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <https://lists.isc.org/pipermail/bind-users/attachments/20150831/a9041efe/attachment-0001.html>
> 
> --
> 
> Message: 3
> Date: Mon, 31 Aug 2015 10:23:54 -0500
> From: Rich Goodson <rgood...@gronkulator.com>
> To: Harshith Mulky <harshith.mu...@outlook.com>
> Cc: "bind-users@lists.isc.org" <bind-users@lists.isc.org>
> Subject: Re: DNS Negative Caching
> Message-ID: <a997d9bc-0788-4e98-a35a-59194c2f0...@gronkulator.com>
> Content-Type: text/plain; charset="windows-1252"
> 
> 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 <harshith.mu...@outlook.com> 
> > wrote:
&

Re: DNS Negative Caching

[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  
> 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
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users 
>  to unsubscribe from this 
> list
> 
> bind-users mailing list
> bind-users@lists.isc.org 
> https://lists.isc.org/mailman/listinfo/bind-users 
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[Chris Buxton]

On Aug 28, 2015, at 5:27 PM, Barry Margolin  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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[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


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

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

RE: DNS Negative Caching

[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-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas
Sent: Friday, August 28, 2015 3:49 PM
To: bind-users@lists.isc.org
Subject: Re: DNS Negative Caching

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 ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

Re: DNS Negative Caching

[Barry Margolin]

In article mailman.2601.1440783131.26362.bind-us...@lists.isc.org,
 Darcy Kevin (FCA) kevin.da...@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).

-- 
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[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 
___

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

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

Re: DNS Negative Caching

[Barry Margolin]

In article mailman.2604.1440796547.26362.bind-us...@lists.isc.org,
 Darcy Kevin (FCA) kevin.da...@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.

-- 
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[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



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[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.



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[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.

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.



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[Barry Margolin]

In article mailman.2589.1440684547.26362.bind-us...@lists.isc.org,
 Alan Clegg a...@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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[Kevin Oberman]

On Tue, Aug 25, 2015 at 12:50 AM, Reindl Harald h.rei...@thelounge.net
wrote:



 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


Only authoritative negative responses are cached. SERVFAILs are never
authoritative, by definition.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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
  ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS Negative Caching

[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




signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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