Bug 514292 (CVE-2009-0696) - CVE-2009-0696 bind: DoS (assertion failure) via nsupdate packets
Summary: CVE-2009-0696 bind: DoS (assertion failure) via nsupdate packets
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2009-0696
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
: 514481 (view as bug list)
Depends On: 514321 514335 514336 514337 514338 514339
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-28 17:54 UTC by Vincent Danen
Modified: 2019-09-29 12:31 UTC (History)
33 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-30 08:18:22 UTC
Embargoed:


Attachments (Terms of Use)
difference between 9.4.3-P2 and 9.4.3-P3 to correct this issue (1.69 KB, patch)
2009-07-28 20:13 UTC, Vincent Danen
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1179 0 normal SHIPPED_LIVE Important: bind security update 2009-07-29 22:56:17 UTC
Red Hat Product Errata RHSA-2009:1180 0 normal SHIPPED_LIVE Important: bind security and bug fix update 2009-07-29 18:01:26 UTC
Red Hat Product Errata RHSA-2009:1181 0 normal SHIPPED_LIVE Important: bind security and bug fix update 2009-07-29 18:17:58 UTC

Description Vincent Danen 2009-07-28 17:54:14 UTC
A Debian bug report [1] notes that named can be caused to exit with an assertion failure due to a particular update packet.  This will cause a complete exit of named, preventing it from serving any more DNS responses.

The bug includes a reproducer in perl that can be used to trigger this.  I have tried the reproducer against my local network LAN server (running CentOS 5.3) and it works as advertised, however there are a few factors that increase the complexity and reduce the exploitability of this issue.  Because these are update packets, named must be setup to allow updating of records (which is typical in the case of dynamic DNS), however the RNDC key is required in order to perform the update; possibly if named is configured insecurely to allow hosts on the local network to update without the RNDC key this could be a much larger problem (unverified if that is the case).

By default, both /etc/rndc.conf and /etc/rndc.key are mode 0640 and owned root:named so on the DNS server itself, someone would require named or root privileges to obtain the key; on external systems that may contain the RNDC key for updating, this would depend on that host's security.

It is also required to know a FQDN that already exists on the DNS server; attempting to update a FQDN that does not exist does not cause named to exit.  Sample log output for a succesful crash:

Jul 28 11:30:58 hades named[18990]: db.c:579: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
Jul 28 11:30:58 hades named[18990]: exiting (due to assertion failure)

And when the FQDN is not correct:

Jul 28 11:24:36 hades named[8301]: client 10.10.10.10#36034: updating zone 'me.ca/IN': update unsuccessful: 1.me.ca/ANY: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)

And finally, when an incorrect RNDC key is provided:

Jul 28 11:30:16 hades named[18891]: client 10.10.10.10#35404: request has invalid signature: TSIG rndckey: tsig verify failure (BADSIG)

Interestingly, the reproducer is a clever one as it does not exist when named crashes, so if named is restarted or is running under a supervision service to auto-restart, just leaving the reproducer running will continue to cause it to crash indefinitely unless the attacking IP is firewalled off.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538975

Comment 2 Vincent Danen 2009-07-28 20:11:56 UTC
CERT has their vulnerability note here: http://www.kb.cert.org/vuls/id/725188

Comment 3 Vincent Danen 2009-07-28 20:13:19 UTC
Created attachment 355461 [details]
difference between 9.4.3-P2 and 9.4.3-P3 to correct this issue

Upstream releases are also available:

http://oldwww.isc.org/sw/bind/view?release=9.4.3-P3&noframes=1
http://oldwww.isc.org/sw/bind/view?release=9.5.1-P3&noframes=1
http://oldwww.isc.org/sw/bind/view?release=9.6.1-P1&noframes=1

Comment 5 Vincent Danen 2009-07-28 21:06:09 UTC
ISC's advisory on this issue: https://www.isc.org/node/474 :

Description:

Urgent: this exploit is public. Please upgrade immediately.

Receipt of a specially-crafted dynamic update message may cause BIND 9 servers to exit. This vulnerability affects all servers – it is not limited to those that are configured to allow dynamic updates. Access controls will not provide an effective workaround.

dns_db_findrdataset() fails when the prerequisite section of the dynamic update message contains a record of type “ANY” and where at least one RRset for this FQDN exists on the server.

db.c:659: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
exiting (due to assertion failure).
Workarounds:
None.

(Some sites may have firewalls that can be configured with packet filtering techniques to prevent nsupdate messages from reaching their nameservers.)
Active exploits:
An active remote exploit is in wide circulation at this time.

