lib/dns/message.c:1626: INSIST(free_name == isc_boolean_false) failed, with SIG0 response and SIG0 in additional record
we have been running one of the Codenomicon test suits sending various
DNS responses back to client requests triggered by nslookup and dig
and we have hit an
abort() with reposnse containing SIG0 answer type
and SIG0 type in additional records.
Domain Name System (response) Transaction ID: 0x2f83 Flags: 0x8100 Standard query response, No error Questions: 1 Answer RRs: 1 Authority RRs: 1 Additional RRs: 1 Queries dns.suite.local: type A, class IN Name: dns.suite.local [Name Length: 15] [Label Count: 3] Type: A (Host Address) (1) Class: IN (0x0001) Answers la\030el: type SIG, class IN Name: la\030el Type: SIG (security signature) (24) Class: IN (0x0001) Time to live: 3600 Data length: 35 Type Covered: Unused (0) Algorithm: RSA/SHA1 (5) Labels: 85 Original TTL: 0 (0 seconds) Signature Expiration: Jun 8, 1970 13:43:44.000000000 CET Signature Inception: Jan 16, 2019 13:45:51.000000000 CET Key Tag: 0 Signer's name: dns.suite.local Signature: 6c00 Authoritative nameservers dns.suite.local: type A, class IN, addr 0.0.0.0 Name: dns.suite.local Type: A (Host Address) (1) Class: IN (0x0001) Time to live: 3600 Data length: 4 Address: 0.0.0.0 Additional records suite.local: type SIG, class IN Name: suite.local Type: SIG (security signature) (24) Class: IN (0x0001) Time to live: 3600 Data length: 35 Type Covered: Unused (0) Algorithm: RSA/SHA1 (5) Labels: 0 Original TTL: 0 (0 seconds) Signature Expiration: Feb 7, 1970 23:13:20.000000000 CET Signature Inception: Jan 16, 2019 13:45:51.000000000 CET Key Tag: 72 Signer's name: dns.suite.local Signature: 6c00
getsection() doesn't know how to handle this kind of packet
as there is already sig0 record and free_name is left 'true'.
Stack trace of thread 8334:
#0 0x00007fb9b0ad153f __GI_raise (libc.so.6) #1 0x00007fb9b0abb895 __GI_abort (libc.so.6) #2 0x00007fb9b147efea isc_assertion_failed (libisc.so.169) #3 0x00007fb9b160de30 getsection (libdns.so.1102) #4 0x00007fb9b160e3e2 dns_message_parse (libdns.so.1102) #5 0x000000000041bff5 recv_done (dig) #6 0x00007fb9b14b0b72 dispatch (libisc.so.169) #7 0x00007fb9b14b0ecf run (libisc.so.169) #8 0x00007fb9b0fde58e start_thread (libpthread.so.0) #9 0x00007fb9b0b966a3 __clone (libc.so.6)
I have made a reproducer script (attached) it will work on Fedora 29 out of box with bind 9.11.4-P2-RedHat-9.11.4-13.P2.fc29.
I have also tried to configure named to forwarding configuration
and used simple script to send the problematic response back but I have
not able to force the same code path in
getsection(). Still I feel this
problem could hit also named and cause it to
abort(). Therefore I
wanted to report this through this channel first just to make sure.
I didn't manage to figure out any proper fix, I can do that locally with some check for this specific condition but I don't feel it is right. Better if someone from bind developers would have a look.
Just to make sure I'm also attaching logs from reproducer run locally and the pcap capture of the packets, in case the reproducer script fails for you.