Hi, Patrik -
> which also suspiciously seems to use the SOA TTL of 7200
> rather than the NXDOMAIN TTL of 18000
That is how negative cache TTL is calculated (by authoritative server).
RFC2308 reads:
(Negative cache) TTL is taken from the minimum of the SOA.MINIMUM field
and SOA's TTL.
Rega
Patrik Lundin via Unbound-users wrote:
>
> The first lookup (which also suspiciously seems to use the SOA TTL of 7200
> rather than the NXDOMAIN TTL of 18000):
RFC 2308 section 5
Like normal answers negative answers have a time to live (TTL). As
there is no record in the answer section to
Hi Patrik,
Yes I can confirm that unbound have a "domain wide" NXD caching. As long as the
returned TTL for your second query is lower than the max TTL for the record
this (IMHO) is not a violation of RFC2308. However there are domains out there
that return a higher TTL for EMPTY NOERROR vs NXD
On Fri, Aug 21, 2015 at 04:32:33PM +0100, Tony Finch wrote:
>
> RFC 2308 section 5
>
>Like normal answers negative answers have a time to live (TTL). As
>there is no record in the answer section to which this TTL can be
>applied, the TTL must be carried by another method. This is do
On Fri, Aug 21, 2015 at 03:40:14PM +, Stephan Lagerholm wrote:
>
> Yes I can confirm that unbound have a "domain wide" NXD caching. As
> long as the returned TTL for your second query is lower than the max
> TTL for the record this (IMHO) is not a violation of RFC2308.
>
Interesting... Is it
On Fri, Aug 21, 2015 at 08:16:03PM +0200, Patrik Lundin via Unbound-users wrote:
>
> It was interesting to hear that the 600 came from the NXDOMAIN response
> for the equivalent lookup of nonexistant1.google.com.
>
Correction: the TTL of 600 comes from the NOERROR result from looking up AAA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Patrik,
On 08/21/2015 05:14 PM, Patrik Lundin via Unbound-users wrote:
> Hello,
>
> I recently noticed what to me is a strange caching behaviour for
> NXDOMAIN results.
>
> This has been seen both on Ubuntu 14.04 with unbound 1.4.22 and on
> Op
On Fri, Aug 21, 2015 at 11:13:34PM +0200, Wouter Wijngaards via Unbound-users
wrote:
>
> This is because the RRset cache is shared between answers. The SOA
> record is in that cache. When you query the second time, unbound
> detects that the SOA record has not changed, and therefore keeps
> tim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Patrik,
On 22/08/15 07:27, Patrik Lundin wrote:
> On Fri, Aug 21, 2015 at 11:13:34PM +0200, Wouter Wijngaards via
> Unbound-users wrote:
>>
>> This is because the RRset cache is shared between answers. The
>> SOA record is in that cache. When
