Re: BIND 9.10.4 may have a fatal crash defect.
To our users: Last week, reacting to reports from several users concerning assertion failures in BIND 9.10.4, we took the unusual step of deprecating that release while we investigated the problem: internal checks detecting a state in the cache data structure that should have been impossible. Thanks to several users who shared their crash data with us, our developers have identified a problem. In the April 28 maintenance releases, the internal representation and packing of the 'node' structure used in the BIND cache was changed to reduce memory usage and increase performance. The packing change caused some single-bit flag values that were protected by one lock to share the same word in physical memory with flag values protected by a different lock. This creates the potential for a race condition: two threads can modify the same flag value simultaneously, leading to the inconsistent state that triggers the assertion failures. Though this flaw can occur with any compiler, it's substantially more likely to lead to a crash when BIND is compiled on the x86_64 platform using the 'clang' compiler and a difference in the node structure between BIND 9.9 and 9.10 makes the failure more likely to occur in BIND 9.10. However, operators who are running one of the affected versions (BIND 9.9.9, BIND 9.10.4, or BIND 9.9.9-S1) should replace those versions as soon as updated releases are available. Having identified what we believe to be the root cause, we are currently, with the help of some volunteers who were previously experiencing crashes in their operational environments, testing a candidate fix with (so far) good results. If no further failures occur, we expect to issue patch releases for all of the April 28 releases (BIND 9.9.9, BIND 9.10.4, and BIND 9.9.9-S1) If you're wondering how this affects you, we hope this summary may help: + Nothing we have seen so far suggests that this issue is a deliberately exploitable security vulnerability. + Completely authoritative servers are at extremely low risk (approaching zero) from this defect. Only recursive servers are at significant risk. If you are operating an authoritative server which does not perform recursion for clients, you can probably safely wait for replacement versions to be released and upgrade when convenient. + We have only received reports of INSIST exceptions in BIND 9.10.4. + The change which exposed the race condition exists in BIND 9.9.9 and BIND 9.9.9-S1 as well, but we have received no reports of INSIST errors occurring in those versions. They are possible but have a much lower probability of occurrence. + If you are running a recursive resolver on an affected version of BIND, you are at moderate risk unless you are running BIND 9.10.4 and your named binaries have been compiled with clang, in which case you are at higher risk. You have several options, including: - revert to BIND 9.9.8-P4, 9.10.3-P4, or 9.9.8-S6 until the replacement versions are officially released - retrieve and compile the current 9_9 or 9_10 branch from the ISC public git repository, which will contain the candidate fix which we expect to release next week or contact ISC Support for assistance with a patch if you are a customer with a support contract. - use a watchdog process to manage 'named' and restart it if it exits; upgrade when replacement versions are released. We'd like to once again thank the users who helped us to track this down and apologize for the inconvenience it has caused to our users. Michael McNally ISC Support ___ 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: Trouble with option managed-keys
Hello Mark,
yes, it works now. Thanks for your prompt help.
Thomas Hluchnik
Am Tuesday 17 May 2016 22:49:29 schrieb Mark Elkins:
> "managed-keys" is not a config option, try moving it outside the option
> stanza, eg
>
> options {
> version ""; // remove this to allow version queries
> listen-on{ 127.0.0.1; 192.168.21.101; };
> listen-on-v6 { none; };
> empty-zones-enable yes;
> allow-query { clients; };
> allow-recursion { clients; };
> allow-transfer { none; };
> dnssec-enable yes;
> dnssec-validation yes;
> };
>
> include "/etc/root_trusted_key";
>
> logging {
> category lame-servers { null; };
> };
> ...
>
> Personally, I just have the text from your included file directly in
> named.conf file itself.
>
> Take a quick peek at http://dnssec.co.za
>
>
>
> On 17/05/2016 22:35, t...@it-hluchnik.de wrote:
> > Hi all,
> >
> > I have a problem with DNSSEC and I dont find a solution. Maybe someone can
> > help me.
> >
> > My intention is to run a bind which acts as DNSSEC enabled resolver for my
> > internal LAN. This runs on a VirtualBox instance with OpenBSD 5.9. I got a
> > precompiled package from OpenBSD, version is 9.10.3-P3.
> >
> > Configuring my named, I mostly followed a howto from Calomel.org:
> >
> > https://calomel.org/dns_bind.html
> >
> > This is my named.conf:
> >
> > root@bsd59n:/var/named/etc# egrep -v '^ *#|^ *$|^\/\/' named.conf
> > acl clients {
> > 127.0.0.0/8;
> > 192.168.21.0/24;
> > ::1;
> > };
> > options {
> > version ""; // remove this to allow version queries
> > listen-on{ 127.0.0.1; 192.168.21.101; };
> > listen-on-v6 { none; };
> > empty-zones-enable yes;
> > allow-query { clients; };
> > allow-recursion { clients; };
> > allow-transfer { none; };
> > include "/etc/root_trusted_key";
> > dnssec-enable yes;
> > dnssec-validation yes;
> > };
> > logging {
> > category lame-servers { null; };
> > };
> > zone "." {
> > type hint;
> > file "etc/root.hint";
> > };
> > zone "localhost" {
> > type master;
> > file "standard/localhost";
> > allow-transfer { localhost; };
> > };
> > zone "127.in-addr.arpa" {
> > type master;
> > file "standard/loopback";
> > allow-transfer { localhost; };
> > };
> >
> >
> > As my named is running in a chroot jail, /etc/root_trusted_key is
> > /var/named/etc/root_trusted_key in reality.
> >
> > root@bsd59n:/var/named/etc# root_trusted_key
> > managed-keys {
> >"." initial-key 257 3 8
> > "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
> > FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
> > bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
> > X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
> > W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
> > Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ";
> > };
> >
> > root_trusted_key was generated as Calomel howto describes.
> >
> > Now, when I try to start named with that config, I get a courious error
> > message:
> >
> >
> > root@bsd59n:/var/named/etc# /usr/local/sbin/named -t /var/named -u _bind -U
> > 4 -g
> > 17-May-2016 21:53:14.644 starting BIND 9.10.3-P3 -t /var/named
> > -u _bind -U 4 -g
> > 17-May-2016 21:53:14.644 built with '--enable-shared'
> > '--enable-filter-' '--enable-threads' '--with-libt
> > ool' '--without-readline' '--with-python=/usr/local/bin/python2.7'
> > '--prefix=/usr/local' '--sysconfdir=/etc'
> > '--mandir=/usr/local/man' '--infodir=/usr/local/info'
> > '--localstatedir=/var' '--disable-silent-rules' '--di
> > sable-gtk-doc' 'CC=cc' 'CFLAGS=-O2 -pipe'
> > 17-May-2016 21:53:14.644
> >
> > 17-May-2016 21:53:14.644 BIND 9 is maintained by Internet Systems
> > Consortium,
> > 17-May-2016 21:53:14.644 Inc. (ISC), a non-profit 501(c)(3) public-benefit
> > 17-May-2016 21:53:14.644 corporation. Support and training for BIND 9 are
> > 17-May-2016 21:53:14.644 available at https://www.isc.org/support
> > 17-May-2016 21:53:14.644
> >
> > 17-May-2016 21:53:14.645 found 2 CPUs, using 2 worker threads
> > 17-May-2016 21:53:14.645 using 2 UDP listeners per interface
> > 17-May-2016 21:53:14.648 using up to 4096 sockets
> > 17-May-2016 21:53:14.681 loading configuration from '/etc/named.conf'
> > 17-May-2016 21:53:14.683 /etc/root_trusted_key:1: unknown option
> > 'managed-keys'
> > 17-May-2016 21:53:14.686 loading configuration: failure
> > 17-May-2016 21:53:14.686 exiting (due to fatal error)
> >
> >
> > But named documentation and "man named.conf" both say that managed-keys
> > were a valid option.
> >
> > So what's wrong here? Thanks in advance for any help.
> >
> > Thomas Hluchnik
> >
> >
> >
resolution problem
I am having an issue resolving www.cloudsat.cira.colostate.edu from 2 of my name servers. I have 2 others with identical configs that resolve correctly. A normal lookup shows a server fail but a +trace looks ok. Any ideas how to better troubleshoot the issue? dig www.cloudsat.cira.colostate.edu @ns1.service.uci.edu ; <<>> DiG 9.3.4-P1 <<>> www.cloudsat.cira.colostate.edu @ns1.service.uci.edu ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1057 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.cloudsat.cira.colostate.edu. INA ;; Query time: 4992 msec ;; SERVER: 128.200.1.201#53(128.200.1.201) ;; WHEN: Wed May 18 14:08:26 2016 ;; MSG SIZE rcvd: 49 dig www.cloudsat.cira.colostate.edu @ns1.service.uci.edu +trace ; <<>> DiG 9.3.4-P1 <<>> www.cloudsat.cira.colostate.edu @ns1.service.uci.edu +trace ; (1 server found) ;; global options: printcmd . 350434 IN NS d.root-servers.net. . 350434 IN NS e.root-servers.net. . 350434 IN NS c.root-servers.net. . 350434 IN NS a.root-servers.net. . 350434 IN NS l.root-servers.net. . 350434 IN NS f.root-servers.net. . 350434 IN NS g.root-servers.net. . 350434 IN NS i.root-servers.net. . 350434 IN NS j.root-servers.net. . 350434 IN NS b.root-servers.net. . 350434 IN NS k.root-servers.net. . 350434 IN NS m.root-servers.net. . 350434 IN NS h.root-servers.net. ;; Received 496 bytes from 128.200.1.201#53(128.200.1.201) in 2 ms edu.172800 IN NS l.edu-servers.net. edu.172800 IN NS a.edu-servers.net. edu.172800 IN NS d.edu-servers.net. edu.172800 IN NS f.edu-servers.net. edu.172800 IN NS g.edu-servers.net. edu.172800 IN NS c.edu-servers.net. ;; Received 284 bytes from 199.7.91.13#53(d.root-servers.net) in 73 ms colostate.edu. 172800 IN NS dns1.colostate.edu. colostate.edu. 172800 IN NS dns3.colostate.edu. ;; Received 119 bytes from 192.41.162.30#53(l.edu-servers.net) in 78 ms www.cloudsat.cira.colostate.edu. 3600 IN CNAME dpc.cira.colostate.edu. dpc.cira.colostate.edu. 3600IN A 129.82.109.62 ;; Received 83 bytes from 129.82.103.121#53(dns1.colostate.edu) in 36 ms___ 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
