Re: Query zone expiration time

On Nov 17, 2011, at 6:11 AM, Hajducko, Steven wrote: > Is there a way to query a slave to determine how much time is left before its > zones expire in a situation where the master has died? Erm, I believe you can look at the mtime on the file and add the expire time to determine when it will "

Re: Query zone expiration time

On 11/16/11 10:20 PM, "Hajducko, Steven" wrote: > We're actually going to move the zones to our Infoblox system, which is why we > wanted to determine if we had enough time or if we had to bother with the > recovery, hence the question. Perhaps you want `dig @ soa +multiline`. -- By nature, me

Re: Query zone expiration time

On Nov 16, 2011, at 10:20 PM, Hajducko, Steven wrote: > Yeah, that's if we wanted to bother recovering it. :) Then there is the > process of recovering the master conf file and setting up notifies and allows > for all the slaves the old master had. Hmm. If you don't care about recovering the z

RE: Query zone expiration time

Yeah, that's if we wanted to bother recovering it. :) Then there is the process of recovering the master conf file and setting up notifies and allows for all the slaves the old master had. We're actually going to move the zones to our Infoblox system, which is why we wanted to determine if we

Re: Can't compile bind 9.8.1-P1 on Solaris

With great help I got Bind 9.8.1 to compile on solaris but I can not get Bind to start up. I am getting: 17-Nov-2011 00:31:23.609 initializing DST: openssl failure 17-Nov-2011 00:31:23.609 exiting (due to fatal error) Is anyone else seeing this? -- Hal King - h...@utk.edu Systems Administrato

Re: Can't compile bind 9.8.1-P1 on Solaris

> Using ./configure [ ... ] --without-dlopen [ ... ] got it to compile > and install, which is fine for me, but what should I do if I needed > DLZ support? Removing "dlzexternal" from SUBDIRS in bin/tests/system/Makefile ought to do it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, I

Re: Can't compile bind 9.8.1-P1 on Solaris

On Wednesday 16 November 2011 19:30:55 Evan Hunt wrote: > > I get an error compiling Bind at: > > > > make[4]: Entering directory > > `/usr/local/src/bind-9.8.1-P1/bin/tests/system/dlzexternal' ld > > -G -z text -o driver.so driver.o > > ld: invalid number `-z' > > > > Giving ?G a number makes ?z

Re: Query zone expiration time

On 11/16/2011 5:11 PM, Hajducko, Steven wrote: > We had a master die and we’ve been meaning to move it off to a newer > system. We’re trying to determine how much time is left on the zones in > order to see if we can do it right or if we have to quickly recover the > master. Change the "type sla

Re: turning off gssapi in 9.8.1

> I notice that 9.8.1 ships with > --with-gssapi > on by default. > > If I turn that off, what functionality do I lose? GSS/TSIG authentication, which lets you interoperate with Active Directory servers. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc.

Re: Can't compile bind 9.8.1-P1 on Solaris

> I compiled 9.8.1 on the same server with the same setup. So it is not in > 9.8.1. > I can not reproduce the problem. Can you try with Sun Studio 11 or 12 and then see what you get? You know, it would not be the ffirst time that old GCC on Solaris 10 failed me. If I need GCC, and I often do, I

Re: Can't compile bind 9.8.1-P1 on Solaris

I compiled 9.8.1 on the same server with the same setup. So it is not in 9.8.1. -- Hal King - h...@utk.edu Systems Administrator Office of Information Technology Systems: Business Information Systems The University of Tennessee 135D Kingston Pike Building 2309 Kingston Pk. Knoxville, TN 37996

turning off gssapi in 9.8.1

I notice that 9.8.1 ships with --with-gssapi on by default. If I turn that off, what functionality do I lose? Thanks. -- Jack Tavares "How many more can we sell with this button?" ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to un

Re: Can't compile bind 9.8.1-P1 on Solaris

