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 <201602181942.u1ijgrkf001...@dolphin.adi.com>, Thomas Schulz writes:
> A recommended way to set up a ZSK rollover is to set the inactive date of
> the current key one month later than the publish date of the replacement key.
> This makes sense as the RRSIG records are created to last on
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
Ah, so "recursive-clients" is the quota of queries that require named to
recurse to get the answer, right? I was going to respond with the same advice
-- slave your internal zones -- but then I somehow convinced myself that
"recursive-clients" was merely the quota of concurrent RD=1 queries that
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
In message <20160218185957.ga2...@mycre.ws>, Robert Edmonds writes:
> Tony Finch wrote:
> > Tony Finch wrote:
> > >
> > > Funnily enough I recently wrote a tool to do this but I have been failing
> > > to publish a blog article about it... Have a look at this:
> > > https://git.csx.cam.ac.uk/x/uc
A recommended way to set up a ZSK rollover is to set the inactive date of
the current key one month later than the publish date of the replacement key.
This makes sense as the RRSIG records are created to last one month from
their creation date.
Now if I try to speed up the ZSK rollover to make the
> On 18 Feb 2016, at 18:59, Robert Edmonds wrote:
>
> A large proportion of records are only ever used "once, or a handful of
> times", according to researchers: [...]
Yes, and there's an amazing amount of crap in the cache too. About 14% of our
cache is weird Sonicwall geoip records, which a
Tony Finch wrote:
> Tony Finch wrote:
> >
> > Funnily enough I recently wrote a tool to do this but I have been failing
> > to publish a blog article about it... Have a look at this:
> > https://git.csx.cam.ac.uk/x/ucs/ipreg/adns-masterfile.git
>
> Longer blurb now published at: http://fanf.livej
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
Tony Finch wrote:
>
> Funnily enough I recently wrote a tool to do this but I have been failing
> to publish a blog article about it... Have a look at this:
> https://git.csx.cam.ac.uk/x/ucs/ipreg/adns-masterfile.git
Longer blurb now published at: http://fanf.livejournal.com/141030.html
Tony.
--
William Taylor wrote:
> Is there anyway to pre-heat the cache in bind on startup besides having
> a custom script that did a bunch of queries on top hosts?
Funnily enough I recently wrote a tool to do this but I have been failing
to publish a blog article about it... Have a look at this:
https:/
19 matches
Mail list logo
