Hello all,
Are they any thoughts around, how to handle yesterday's glibc
vulnerability[1][2] from the side bind?
Since it is a rather painful task in order to update all hosts to a new
version of glibc, we were thinking about other possible workarounds.
Any ideas how to drop non-compliant respo
Am 17.02.2016 um 17:22 schrieb Dominique Jullier:
Are they any thoughts around, how to handle yesterday's glibc
vulnerability[1][2] from the side bind?
Since it is a rather painful task in order to update all hosts to a new
version of glibc, we were thinking about other possible workarounds
On 2/17/16, 11:34 AM, "Reindl Harald" wrote:
>Am 17.02.2016 um 17:22 schrieb Dominique Jullier:
>> Are they any thoughts around, how to handle yesterday's glibc
>> vulnerability[1][2] from the side bind?
>>
>> Since it is a rather painful task in order to update all hosts to a new
>> version of g
I agree with Reindl, but (at the risk of this sounding bad) it also underscores
why it is important to proactive in management of risk and change.
If you don't know what you don't know that is very risky behavior. If there is
a collective freak out on what to do to get something fixed regardles
Cyber folks asked if there was any way for the DNS servers to "protect" the
vulnerable clients.
The only thing i could see from the explanation was disabling or limiting
edns0 sizes. That is obviously not a long term option.
On Feb 17, 2016 11:39 AM, "Alan Clegg" wrote:
> On 2/17/16, 11:34 AM,
Hello Darcy and other posters
- Original Message -
From: "Darcy Kevin (FCA)"
To:
Sent: Tuesday, February 16, 2016 1:42 AM
Subject: RE: Zone hints for VPN environments
Note that there are additional considerations if there are any descendant
(child, grandchild, etc.) zones of intra.
Hi there,
On Wed, 17 Feb 2016, Dominique Jullier wrote:
Are they any thoughts around, how to handle yesterday's glibc
vulnerability[1][2] from the side bind?
This is a glibc issue, not a bind issue. It makes no sense to attempt
to fix the problem by modifying bind. Firstly, bind is not the
* Ben Croswell:
> Cyber folks asked if there was any way for the DNS servers to "protect" the
> vulnerable clients.
> The only thing i could see from the explanation was disabling or limiting
> edns0 sizes. That is obviously not a long term option.
EDNS0 buffer sizes do not apply to TCP respons
* Alan Clegg:
> While I agree that the "major distributions" (and even the minor ones) are
> getting patches out, I'd like to point out something that Alan Cox posted
> over on G+:
>
> "You can upgrade all your servers but if that little cheapo plastic box on
> your network somewhere has a vulnera
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?
I know you can dump it with rndc but can you load it back ?
--
William Taylor
Senior Systems Engineer
http://sonic.com
707.522.1000 ext 2276
_
On Wed, Feb 17, 2016 at 11:31:54AM -0800, 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?
> I know you can dump it with rndc but can you load it back ?
It used to be possible to load the cac
> 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?
> I know you can dump it with rndc but can you load it back ?
Technically yes, but the option that can do it was only implemented for
testing purposes. Using it in
On Wed, Feb 17, 2016 at 11:31:54AM -0800, 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?
> I know you can dump it with rndc but can you load it back ?
One way to achieve this is to have two
In message <87io1nrw2k@mid.deneb.enyo.de>, Florian Weimer writes:
> * Alan Clegg:
>
> > While I agree that the "major distributions" (and even the minor ones) are
> > getting patches out, I'd like to point out something that Alan Cox posted
> > over on G+:
> >
> > "You can upgrade all your se
* Mark Andrews:
> And the best way to deal with this is to have manufacturers update
> https://www.kb.cert.org/vuls/id/457759 with their status. Yes it
> should be a much bigger list than what is there. Every IoT vendor.
> Every router vendor. Every OS vendor. Yes, ISC needs to put in a
> offi
15 matches
Mail list logo