>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
My understanding is that the "extra" stuff wouldn't have any signature at all.
Wouldn't that break DNSSEC if the rest of the response had signatures? Or does
the DNSSEC-validation algorithm support "hybrid" responses like that?
- Ke
On 16/06/2016 15:57, Alan Clegg wrote:
> Change where it says: file "foo"; so that you don't have two zones with
> "foo".
You might keep the names but put them in different folders. That would
eventually be different filenames.
>
> AlanC
>
> On 6/16/16, 4:16 AM, "Daniel Dawalibi" on behalf of d
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
Change where it says: file "foo"; so that you don't have two zones with
"foo".
AlanC
On 6/16/16, 4:16 AM, "Daniel Dawalibi" wrote:
>Do you have the correct syntax to be adjusted on both views?
>
>-Original Message-
>From: bind-users-boun...@lists.isc.org
>[mailto:bind-users-boun...@lis
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
Darcy Kevin (FCA) wrote:
>
> It'll also, irrespective of caching, break DNSSEC.
No, extra stuff in the additional section should not break DNSSEC
because the signatures are per-RRset not per-message.
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode
Tyne, West Dogger: Varia
Do you have the correct syntax to be adjusted on both views?
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ray Bellis
Sent: 16 June, 2016 11:04 AM
To: bind-users@lists.isc.org
Subject: Re: writeable file 'domain.com': alrea
On 16/06/2016 09:01, Evan Hunt wrote:
> Use the "in-view" statement so that there's only one copy of the zone
> shared by both views.
Yes, or that, if they really are the same zone contents in both views.
Ray
___
Please visit https://lists.isc.org/ma
On 16/06/2016 07:53, Daniel Dawalibi wrote:
> We are upgrading our DNS authoritative BIND version 9.10.4-P1 but we are
> facing “writing errors” on the slave zone files that are transferred
> from other Master DNS servers.
>
> Our configuration consists of two views (local and inter) and the
> d
On Thu, Jun 16, 2016 at 09:53:14AM +0300, Daniel Dawalibi wrote:
> The problem was solved after removing the zone from one VIEW but is there
> any workaround for this issue without removing the zone from the view
> section (either Local or Inter)?
Use the "in-view" statement so that there's only
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
19 matches
Mail list logo
