On 11/18/2011 11:48, Evan Hunt wrote:
>> Personally I have always thought that the perl script in contrib is
>> overly complex.
>>
>> #!/bin/sh
>>
>> while : ; do
>> /path/named -f
>> sleep 17
>> done
>
> That works, but note that it won't catch the problem if named hangs.
Right, but t
> Personally I have always thought that the perl script in contrib is
> overly complex.
>
> #!/bin/sh
>
> while : ; do
> /path/named -f
> sleep 17
> done
That works, but note that it won't catch the problem if named hangs.
Running it in xinetd works too, but same note.
--
Evan Hu
On 11/17/2011 13:24, Jeremy C. Reed wrote:
> Also what other types of nanny scripts do you use? (I already saw other
> emails with a few suggestions.)
Personally I have always thought that the perl script in contrib is
overly complex.
#!/bin/sh
while : ; do
/path/named -f
sleep
In message <5a89161c-702d-4093-af15-966cbc724...@cornell.edu>, John Wobus
writes:
> I assume ISC does not deliberately insert aborts
> triggerable by bad data in DNS queries and answers.
> Much more likel,y they do it when something happens
> that is supposed to be logically impossible whatever t
On 11/17/11 1:45 PM, "/dev/rob0" wrote:
> What I should perhaps do: separate the authoritative named instance
> from the recursive one on the mail server. I suppose BIND 10 does
> this, by design?
Yes, that is best practice (I keep reading it in docs from people I trust,
like Cricket Liu). I've
On Thursday 17 November 2011 15:24:12 Jeremy C. Reed wrote:
> Also what other types of nanny scripts do you use? (I already saw
> other emails with a few suggestions.)
Mine is a very trivial thing, basically just:
/sbin/pidof named || restartNamed
where "restartNamed" is a function to log the
On Wed, 16 Nov 2011, Phil Mayers wrote:
> It might be good if bind were able to re-start itself, rather than dying
> outright (e.g. re-exec the process) but that is dangerous too; it's better
> done by an unrelated supervising process.
In the bind9 tarball's contrib directory there is a simply "n
I assume ISC does not deliberately insert aborts
triggerable by bad data in DNS queries and answers.
Much more likel,y they do it when something happens
that is supposed to be logically impossible whatever the
incoming data, and implies continuing to run is
potentially insecure and/or will just cr
On 11/16/11 5:14 AM, "Phil Mayers" wrote:
> On 16/11/11 13:07, Warren Kumari wrote:
>> It was (very convincingly!) explained to me that INSISTS() are only
>> used for the "this should not happen" cases, and if the INSISTS()
>> were not there, many of the recent attacks may have led to much worse
>
On Wed, 16 Nov 2011, Lightner, Jeff wrote:
By "init script" do you mean a script running from inittab doing a respawn? When I see
"init script" I think of scripts run at shutdown and boot in /etc/init.d (or more
accurately in /etc/rc?.d run level directories linked to the scripts in init.d).
On Wed, 16 Nov 2011, David Ford wrote:
ISC have replied and indicated that BIND 10 was designed, with
resilience to abnormal events, in mind. i'm eagerly looking forward to
trying it out now.
i disagree that it's easier to find and fix. many people will simply
wrap it in a while(1) and ignore
ISC have replied and indicated that BIND 10 was designed, with
resilience to abnormal events, in mind. i'm eagerly looking forward to
trying it out now.
i disagree that it's easier to find and fix. many people will simply
wrap it in a while(1) and ignore it because we don't have the time to
sit
On Wed, 16 Nov 2011, Stephane Bortzmeyer wrote:
From the reports on this mailing list, it seems there is a new
vulnerability in BIND, actively exploited in the wild. I suggest that
you send a detailed bug report (with the actual log) to ISC
I have not heard this is actually "exploited" versus
sage-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Paul
Wouters
Sent: Wednesday, November 16, 2011 11:48 AM
To: David Ford
Cc: bind-users@lists.isc.org
Subject: Re: bind-9.8.1: INSIST(! dns_rdataset _isas
On Wed, 16 Nov 2011, David Ford wrote:
can we have a paradigm shift from ISC please? instead of falling over
dead with insist/assert, please bleat a warning and drop the problematic
issue on the floor instead and press on with business. many BIND DoS
attacks (and zone typos) are very effective
On Wednesday 16 November 2011 07:21:12 Will Lists wrote:
> Just for for my own knowledge, as I haven't had the issue (yet),
> what log would this error appear in?
This will of course vary by OS. I haven't had it yet either, but I
would expect to see (by default) a daemon.{err,crit,alert} message
Ah, never mind that last question. Brain hadn't been put in gear yet. :-)
-Will
On Wed, Nov 16, 2011 at 7:21 AM, Will Lists wrote:
> Just for for my own knowledge, as I haven't had the issue (yet), what log
> would this error appear in?
>
> Thanks.
>
> -Will
>
>
>
> On Wed, Nov 16, 2011 at 7
Just for for my own knowledge, as I haven't had the issue (yet), what log
would this error appear in?
Thanks.
-Will
On Wed, Nov 16, 2011 at 7:18 AM, Evan Hunt wrote:
>
> > can we have a paradigm shift from ISC please? instead of falling over
> > dead with insist/assert, please bleat a warni
> can we have a paradigm shift from ISC please? instead of falling over
> dead with insist/assert, please bleat a warning and drop the problematic
> issue on the floor instead and press on with business. many BIND DoS
> attacks (and zone typos) are very effective for just this reason.
This is i
On 16/11/11 13:07, Warren Kumari wrote:
It was (very convincingly!) explained to me that INSISTS() are only
used for the "this should not happen" cases, and if the INSISTS()
were not there, many of the recent attacks may have led to much worse
things like buffer overflows / more worrying securit
On Nov 16, 2011, at 8:35 PM, David Ford wrote:
> can we have a paradigm shift from ISC please? instead of falling over
> dead with insist/assert, please bleat a warning and drop the problematic
> issue on the floor instead and press on with business. many BIND DoS
> attacks (and zone typos) are
On 11/16/2011 01:35 PM, David Ford wrote:
> can we have a paradigm shift from ISC please? instead of falling over
> dead with insist/assert, please bleat a warning and drop the problematic
> issue on the floor instead and press on with business. many BIND DoS
> attacks (and zone typos) are very e
can we have a paradigm shift from ISC please? instead of falling over
dead with insist/assert, please bleat a warning and drop the problematic
issue on the floor instead and press on with business. many BIND DoS
attacks (and zone typos) are very effective for just this reason.
:)
__
> To my surprise, I had several DNS servers running BIND 9.8.1 all fail
> at about the same time with this assertion failure in query.c, on line
> 1895.
Have you compiled BIND from the original ISC sources, or do you use a
distribution version?
--
Florian Weimer
BFK edv-consultin
On Tue, Nov 15, 2011 at 11:30:19PM -0800,
nicku wrote
a message of 5 lines which said:
> To my surprise, I had several DNS servers running BIND 9.8.1 all
> fail at about the same time with this assertion failure in query.c,
> on line 1895.
>From the reports on this mailing list, it seems ther
To my surprise, I had several DNS servers running BIND 9.8.1 all fail
at about the same time with this assertion failure in query.c, on line
1895. The only references I have found to this were from
CVE-2009-0696 Dynamic Update DoS attack, which 9.8.1 surely should be
immune to. Any suggestions as
26 matches
Mail list logo
