Grant Taylor wrote:
>
> Is there anything that the networking team can do to help alleviate some of
> the pain? I.e. make sure that equipment returns no route to host error
> messages? Will this make named abort queries before they would otherwise
> timeout?
Dunno :-)
One of the outages we had
On 02/18/2016 07:05 PM, Tony Finch wrote:
Yep, mostly waiting for replies that will never come, which doesn't
require much CPU.
Is there anything that the networking team can do to help alleviate some
of the pain? I.e. make sure that equipment returns no route to host
error messages? Will t
On 2016-02-18 18:19, John Miller wrote:
Something I just thought of: how did you manage your NS records in
this situation? To get NOTIFY/IXFR to work properly, either you have
to list every one of your recursive servers in your local NS records
or you have to do an also-notify block on the maste
In message
, John
Miller writes:
> >> I was going to respond with the same advice --
> >> slave your internal zones -- but then I somehow convinced myself that
> >> "recurs
> >> ive-clients" was merely the quota of concurrent RD=1 queries that named
> >> would
> >> handle, thus slaving wouldn
In message
, John
Miller writes:
> On Thu, Feb 18, 2016 at 5:06 PM, Mark Andrews wrote:
> > For some reason people are afraid to slave internal zones. Back
> > when I was working for CSIRO I used to slave all the internal zones
> > for all of the sites the division had. Each site administered
>> I was going to respond with the same advice --
>> slave your internal zones -- but then I somehow convinced myself that "recurs
>> ive-clients" was merely the quota of concurrent RD=1 queries that named would
>> handle, thus slaving wouldn't help in a network-outage situation, since name
>> d w
John Miller wrote:
> Thanks for the reply, Tony. With the recent glibc bug, I figured most
> folks would be off putting out those fires!
If they haven't done it by now then, gosh, I feel sorry for them.
(It's SO NICE to have a redundant service that you can patch and upgrade
without affecting u
On Thu, Feb 18, 2016 at 5:06 PM, Mark Andrews wrote:
> For some reason people are afraid to slave internal zones. Back
> when I was working for CSIRO I used to slave all the internal zones
> for all of the sites the division had. Each site administered its
> own zones but all sites slaved all of
On 2016-02-18 14:06, Mark Andrews wrote:
For some reason people are afraid to slave internal zones. Back
when I was working for CSIRO I used to slave all the internal zones
for all of the sites the division had. Each site administered its
own zones but all sites slaved all of them. That way lo
In message <686c619a5c4e4bcabdc6cfaf1e27d...@mxph4chrw.fgremc.it>, "Darcy Kevin
(FCA)" writes:
> Ah, so "recursive-clients" is the quota of queries that require named to recu
> rse to get the answer, right?
Yes.
> I was going to respond with the same advice --
> slave your internal zones -- bu
sday, February 18, 2016 4:08 PM
To: John Miller
Cc: Bind Users Mailing List
Subject: Re: Tuning for lots of SERVFAIL responses
In message
, John Miller writes:
> A couple of weeks ago, we experienced an outage on our external
> Internet links. Ideally, this shouldn't affect queries for
In message
, John Miller writes:
> A couple of weeks ago, we experienced an outage on our external
> Internet links. Ideally, this shouldn't affect queries for internal
> resources - we expect those queries to continue to be answered.
>
> That being said, we saw a bunch of messages in our logs
Thanks for the reply, Tony. With the recent glibc bug, I figured most
folks would be off putting out those fires!
On Thu, Feb 18, 2016 at 3:04 PM, Tony Finch wrote:
> John Miller wrote:
>
>> A couple of weeks ago, we experienced an outage on our external
>> Internet links. Ideally, this shouldn
John Miller wrote:
> A couple of weeks ago, we experienced an outage on our external
> Internet links. Ideally, this shouldn't affect queries for internal
> resources - we expect those queries to continue to be answered.
We've had a few connectivity losses over the last year due to floods and
D
A couple of weeks ago, we experienced an outage on our external
Internet links. Ideally, this shouldn't affect queries for internal
resources - we expect those queries to continue to be answered.
That being said, we saw a bunch of messages in our logs such as:
client 192.168.1.2#56075: no more r
15 matches
Mail list logo