> >> I get an error compiling Bind at: >> >> make[4]: Entering directory >> `/usr/local/src/bind-9.8.1-P1/bin/tests/system/dlzexternal' >> ld -G -z text -o driver.so driver.o >> ld: invalid number `-z' >> >> Giving ?G a number makes ?z unrecognized. >> >> I'm in Solaris 10, Sparc, GCC 3.4.6 > > Th

Re: Can't compile bind 9.8.1-P1 on Solaris

> I get an error compiling Bind at: > > make[4]: Entering directory > `/usr/local/src/bind-9.8.1-P1/bin/tests/system/dlzexternal' > ld -G -z text -o driver.so driver.o > ld: invalid number `-z' > > Giving ?G a number makes ?z unrecognized. > > I'm in Solaris 10, Sparc, GCC 3.4.6 Thanks for th

Re: trigger point for new bug

On 11/16/11 12:31 PM, Paul Wouters wrote: Is disabling DNSSEC validation a workaround? We do not believe it would be effective. Michael McNally ISC Support ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this

Re: Turning log on bind for troubleshooting

Thanks! It was not my original intent, it got paste there somehow. Anyway, that has been corrected yesterday! > I'm afraid there's much more for you to read, try searching for some DNS > howto's On 11/16/11 1:03 PM, Matus UHLAR - fantomas wrote: On 15.11.11 14:16, Eduardo Bonsi wrote: I alrea

Re: Can't compile bind 9.8.1-P1 on Solaris

> Thanks! > Everything here is looking fine on Solaris. No issues with the build at all. However, again, I am using Sun Studio 11 on Solaris 8 and not GCC that comes with Sol 10. I have moved on from 32-bit builds to 64-bit and then the packages will come along soon. Dennis -- -- http://pgp.

Re: trigger point for new bug

