Zitat von Marek Sebera via Unbound-users :
Hi,
I'm glad at least somebody finds this project useful.
I also find it very useful because DNSSEC should be integrated per
Device to be useful/secure IMHO. I hope that someday (soon) a
validating resolver will be the default for Android, at l
On 21 Aug 2015, at 9:49, Andi via Unbound-users wrote:
> I also find it very useful because DNSSEC should be integrated per Device to
> be useful/secure IMHO.
I must say I disagree with the statement, because it sounds like if usefulness
of DNSSEC is black and white, yes or no. And that it is u
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
OpenBSD with unbound 1.5.2.
I noticed that for some domains, the cache TTL for NXDOMAIN results
seemed to be shared for all nonexistant rep
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
11 matches
Mail list logo