Comment 8 Michael H. Warfield 2009-07-29 02:46:07 UTC
Based on the original advisory, this appears to affect only "master" servers.  One standard best practice is to have one master and multiple slaves and to protect that master (no exposure to the Internet).  This would seem to be a mitigation.  This is a BCP (Best Common Practice) for those of us who have been doing this for years.

Sites with authoritative name servers definitely should upgrade AND fix their configurations to protect their masteres.

Comment 11 Durval Menezes 2009-07-29 13:28:20 UTC
I've reproduced this bug with the stock RHEL4 bind (bind-9.2.4-30.el4_7.2).

I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a source 
package and binary packages that fix it (under the same conditions, the patched 
named no longer aborts), and placed it all (patch, spec file, source RPM, and binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind

The direct URL for the patch is http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; 
please feel free to use it as appropriate.

Best Regards,
-- 
   Durval Menezes <durval AT tmp DOT com DOT br>

Comment 12 Fedora Update System 2009-07-29 13:42:39 UTC
bind-9.6.1-4.P1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/bind-9.6.1-4.P1.fc11

Comment 13 Fedora Update System 2009-07-29 13:42:48 UTC
bind-9.5.1-3.P3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/bind-9.5.1-3.P3.fc10

Comment 14 Elia Pinto 2009-07-29 14:09:23 UTC
(In reply to comment #11)
> I've reproduced this bug with the stock RHEL4 bind (bind-9.2.4-30.el4_7.2).
> 
> I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a
> source 
> package and binary packages that fix it (under the same conditions, the patched 
> named no longer aborts), and placed it all (patch, spec file, source RPM, and
> binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind
> 
> The direct URL for the patch is
> http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; 
> please feel free to use it as appropriate.
> 
> Best Regards,
> -- 
>    Durval Menezes <durval AT tmp DOT com DOT br>  

Solaris Designer reproduce the bug also without using dynamic update

quote

On Wed, Jul 29, 2009 at 05:15:09PM +0400, Solar Designer wrote:
> Confirmed on 9.3.5-P2 (removing the "$packet->sign_tsig(...)" line from
> the exploit as above) with whatever patches we happened to have until
> this latest fix.

It gets worse: I was also able to crash named from an IP address
explicitly denied in "allow-query".  I did verify that non-malicious
queries from that IP address were indeed correctly denied.

It appears that BIND does too much processing too early in the code.

Alexander

quote

Found on oss-security mailing list

Comment 15 Tomas Hoger 2009-07-29 14:11:28 UTC
(In reply to comment #11)
> The direct URL for the patch is
> http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; 
> please feel free to use it as appropriate.

Updates with similar patch are undergoing quality assurance testing now and will be released as soon as they are fully tested.

Comment 16 Graeme Fowler 2009-07-29 14:35:19 UTC
(In reply to comment #14)
> Solaris Designer reproduce the bug also without using dynamic update

ISC have already acknowledged that the bug affects instances where the configuration does not permit updates. It is not updates themselves that cause the problem, but packets masquerading as updates - whether they would work or not.

Comment 18 Priscila 2009-07-29 14:48:00 UTC
There is some workarrond for this?

Regards.

Priscila Veiga

Comment 19 Priscila 2009-07-29 14:48:26 UTC
https://www.isc.org/node/474

Comment 20 Vincent Danen 2009-07-29 15:01:14 UTC
Upon further investigation it was found that that crash is not limited to configurations that allow updates, contrary to what was originally reported.  As well, the allow-query keyword does not prove an effective ACL mechanism to protect the server, as IPs that are explicitly denied by allow-query can still trigger a crash.

Comment 21 Vincent Danen 2009-07-29 15:04:49 UTC
(In reply to comment #18)
> There is some workarrond for this?

The only work-around for this issue seems to be firewall-based rules to prevent unauthorized systems from talking at all to the named service.  Also see comment #8 regarding master and slave servers.

Comment 24 Adam Tkac 2009-07-29 15:29:53 UTC
*** Bug 514481 has been marked as a duplicate of this bug. ***

Comment 26 Adam Tkac 2009-07-29 15:38:33 UTC
Source RPMs of fixed packages which are undergoing quality assurance testing are also available on http://people.redhat.com/atkac/bind/. Note those packages are _NOT_ official release.

Comment 28 Dmitri Granovski 2009-07-29 15:58:52 UTC
(In reply to comment #11)
> 
> I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a
> source 
> package and binary packages that fix it (under the same conditions, the patched 
> named no longer aborts), and placed it all (patch, spec file, source RPM, and
> binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind
> 
> The direct URL for the patch is
> http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; 
> please feel free to use it as appropriate.
> 
> Best Regards,
> -- 
>    Durval Menezes <durval AT tmp DOT com DOT br>  

You seem to be missing bind-chroot at that location.

Comment 31 Dmitri Granovski 2009-07-29 16:14:41 UTC
Is there a possibility to back-port it to redhat 7.3?

Comment 33 Durval Menezes 2009-07-29 16:21:48 UTC
(In reply to comment #28)
> (In reply to comment #11)
> > 
> > I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a
> > source 
> > package and binary packages that fix it (under the same conditions, the patched 
> > named no longer aborts), and placed it all (patch, spec file, source RPM, and
> > binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind
> > 
> > The direct URL for the patch is
> > http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; 
> > please feel free to use it as appropriate.
> > 
> > Best Regards,
> > -- 
> >    Durval Menezes <durval AT tmp DOT com DOT br>  
> 
> You seem to be missing bind-chroot at that location.  

Indeed. bind-chroot had strange issues at my installation, and since it's just a chroot-tree (which most/all people running bind in a chrooted configuration will already have), I just removed it initially. Will check it later and post it too.
Anyway, if you need the bind-chroot, feel free to recompile it from my src.rpm.

Comment 34 Dmitri Granovski 2009-07-29 16:29:46 UTC
(In reply to comment #33)
> (In reply to comment #28)
> > (In reply to comment #11)
> > > 
> > > I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a
> > > source 
> > > package and binary packages that fix it (under the same conditions, the patched 
> > > named no longer aborts), and placed it all (patch, spec file, source RPM, and
> > > binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind
> > > 
> > > The direct URL for the patch is
> > > http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; 
> > > please feel free to use it as appropriate.
> > > 
> > > Best Regards,
> > > -- 
> > >    Durval Menezes <durval AT tmp DOT com DOT br>  
> > 
> > You seem to be missing bind-chroot at that location.  
> 
> Indeed. bind-chroot had strange issues at my installation, and since it's just
> a chroot-tree (which most/all people running bind in a chrooted configuration
> will already have), I just removed it initially. Will check it later and post
> it too.
> Anyway, if you need the bind-chroot, feel free to recompile it from my src.rpm.  

Done that and everything went well, thank you.

Comment 35 Tomas Hoger 2009-07-29 16:55:24 UTC
(In reply to comment #31)
> Is there a possibility to back-port it to redhat 7.3?  

Dmitri, Red Hat Linux 7.3 is not supported for years, so there will be no update for it.  The patch for later bind version (e.g. from RHEL3) may apply cleanly to bind in 7.3, but you'll have to do you own backport / build.

Comment 37 rmeikle 2009-07-29 17:06:14 UTC
> By default, both /etc/rndc.conf and /etc/rndc.key are mode 0640 and owned
> root:named so on the DNS server itself, someone would require named or root
> privileges to obtain the key; on external systems that may contain the RNDC key
> for updating, this would depend on that host's security.

Maybe I'm misunderstanding...could someone please clarify?  Wouldn't this imply that as long as the box is secure that no malicious attacker could send a packet since they wouldn't have the correct permissions to access the RNDC key?

Comment 38 Tomas Hoger 2009-07-29 17:08:55 UTC
(In reply to comment #11)
> http://www.durval.com.br/RPMS/el4/bind

A note to all using Durval's packages.  If you install them, you may not get official updates installed automatically due to Durval's packages having newer NVR and you may need to install them manually.

Comment 39 Dmitri Granovski 2009-07-29 17:11:43 UTC
(In reply to comment #35)
> (In reply to comment #31)
> > Is there a possibility to back-port it to redhat 7.3?  
> 
> Dmitri, Red Hat Linux 7.3 is not supported for years, so there will be no
> update for it.  The patch for later bind version (e.g. from RHEL3) may apply
> cleanly to bind in 7.3, but you'll have to do you own backport / build.  

Thanks for the heads up.

Here's what happens when I try to build rpm from srcrpm taken from
http://people.redhat.com/atkac/bind/bind-9.2.4-25.el3.src.rpm
glibc-headers-2.3.2-101.4
gcc-2.96-112.7.2

gcc -O2 -g -march=i386 -mcpu=i686 -g -I/usr/src/redhat/BUILD/bind-9.2.4
-I./include -I./../pthreads/include -I../include -I./../include -I./..
-D_REENTRANT -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
-c interfaceiter.c  -fPIC -DPIC -o .libs/interfaceiter.lo
In file included from include/isc/net.h:88,
                 from interfaceiter.c:36:
../include/isc/ipv6.h:63: redefinition of `struct in6_addr'
../include/isc/ipv6.h:81: redefinition of `struct sockaddr_in6'
In file included from interfaceiter.c:36:
include/isc/net.h:159: redefinition of `struct in6_pktinfo'
include/isc/net.h:202: warning: redefinition of `in_port_t'
/usr/include/netinet/in.h:92: warning: `in_port_t' previously declared here
make[3]: *** [interfaceiter.lo] Error 1
make[3]: Leaving directory `/usr/src/redhat/BUILD/bind-9.2.4/lib/isc/unix'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/bind-9.2.4/lib/isc'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/bind-9.2.4/lib'
make: *** [subdirs] Error 1

Comment 41 errata-xmlrpc 2009-07-29 17:44:13 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1179 https://rhn.redhat.com/errata/RHSA-2009-1179.html

Comment 42 errata-xmlrpc 2009-07-29 18:01:39 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2009:1180 https://rhn.redhat.com/errata/RHSA-2009-1180.html

Comment 43 errata-xmlrpc 2009-07-29 18:18:06 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 3

Via RHSA-2009:1181 https://rhn.redhat.com/errata/RHSA-2009-1181.html

Comment 44 Mark J. Cox 2009-07-29 18:28:02 UTC
We will be repushing the RHEL5 update shortly:  The packages in this erratum have been updated to also correct this issue in the bind-sdb package.

Comment 45 errata-xmlrpc 2009-07-29 22:56:20 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1179 https://rhn.redhat.com/errata/RHSA-2009-1179.html

Comment 46 NOSPA 2009-07-30 00:11:04 UTC
(In reply to comment #42)
> This issue has been addressed in following products:
>   Red Hat Enterprise Linux 4
> Via RHSA-2009:1180 https://rhn.redhat.com/errata/RHSA-2009-1180.html  


There are still no new rpms in http://mirror.centos.org/centos/4/updates/i386/RPMS/ when 3.x and 5.x have new bind rpms

Comment 47 Fedora Update System 2009-07-30 03:55:21 UTC
bind-9.6.1-4.P1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 48 Fedora Update System 2009-07-30 03:55:35 UTC
bind-9.5.1-3.P3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 49 NOSPA 2009-07-30 05:23:34 UTC
When you will put RPMs for Red Hat Enterprise Linux 4? There are still old RPMS on http://mirror.centos.org/centos/4/updates/i386/RPMS/

Comment 50 Ted Rule 2009-07-30 06:48:00 UTC
FWIW, the Debian report mentions use of the u32 iptables module to suppress packets based upon matching a bit-string, as in:

iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'

Unfortunately, the u32 module doesn't seem to exist in RHEL kernels ( and hence also CentOS ). The 32 module is mentioned in the manual, even though it doesn't exist in the kernel, BTW.

After some experimentation, I've found that a partial workround is to use the string module instead searching for a single hex-byte:
 
iptables -I INPUT -p udp --dport 53 -m string --algo kmp --from 30 --to 31 --hex-string '|28|' -j LOG --log-prefix "warning: DROPDNS: " --log-level warning

Note that this string search matches on 8-bits, whereas u32 matches on 4. RFC2136 requires 3 of the other bits to be sent as zero, but ignored if non-zero. Hence there's no guarantee that an attacker might not be able to use hex-strings 29 through 2F instead, which would need 7 more iptables rules. There may be a way of expressing this via a regex, but the iptables manual is very thin on details in this regard.

I also assume that string matching on every DNS packet in the kernel is probably CPU hungry, but this workround may at least provide enough medicine to keep the patient alive until the RPM update ambulance arrives.

Comment 51 Adam Tkac 2009-07-30 07:32:54 UTC
(In reply to comment #50)
> FWIW, the Debian report mentions use of the u32 iptables module to suppress
> packets based upon matching a bit-string, as in:
> 
> iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'
> 
> Unfortunately, the u32 module doesn't seem to exist in RHEL kernels ( and hence
> also CentOS ). The 32 module is mentioned in the manual, even though it doesn't
> exist in the kernel, BTW.
> 
> After some experimentation, I've found that a partial workround is to use the
> string module instead searching for a single hex-byte:
> 
> iptables -I INPUT -p udp --dport 53 -m string --algo kmp --from 30 --to 31
> --hex-string '|28|' -j LOG --log-prefix "warning: DROPDNS: " --log-level
> warning
> 
> Note that this string search matches on 8-bits, whereas u32 matches on 4.
> RFC2136 requires 3 of the other bits to be sent as zero, but ignored if
> non-zero. Hence there's no guarantee that an attacker might not be able to use
> hex-strings 29 through 2F instead, which would need 7 more iptables rules.
> There may be a way of expressing this via a regex, but the iptables manual is
> very thin on details in this regard.
> 
> I also assume that string matching on every DNS packet in the kernel is
> probably CPU hungry, but this workround may at least provide enough medicine to
> keep the patient alive until the RPM update ambulance arrives.  

This is protection against UDP based queries only. TCP based queries will still knock down your named.

Comment 52 Tomas Hoger 2009-07-30 08:13:34 UTC
(In reply to comment #37)
> Maybe I'm misunderstanding...could someone please clarify?  Wouldn't this imply
> that as long as the box is secure that no malicious attacker could send a
> packet since they wouldn't have the correct permissions to access the RNDC
> key?

Comment #20 has update for the initial description.  Further investigation proved that the broken code is reachable even with update request packet that is not signed (hence attacked does not need to know key configured on the server) and even if bind is not configured for dynamic updates.

Comment 53 Tomas Hoger 2009-07-30 08:14:57 UTC
(In reply to comment #39)
> Here's what happens when I try to build rpm from srcrpm taken from
> http://people.redhat.com/atkac/bind/bind-9.2.4-25.el3.src.rpm

My though was more about taking SRPM from 7.3 and adding patch extracted from RHEL3 SRPM to it.  Though there may be other unfixed security flaws form the past as well.

Comment 54 Tomas Hoger 2009-07-30 08:18:22 UTC
(In reply to comment #49)
> When you will put RPMs for Red Hat Enterprise Linux 4? There are still old RPMS
> on http://mirror.centos.org/centos/4/updates/i386/RPMS/  

Red Hat Enterprise Linux 4 updates are available via Red Hat Network, SRPM are also available on FTP:

ftp://updates.redhat.com/enterprise/4AS/en/os/SRPMS/

Only CentOS team can tell when corresponding CentOS updates for CentOS 4 will be available.  You can watch centos-announce list for updates:

http://lists.centos.org/mailman/listinfo/centos-announce

Comment 55 Dmitri Granovski 2009-07-31 03:52:31 UTC
(In reply to comment #53)
> (In reply to comment #39)

> My though was more about taking SRPM from 7.3 and adding patch extracted from
> RHEL3 SRPM to it.  Though there may be other unfixed security flaws form the
> past as well.  

I was able to successfully patch bind-9.2.1-1.7x.2.src.rpm using contents of bind-9.2.4-CVE-2009-0696.diff from bind-9.2.4-25.el3.src.rpm

Resulting package seems stable and fixes this particular flaw.

Comment 57 malek shabou 2009-09-08 08:07:49 UTC
(In reply to comment #54)
> (In reply to comment #49)
> > When you will put RPMs for Red Hat Enterprise Linux 4? There are still old RPMS
> > on http://mirror.centos.org/centos/4/updates/i386/RPMS/  
> 
> Red Hat Enterprise Linux 4 updates are available via Red Hat Network, SRPM are
> also available on FTP:
> 
> ftp://updates.redhat.com/enterprise/4AS/en/os/SRPMS/
> 
> Only CentOS team can tell when corresponding CentOS updates for CentOS 4 will
> be available.  You can watch centos-announce list for updates:
> 
> http://lists.centos.org/mailman/listinfo/centos-announce  

	
since it updated, BIND stop responding to requests IPv6 regularly. we have found these errors:
Sep  1 04:02:01 tree named[8364]: client.c:1334: unexpected error:
Sep  1 04:02:06 tree named[8364]: client.c:1334: unexpected error:
Sep  1 04:02:11 tree named[8364]: client.c:1334: unexpected error:


At 04:02 AM logrotate execute '/sbin/service named reload  2> /dev/null > /dev/null || true'

it seems that there is a link between the reload and the probleme


Regards,

Comment 58 Adam Tkac 2009-09-08 12:48:49 UTC
(In reply to comment #57)
> since it updated, BIND stop responding to requests IPv6 regularly. we have
> found these errors:
> Sep  1 04:02:01 tree named[8364]: client.c:1334: unexpected error:
> Sep  1 04:02:06 tree named[8364]: client.c:1334: unexpected error:
> Sep  1 04:02:11 tree named[8364]: client.c:1334: unexpected error:

It seems you are affected by bug #518866.


Note You need to log in before you can comment on or make changes to this bug.