On 11/16/11 2:35 PM, "Michael McNally" wrote: > On 11/16/11 1:22 PM, michoski wrote: >> Short time ago I grabbed the latest tarball from your download site, and >> generated internal packages. I could have sworn that was 9.8.1-P4 (our >> internal packages still have the P4, and Google finds some

Re: trigger point for new bug

On 11/16/11 1:22 PM, michoski wrote: Short time ago I grabbed the latest tarball from your download site, and generated internal packages. I could have sworn that was 9.8.1-P4 (our internal packages still have the P4, and Google finds some hits): Perhaps it was 9.8.0-P4? Many of our version

"Scavenging" DDNS records

(I am going to post this individually to both the BIND and DHCP lists as this crosses both, but not going to cross-post). DHCPD 4.1-ESV-R3 & BIND 9.7.4 We've got about 20 /20 networks and another few /24 networks (all within the 10/8 block) that are setup for approximately 50% of their total ran

Re: trigger point for new bug

On 11/16/11 1:20 PM, "Michael McNally" wrote: > According to our best current understanding of the issue: > > + Authoritative-only nameservers should be safe and only > recursing servers at risk. > > + From the security advisory we have posted on our website: > ( http://www.isc.org/sof

Query zone expiration time

Is there a way to query a slave to determine how much time is left before its zones expire in a situation where the master has died? We had a master die and we've been meaning to move it off to a newer system. We're trying to determine how much time is left on the zones in order to see if we c

Re: Can't compile bind 9.8.1-P1 on Solaris

Thanks! -- Hal King - h...@utk.edu Systems Administrator Office of Information Technology Systems: Business Information Systems The University of Tennessee 135D Kingston Pike Building 2309 Kingston Pk. Knoxville, TN 37996 Phone: 974-1599 On 11/16/11 4:44 PM, "Dennis Clarke" wrote: > >>

Re: Can't compile bind 9.8.1-P1 on Solaris

> Is anyone else having problems with the compile? > Give me 60 minutes -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastw

Re: Can't compile bind 9.8.1-P1 on Solaris

> I get an error compiling Bind at: > > make[4]: Entering directory > `/usr/local/src/bind-9.8.1-P1/bin/tests/system/dlzexternal' > ld -G -z text -o driver.so driver.o > ld: invalid number `-z' > > Giving –G a number makes –z unrecognized. > > I'm in Solaris 10, Sparc, GCC 3.4.6 > I'm not seeing

Re: Can't compile bind 9.8.1-P1 on Solaris

Is anyone else having problems with the compile? -- Hal King - h...@utk.edu Systems Administrator Office of Information Technology Systems: Business Information Systems The University of Tennessee 135D Kingston Pike Building 2309 Kingston Pk. Knoxville, TN 37996 Phone: 974-1

Re: trigger point for new bug

On Wed, 16 Nov 2011, Evan Hunt wrote: The answer is no, to the best of our knowledge at this time, the bug cannot be triggered before the query ACL has been applied. This doesn't help, though, because the query can be a perfectly innocuous one sent by an allowed host. The problem is what was i

Re: trigger point for new bug

On 11/16/11 9:55 AM, Chris Brookes wrote: Any info on whether the newly announced bug can be triggered before the query ACL is applied on a recursive only server? An authoritative only server ought to be safe? According to our best current understanding of the issue: + Authoritative-only name

Can't compile bind 9.8.1-P1 on Solaris

I get an error compiling Bind at: make[4]: Entering directory `/usr/local/src/bind-9.8.1-P1/bin/tests/system/dlzexternal' ld -G -z text -o driver.so driver.o ld: invalid number `-z' Giving –G a number makes –z unrecognized. I'm in Solaris 10, Sparc, GCC 3.4.6 -- Hal King - h...@utk.edu

Re: Turning log on bind for troubleshooting

On 15.11.11 14:16, Eduardo Bonsi wrote: I already configured for the master and these are my first issues: 15-Nov-2011 13:40:58.312 general: warning: /var/named/bonsi.org.external.hosts:15: ignoring out-of-zone data (EduardoBonsi.45.200.63.in-addr.arpa) 15-Nov-2011 13:40:58.312 general: warnin

Re: trigger point for new bug

> Any info on whether the newly announced bug can be triggered before > the query ACL is applied on a recursive only server? The answer is no, to the best of our knowledge at this time, the bug cannot be triggered before the query ACL has been applied. This doesn't help, though, because the quer

Re: trigger point for new bug

On 11/16/11 10:55 AM, "Chris Brookes" wrote: > Any info on whether the newly announced bug can be triggered before > the query ACL is applied on a recursive only server? An authoritative > only server ought to be safe? Hmm, good question. Then folks with IDS/IPS hooks could potentially catch who

ISC Security Advisory: BIND 9 Resolver crashes after logging an error in query.c

BIND 9 Resolver crashes after logging an error in query.c Summary: Organizations across the Internet reported crashes interrupting service on BIND 9 nameservers performing recursive queries. Affected servers crashed after logging an error in query.c with the following message: "INSIST(! dns_rdatas

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset))failed

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 >

trigger point for new bug

Any info on whether the newly announced bug can be triggered before the query ACL is applied on a recursive only server? An authoritative only server ought to be safe? Cheers C ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubsc

test

test -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users

RE: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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).

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

RE: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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). -Original Message- From: bind-us

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

Re: All Bind servers crashed

On Wed, Nov 16, 2011 at 07:59:10AM -0600, b...@namor.ca wrote: > On Wed, 16 Nov 2011, Bill Owens wrote: > >This behavior makes me bet that the trigger is a name in an incoming > >email message, being resolved by an anti-spam filter. > > We had the same thing happen, across multiple, geographical

Re: All Bind servers crashed

