[dns-operations] bind-9.9.4-P1 crash
Anyone seen this crash:? I’m hitting it fairly often right now and trying to poke at the code for triage: 17-Dec-2013 20:56:03.138 general: name.c:1727: INSIST(offset <= length) failed, back trace 17-Dec-2013 20:56:03.138 general: #0 0x43140d in ?? 17-Dec-2013 20:56:03.138 general: #1 0x7622517a in ?? 17-Dec-2013 20:56:03.138 general: #2 0x77873536 in ?? 17-Dec-2013 20:56:03.139 general: #3 0x77877b8d in ?? 17-Dec-2013 20:56:03.139 general: #4 0x432590 in ?? 17-Dec-2013 20:56:03.139 general: #5 0x4367a6 in ?? 17-Dec-2013 20:56:03.139 general: #6 0x440c1f in ?? 17-Dec-2013 20:56:03.139 general: #7 0x445c19 in ?? 17-Dec-2013 20:56:03.139 general: #8 0x426bef in ?? 17-Dec-2013 20:56:03.139 general: #9 0x76247836 in ?? 17-Dec-2013 20:56:03.139 general: #10 0x75dfcf33 in ?? 17-Dec-2013 20:56:03.139 general: #11 0x75b2aead in ?? 17-Dec-2013 20:56:03.139 general: exiting (due to assertion failure) Seems to perhaps be with a specific QNAME (gdb) bt #0 0x75a6bc59 in raise () from /usr/lib64/libc.so.6 #1 0x75a6d368 in abort () from /usr/lib64/libc.so.6 #2 0x004315d6 in assertion_failed (file=, line=, type=, cond=) at ./main.c:218 #3 0x7622517a in isc_assertion_failed () from /usr/lib64/libisc.so.95 #4 0x77873536 in set_offsets () from /usr/lib64/libdns.so.100 #5 0x77877b8d in dns_name_copy () from /usr/lib64/libdns.so.100 #6 0x00432590 in query_findclosestnsec3 (qname=qname@entry=0x726b6810, db=db@entry=0x7fffe73d82b0, version=version@entry=0x0, client=client@entry=0x7fffe8132e10, rdataset=0x7fffed088b00, sigrdataset=0x7fffed0880f0, fname=0x7fffed0850b0, exact=exact@entry=isc_boolean_true, found=found@entry=0x726b6810) at query.c:5337 #7 0x004367a6 in query_addwildcardproof (client=, db=0x7fffe73d82b0, version=0x7fffe73d0590, name=, ispositive=ispositive@entry=isc_boolean_false, nodata=nodata@entry=isc_boolean_false) at query.c:3482 #8 0x00440c1f in query_find (client=0x7fffe8132e10, event=event@entry=0x0, qtype=, qtype@entry=12) at query.c:6686 #9 0x00445c19 in ns_query_start (client=client@entry=0x7fffe8132e10) at query.c:7794 #10 0x00426bef in client_request (task=, event=) at client.c:1939 #11 0x76247836 in run () from /usr/lib64/libisc.so.95 #12 0x75dfcf33 in start_thread () from /usr/lib64/libpthread.so.0 #13 0x75b2aead in clone () from /usr/lib64/libc.so.6 QNAME available in private for those that I trust. - Jared ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] bind-9.9.4-P1 crash
Could you please submit this to bind9-b...@isc.org. In message <812f0f01-2c7c-434d-b9e8-6219fcb8c...@puck.nether.net>, Jared Mauch writes: > Anyone seen this crash:? > > I'm hitting it fairly often right now and trying to poke at the code for > triage: > > 17-Dec-2013 20:56:03.138 general: name.c:1727: INSIST(offset <= length) > failed, back trace > 17-Dec-2013 20:56:03.138 general: #0 0x43140d in ?? > 17-Dec-2013 20:56:03.138 general: #1 0x7622517a in ?? > 17-Dec-2013 20:56:03.138 general: #2 0x77873536 in ?? > 17-Dec-2013 20:56:03.139 general: #3 0x77877b8d in ?? > 17-Dec-2013 20:56:03.139 general: #4 0x432590 in ?? > 17-Dec-2013 20:56:03.139 general: #5 0x4367a6 in ?? > 17-Dec-2013 20:56:03.139 general: #6 0x440c1f in ?? > 17-Dec-2013 20:56:03.139 general: #7 0x445c19 in ?? > 17-Dec-2013 20:56:03.139 general: #8 0x426bef in ?? > 17-Dec-2013 20:56:03.139 general: #9 0x76247836 in ?? > 17-Dec-2013 20:56:03.139 general: #10 0x75dfcf33 in ?? > 17-Dec-2013 20:56:03.139 general: #11 0x75b2aead in ?? > 17-Dec-2013 20:56:03.139 general: exiting (due to assertion failure) > > > Seems to perhaps be with a specific QNAME > > (gdb) bt > #0 0x75a6bc59 in raise () from /usr/lib64/libc.so.6 > #1 0x75a6d368 in abort () from /usr/lib64/libc.so.6 > #2 0x004315d6 in assertion_failed (file=, > line=, type=, cond=) at > ./main.c:218 > #3 0x7622517a in isc_assertion_failed () from > /usr/lib64/libisc.so.95 > #4 0x77873536 in set_offsets () from /usr/lib64/libdns.so.100 > #5 0x77877b8d in dns_name_copy () from /usr/lib64/libdns.so.100 > #6 0x00432590 in query_findclosestnsec3 > (qname=qname@entry=0x726b6810, db=db@entry=0x7fffe73d82b0, > version=version@entry=0x0, > client=client@entry=0x7fffe8132e10, rdataset=0x7fffed088b00, > sigrdataset=0x7fffed0880f0, fname=0x7fffed0850b0, > exact=exact@entry=isc_boolean_true, > found=found@entry=0x726b6810) at query.c:5337 > #7 0x004367a6 in query_addwildcardproof (client=, > db=0x7fffe73d82b0, version=0x7fffe73d0590, name=, > ispositive=ispositive@entry=isc_boolean_false, > nodata=nodata@entry=isc_boolean_false) at query.c:3482 > #8 0x00440c1f in query_find (client=0x7fffe8132e10, > event=event@entry=0x0, qtype=, qtype@entry=12) at > query.c:6686 > #9 0x00445c19 in ns_query_start > (client=client@entry=0x7fffe8132e10) at query.c:7794 > #10 0x00426bef in client_request (task=, > event=) at client.c:1939 > #11 0x76247836 in run () from /usr/lib64/libisc.so.95 > #12 0x75dfcf33 in start_thread () from /usr/lib64/libpthread.so.0 > #13 0x75b2aead in clone () from /usr/lib64/libc.so.6 > > QNAME available in private for those that I trust. > > - Jared > > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] bind-9.9.4-P1 crash
Turning off dnssec and validation fixed it for me. - Jared > On Dec 17, 2013, at 9:00 PM, Jared Mauch wrote: > > Anyone seen this crash:? > > I’m hitting it fairly often right now and trying to poke at the code for > triage: > > 17-Dec-2013 20:56:03.138 general: name.c:1727: INSIST(offset <= length) > failed, back trace > 17-Dec-2013 20:56:03.138 general: #0 0x43140d in ?? > 17-Dec-2013 20:56:03.138 general: #1 0x7622517a in ?? > 17-Dec-2013 20:56:03.138 general: #2 0x77873536 in ?? > 17-Dec-2013 20:56:03.139 general: #3 0x77877b8d in ?? > 17-Dec-2013 20:56:03.139 general: #4 0x432590 in ?? > 17-Dec-2013 20:56:03.139 general: #5 0x4367a6 in ?? > 17-Dec-2013 20:56:03.139 general: #6 0x440c1f in ?? > 17-Dec-2013 20:56:03.139 general: #7 0x445c19 in ?? > 17-Dec-2013 20:56:03.139 general: #8 0x426bef in ?? > 17-Dec-2013 20:56:03.139 general: #9 0x76247836 in ?? > 17-Dec-2013 20:56:03.139 general: #10 0x75dfcf33 in ?? > 17-Dec-2013 20:56:03.139 general: #11 0x75b2aead in ?? > 17-Dec-2013 20:56:03.139 general: exiting (due to assertion failure) > > > Seems to perhaps be with a specific QNAME > > (gdb) bt > #0 0x75a6bc59 in raise () from /usr/lib64/libc.so.6 > #1 0x75a6d368 in abort () from /usr/lib64/libc.so.6 > #2 0x004315d6 in assertion_failed (file=, > line=, type=, cond=) at > ./main.c:218 > #3 0x7622517a in isc_assertion_failed () from /usr/lib64/libisc.so.95 > #4 0x77873536 in set_offsets () from /usr/lib64/libdns.so.100 > #5 0x77877b8d in dns_name_copy () from /usr/lib64/libdns.so.100 > #6 0x00432590 in query_findclosestnsec3 > (qname=qname@entry=0x726b6810, db=db@entry=0x7fffe73d82b0, > version=version@entry=0x0, >client=client@entry=0x7fffe8132e10, rdataset=0x7fffed088b00, > sigrdataset=0x7fffed0880f0, fname=0x7fffed0850b0, > exact=exact@entry=isc_boolean_true, >found=found@entry=0x726b6810) at query.c:5337 > #7 0x004367a6 in query_addwildcardproof (client=, > db=0x7fffe73d82b0, version=0x7fffe73d0590, name=, >ispositive=ispositive@entry=isc_boolean_false, > nodata=nodata@entry=isc_boolean_false) at query.c:3482 > #8 0x00440c1f in query_find (client=0x7fffe8132e10, > event=event@entry=0x0, qtype=, qtype@entry=12) at query.c:6686 > #9 0x00445c19 in ns_query_start (client=client@entry=0x7fffe8132e10) > at query.c:7794 > #10 0x00426bef in client_request (task=, > event=) at client.c:1939 > #11 0x76247836 in run () from /usr/lib64/libisc.so.95 > #12 0x75dfcf33 in start_thread () from /usr/lib64/libpthread.so.0 > #13 0x75b2aead in clone () from /usr/lib64/libc.so.6 > > QNAME available in private for those that I trust. > > - Jared > ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] bind-9.9.4-P1 crash
I am glad to see there is an administrator from google. In fact our nameservers have blocked a lot of IPs from google: DROP all -- 173.194.99.0/24 0.0.0.0/0 DROP all -- 74.125.16.2100.0.0.0/0 DROP all -- 74.125.41.17 0.0.0.0/0 DROP all -- 74.125.191.820.0.0.0/0 DROP all -- 74.125.41.19 0.0.0.0/0 DROP all -- 74.125.16.2150.0.0.0/0 DROP all -- 74.125.41.18 0.0.0.0/0 DROP all -- 74.125.41.20 0.0.0.0/0 DROP all -- 74.125.191.840.0.0.0/0 DROP all -- 74.125.16.2120.0.0.0/0 DROP all -- 74.125.191.810.0.0.0/0 DROP all -- 74.125.191.830.0.0.0/0 DROP all -- 74.125.41.16 0.0.0.0/0 DROP all -- 74.125.16.80 0.0.0.0/0 DROP all -- 74.125.16.2140.0.0.0/0 DROP all -- 74.125.191.800.0.0.0/0 DROP all -- 74.125.16.81 0.0.0.0/0 DROP all -- 74.125.16.2130.0.0.0/0 DROP all -- 74.125.16.83 0.0.0.0/0 DROP all -- 74.125.16.84 0.0.0.0/0 DROP all -- 74.125.16.82 0.0.0.0/0 DROP all -- 74.125.16.2080.0.0.0/0 DROP all -- 74.125.16.2110.0.0.0/0 DROP all -- 74.125.16.2090.0.0.0/0 DROP all -- 74.125.178.180.0.0.0/0 DROP all -- 74.125.178.190.0.0.0/0 DROP all -- 74.125.176.810.0.0.0/0 DROP all -- 74.125.19.2130.0.0.0/0 DROP all -- 74.125.177.180.0.0.0/0 DROP all -- 74.125.178.230.0.0.0/0 DROP all -- 74.125.42.20 0.0.0.0/0 DROP all -- 74.125.177.190.0.0.0/0 DROP all -- 74.125.42.16 0.0.0.0/0 DROP all -- 74.125.42.16 0.0.0.0/0 DROP all -- 74.125.42.18 0.0.0.0/0 DROP all -- 74.125.177.200.0.0.0/0 DROP all -- 74.125.40.21 0.0.0.0/0 DROP all -- 74.125.178.220.0.0.0/0 DROP all -- 74.125.178.160.0.0.0/0 DROP all -- 74.125.40.17 0.0.0.0/0 DROP all -- 74.125.185.170.0.0.0/0 DROP all -- 74.125.185.220.0.0.0/0 DROP all -- 74.125.185.210.0.0.0/0 DROP all -- 74.125.40.22 0.0.0.0/0 DROP all -- 74.125.185.200.0.0.0/0 DROP all -- 74.125.19.2100.0.0.0/0 DROP all -- 74.125.185.180.0.0.0/0 DROP all -- 74.125.176.144 0.0.0.0/0 DROP all -- 74.125.185.190.0.0.0/0 DROP all -- 74.125.185.230.0.0.0/0 DROP all -- 74.125.177.160.0.0.0/0 DROP all -- 74.125.42.19 0.0.0.0/0 DROP all -- 74.125.42.17 0.0.0.0/0 DROP all -- 74.125.177.170.0.0.0/0 All the queries from those IPs are going with this style: 74.125.191.84#63255: query: qalljrwww.byw.so 74.125.41.20#53581: query: womciswww.byw.so And the count is huge. So I dropped them. Can you help take a look from your end? Thanks. On 2013-12-18 11:59, Damian Menscher wrote: I'm interested in more details. In particular, it would help to know: - is the trigger a well-formed DNS query or a crafted packet? - does this affect authoritative servers or recursives? - or is the problem actually in the response (through a recursive) from some evil authoritative server? Even if you don't want to share the specifics, knowing the answers to these questions would help people judge the risks. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
