Please also note that the below test is successful with a prefetch value of 0.
To me this really looks like prefetching forgets to update RRSIGs.
Thomas
> On 06.07.2016, at 15:29, Thomas Sturm wrote:
>
> Hi Mark,
>
> I may have found another (possibly related?) bug:
>
> I noticed that when
Hi Mark,
I may have found another (possibly related?) bug:
I noticed that when validating a signed zone using delv by querying a local
BIND caching server (v9.10.3-P4), it sometimes suddenly alerts "no valid
RRSIG”. Indeed, when querying “dig ds mydomain +dnssec", it returns the DS
records, bu
nged handling of "just expiring" records in
9.10.4 [RT #41687].
Brgds,
Ondrej
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Andrews
Sent: Monday, June 20, 2016 8:39 AM
To: Thomas Sturm
Cc: bind-us...@isc.or
A fix for this is in review and should be in the next maintainance
release.
Mark
In message <16a2cdfd-694d-444a-a760-17c9d7517...@open.ch>, Thomas Sturm writes:
>
> I am now able to reliably reproduce the behaviour with dig querying BIND
> 9.10.4-P1 (not 9.9, apparently) with "prefetch 0â:
>
>
, June 16, 2016 11:58 PM
To: Phil Mayers; Daniel Stirnimann; bind-users@lists.isc.org
Subject: RE: Issues resolving outlook.office365.com
>These were being blamed on "the network".
Nothing can be blamed on the network without a client pcap. Otherwise it is
just a bunch of hand wavi
>These were being blamed on "the network".
Nothing can be blamed on the network without a client pcap. Otherwise it is
just a bunch of hand waving and hot air. Show me the money.
;)
John
___
Please visit https://lists.isc.org/mailman/listinfo/bind-u
I am now able to reliably reproduce the behaviour with dig querying BIND
9.10.4-P1 (not 9.9, apparently) with "prefetch 0”:
$ while true; do dig outlook.office365.com +noauthority +noadditional +tries=1
+retry=0; sleep 0.1; done
Wait for 5 minutes, once the TTL expires, this should show about 5
On 16/06/16 13:01, Tony Finch wrote:
Phil Mayers wrote:
For what it's worth, I've been aggressively monitoring DNS resolution of
outlook.office365.com from all four of our recursives, both A & , once a
minute for the past 3 months.
I wonder if you would notice more problems if your query
On 16/06/16 13:09, Thomas Sturm wrote:
- with "prefetch 0” I am able to reproduce it every single time the TTL
expires, even on quiet dev hosts
- with “prefetch 2” I am able to reproduce it on loaded hosts only
- with “prefetch 10” I am NOT able to reproduce it at all
Hmm.
I thought prefetch
> If you're running bind 9.10, then bind 9.10 doing prefetch is a normal
> use-case.
>
> You make a good point that a prefetch-enabled resolver might show different
> behaviour to a non-prefetch one. But we've been on prefetch-enabled resolvers
> for the whole length of our o365 rollout IIRC,
On 16/06/16 13:01, Daniel Stirnimann wrote:
(This was as part of "proving" that various O365 issues were client
side, not network-triggered)
If a resolver cannot resolve outlook.office365.com why should this be a
client side issue? Or do you mean the resolver is the client for
upstream queries?
On 16/06/16 12:58, Reindl Harald wrote:
hence you can't compare it with normal usecases since bind 9.10 does
prefetch which mask any upstream problem, especially TTL when you query
it all the time
If you're running bind 9.10, then bind 9.10 doing prefetch is a normal
use-case.
You make a go
Phil Mayers wrote:
>
> For what it's worth, I've been aggressively monitoring DNS resolution of
> outlook.office365.com from all four of our recursives, both A & , once a
> minute for the past 3 months.
I wonder if you would notice more problems if your query interval is
greater than the TTL.
On 16/06/16 12:15, Tony Finch wrote:
Thomas Sturm wrote:
We are experiencing strange intermittent issues when resolving
outlook.office365.com, but also with other domains like e.g.
amazonaws.com or snort.org.
Based on recent discussions on the mailop list
For what it's worth, I've been agg
Thomas Sturm wrote:
>
> We are experiencing strange intermittent issues when resolving
> outlook.office365.com, but also with other domains like e.g.
> amazonaws.com or snort.org.
Based on recent discussions on the mailop list
(https://chilli.nosignal.org/mailman/listinfo/mailop)
the problem seem
Hi,
We are experiencing strange intermittent issues when resolving
outlook.office365.com, but also with other domains like e.g. amazonaws.com or
snort.org. But let’s choose office365.com as example for now.
outlook.office365.com is a CNAME to lb.geo.office365.com, and office365.com
delegates t
16 matches
Mail list logo