On Wed, 16 Nov 2011, Bill Owens wrote: On Wed, Nov 16, 2011 at 09:57:18AM +0100, Stephane Bortzmeyer wrote: On Wed, Nov 16, 2011 at 09:47:48AM +0100, Magnus Schmidt wrote a message of 49 lines which said: Nov 16 05:30:41 xxx named[1326]: critical: query.c:1781: INSIST(! dns_rdataset_isasso

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

Paradigm shift for error handling

All, On Wed, 2011-11-16 at 13:18 +, Evan Hunt 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 (an

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

RE: BIND 9.7.3-P3 crash on multiple cashing servers

We had the same thing, affected only one of our DNS servers (behind a load-balancer). Here's the relevant log snippet: Nov 15 23:03:33 mail1 named[4601]: query.c:1781: INSIST(! dns_rdataset_isassociated(sigrdataset)) failed, back trace Nov 15 23:03:33 mail1 named[4601]: #0 0x7f1b1e97686f in ?

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

> 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

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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. :) __

Re: All Bind servers crashed

On Wed, Nov 16, 2011 at 09:57:18AM +0100, Stephane Bortzmeyer wrote: > On Wed, Nov 16, 2011 at 09:47:48AM +0100, > Magnus Schmidt wrote > a message of 49 lines which said: > > > Nov 16 05:30:41 xxx named[1326]: critical: query.c:1781: INSIST(! > > dns_rdataset_isassociated(sigrdataset)) failed

Re: BIND 9.7.3-P3 crash on multiple cashing servers

This is from an ISC compiled source. On Wed, Nov 16, 2011 at 2:39 PM, Florian Weimer wrote: > * Samer Khattab: > > > I found the following in the logs: > > > > 16-Nov-2011 08:26:58.724 query.c:1781: INSIST(! > > dns_rdataset_isassociated(sigrdataset)) failed, back trace > > Is this from a versi

Re: BIND 9.7.3-P3 crash on multiple cashing servers

* Samer Khattab: > I found the following in the logs: > > 16-Nov-2011 08:26:58.724 query.c:1781: INSIST(! > dns_rdataset_isassociated(sigrdataset)) failed, back trace Is this from a version which was compiled from sources provided by ISC, or some distribution version? -- Florian Weimer

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

> 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

Update: BIND 9 recursive error being investigated

Interm Security Advisory: http://www.isc.org/software/bind/advisories/cve-2011-tbd (CVE will be updated) Organizations across the Internet are reporting crashes interrupting service on BIND 9 nameservers performing recursive queries. Affected servers crash after logging an error in query.c with

Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

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

Re: BIND 9.7.3-P3 crash on multiple cashing servers

I found the following in the logs: 16-Nov-2011 08:26:58.724 query.c:1781: INSIST(! dns_rdataset_isassociated(sigrdataset)) failed, back trace 16-Nov-2011 08:26:58.738 #0 0x41130b in assertion_failed()+0x4b 16-Nov-2011 08:26:58.738 #1 0x5560da in isc_assertion_failed()+0xa 16-Nov-2011 08:26:58.738

Re: BIND 9.7.3-P3 crash on multiple cashing servers

On Wed, Nov 16, 2011 at 12:08:59PM +0400, Samer Khattab wrote a message of 38 lines which said: > 8 of our cashing-only name servers crashed in a random sequence, and > the crash happened in a 10 minutes time. The servers are running > BIND 9.7.3-P3. Not the only report, it seems. What's in t

Re: All Bind servers crashed

On Wed, Nov 16, 2011 at 09:47:48AM +0100, Magnus Schmidt wrote a message of 49 lines which said: > Nov 16 05:30:41 xxx named[1326]: critical: query.c:1781: INSIST(! > dns_rdataset_isassociated(sigrdataset)) failed, back trace It looks like CVE-2010-3613

All Bind servers crashed

Hello, all three of our bind-Servers crashed tonight at the same time (in a 30 seconds time window), all of them are recursors. Following has been logged: Log-File Nov 16 05:30:41 xxx named[1326]: critical: query.c:1781: INSIST(! dns_rdataset_isassociated(sigrdataset)) failed, back trace Nov 16

BIND 9.7.3-P3 crash on multiple cashing servers

8 of our cashing-only name servers crashed in a random sequence, and the crash happened in a 10 minutes time. The servers are running BIND 9.7.3-P3. The crash produced a core dump for the named process. Does anybody has a similar case recently? Is this a security issue ? Regards, Samer