Description of problem: Version-Release number of selected component: bind-9.9.3-14.P2.fc19 Additional info: reporter: libreport-2.1.12 backtrace_rating: 4 cmdline: /usr/sbin/named -u named crash_function: assertion_failed executable: /usr/sbin/named kernel: 3.13.5-101.fc19.x86_64 runlevel: unknown type: CCpp uid: 25 Truncated backtrace: Thread no. 1 (8 frames) #2 assertion_failed at ./main.c:219 #3 isc_assertion_failed at assertions.c:57 #4 dns_db_detachnode at db.c:636 #5 query_find at query.c:6507 #6 ns_query_start at query.c:7790 #7 client_request at client.c:1970 #8 dispatch at task.c:1116 #9 run at task.c:1286
Created attachment 874676 [details] File: backtrace
Created attachment 874677 [details] File: cgroup
Created attachment 874678 [details] File: core_backtrace
Created attachment 874679 [details] File: dso_list
Created attachment 874680 [details] File: environ
Created attachment 874681 [details] File: limits
Created attachment 874682 [details] File: maps
Created attachment 874683 [details] File: open_fds
Created attachment 874684 [details] File: proc_pid_status
Created attachment 874685 [details] File: var_log_messages
*** Bug 1076261 has been marked as a duplicate of this bug. ***
Do you know the DNS query which causes the crash? Is there any chance to get the coredump file from you? (Please compress it as much as you can and attach it to this bug. I would recommend you to check "Make attachment and comment private".) Also, output from command "rpm -qa" would be very appreciated. Thank you!
Any query that requests a hostname that does NOT return a AAAA from an ldap backed domain. IE for example.com, if a host such as foo.example.com has an A record, but no AAAA and you run: dig foo.example.com AAAA You will crash the named server.
Created attachment 876139 [details] output from rpm -qa
That is really weird, I'm pretty sure we haven't seen that in our tests :-) Please attach full named.conf (not only an excerpt) to this bug. (Do not forget to redact passwords :-) Could you export the DNS database from LDAP and attach it to this bug or send it to me privately, please? You can use following command (when kinit'ed as IPA admin): $ ldapsearch -Y GSSAPI -b 'cn=dns, dc=ipa, dc=test' > /tmp/dns.ldif
I have reproduced the crash. You have DNS64 enabled, haven't you? I added this snippet to my named.conf: dns64 ::ffff:0:0/96 { clients { any; }; exclude { none; }; }; And now it crashes if I do a DNS query for a name with A record but without AAAA record.
Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/132
I have tested this configuration on Fedora 20 with bind-dyndb-ldap-4.1-1.fc20.x86_64 and it doesn't crash: My recommendation is to temporarily disable DNS64 and then upgrade to Fedora 20 :-) I can't promise that fix for Fedora 19 will be available soon because nobody considered DNS64 during original bind-dyndb-ldap design. (Version 4 was heavily refactored so some limitations from older version are not present anymore.) # dig @127.0.0.1 vm.ipa.example. ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-11.P2.fc20 <<>> @127.0.0.1 vm.ipa.example. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28368 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;vm.ipa.example. IN A ;; ANSWER SECTION: vm.ipa.example. 86400 IN A 192.0.2.111 ;; AUTHORITY SECTION: ipa.example. 86400 IN NS vm.ipa.example. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: St bře 19 16:12:50 CET 2014 ;; MSG SIZE rcvd: 106 # @127.0.0.1 vm.ipa.example. -t AAAA ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-11.P2.fc20 <<>> @127.0.0.1 vm.ipa.example. -t AAAA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32301 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;vm.ipa.example. IN AAAA ;; ANSWER SECTION: vm.ipa.example. 3600 IN AAAA ::ffff:192.0.2.111 ;; AUTHORITY SECTION: ipa.example. 86400 IN NS vm.ipa.example. ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: St bře 19 16:12:53 CET 2014 ;; MSG SIZE rcvd: 118 # dig @127.0.0.1 vm.ipa.example. -t ANY ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-11.P2.fc20 <<>> @127.0.0.1 vm.ipa.example. -t ANY ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29670 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;vm.ipa.example. IN ANY ;; ANSWER SECTION: vm.ipa.example. 86400 IN A 192.0.2.111 ;; AUTHORITY SECTION: ipa.example. 86400 IN NS vm.ipa.example.
Yes, I am running this with dns64 I will follow your instructions as asked, and will remove dns64 and upgrade my systems to f20. This will take me a bit to work out of course, given backups, and such to ensure a smooth upgrade. I will report back soon about this.
Thanks. I think it would be then useful to test if dns64 indeed works with the Fedora 20 version of bind-dyndb-ldap - it should, AFAIU.
(In reply to Martin Kosek from comment #20) > Thanks. I think it would be then useful to test if dns64 indeed works with > the Fedora 20 version of bind-dyndb-ldap - it should, AFAIU. Please see comment 18 :-)
I read it, this is why I did Comment 20 - to encourage William to not disable dns64 permanently.
(In reply to Martin Kosek from comment #22) Ah okay, I thought that your message was intended to me :-)
I have upgraded to f20, reconfigured dns64 to run and observed. Everything seems to be more stable now, with no crashes since. Thanks for the advice on this matter. Perhaps it should be listed that f19 is not recommended for ipa due to the older bind-dyndb version? Which version of bind-dyndb is going into rhel7?
(In reply to William Brown from comment #24) > I have upgraded to f20, reconfigured dns64 to run and observed. Everything > seems to be more stable now, with no crashes since. I will try to fix it in bind-dyndb-ldap 3.x when I have time for doing it. > Thanks for the advice on this matter. Perhaps it should be listed that f19 > is not recommended for ipa due to the older bind-dyndb version? Personally, I wouldn't use so strong words :-) I guess that bind-dyndb-ldap 3.x works most deployments. Please consider that you are the first one who ever tried DNS64 with IPA and reported a bug about it. > Which version of bind-dyndb is going into rhel7? Relevant RHEL 7 bug is https://bugzilla.redhat.com/show_bug.cgi?id=1078295.
(In reply to Petr Spacek from comment #25) > (In reply to William Brown from comment #24) > > I have upgraded to f20, reconfigured dns64 to run and observed. Everything > > seems to be more stable now, with no crashes since. > I will try to fix it in bind-dyndb-ldap 3.x when I have time for doing it. > Thanks for that. > > Thanks for the advice on this matter. Perhaps it should be listed that f19 > > is not recommended for ipa due to the older bind-dyndb version? > Personally, I wouldn't use so strong words :-) I guess that bind-dyndb-ldap > 3.x works most deployments. Please consider that you are the first one who > ever tried DNS64 with IPA and reported a bug about it. > Well there you go: Pushing boundaries ;) > > Which version of bind-dyndb is going into rhel7? > Relevant RHEL 7 bug is https://bugzilla.redhat.com/show_bug.cgi?id=1078295. Excellent! Thanks again for your help.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
We discussed this Bugzilla in the team and do not plan to fix the Fedora 19 version, given that this feature is obviously not very used and we have a fix on next version of Fedora (cannot be backported, it is caused by using different internal storage). Closing as NEXTRELEASE.