Nsd segfaults when serving a TXT record with two strings

This zone file, which seems legal (two strings in one TXT record, see
RFC 1035, section 3.3.14 which says "one or more"):

TXT "Name of Facility or similar" "City, Country"

crashes nsd when queried with QTYPE=TXT or ANY:

[1309792314] nsd[21571]: warning: server 21573 died unexpectedly with status 11, restarting

nsd 3.2.8 on Debian 6.0.1 "squeeze"

Hi Stephane,

TXT "Name of Facility or similar" "City, Country"

That is extremely worrying, but it does not happen for me.

$ dig @::1 -p 10053 example.nl TXT +norec
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25205
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.nl. IN TXT
;; ANSWER SECTION:
example.nl. 3600 IN TXT "Name of Facility or similar" "City, Country"

Here is the zonefile I used:

@ 10200 IN SOA open.nlnetlabs.nl. hostmaster.nlnetlabs.nl. 2011070101
28800 7200 604800 3600
@ TXT "Name of Facility or similar" "City, Country"

Can you make clean; make (if you compiled it yourself?).

Can you gdb the server (-d prevents it from forking away from the
terminal) and give a 'bt' stack backtrace?

Best regards,
   Wouter

I have different behaviour, which also looks wrong. NSD 3.2.8 running on
OSX 10.6.8, returns just the first string, but not the second, ie. if I
have:

TXT "string 1" "string 2"

then querying NSD for TXT or ANY only returns "string 1".

Anand

a message of 15 lines which said:

crashes nsd when queried with QTYPE=TXT or ANY:

And the trace seems to be:

Program received signal SIGSEGV, Segmentation fault.
0x0805c7e5 in query_get_dname_offset (query=0x9176c90, domain=0x9174bb4)
    at query.h:143
143 return query->compressed_dname_offsets[domain->number];
(gdb) where
#0 0x0805c7e5 in query_get_dname_offset (query=0x9176c90, domain=0x9174bb4)
    at query.h:143
#1 0x0805c8d0 in encode_dname (q=0x9176c90, domain=0x9174bb4) at packet.c:21
#2 0x0805ca46 in packet_encode_rr (q=0x9176c90, owner=0x91708dc, rr=0x9174b54)
    at packet.c:76
#3 0x0805cc09 in packet_encode_rrset (query=0x9176c90, owner=0x91708dc,
    rrset=0x9174b44, section=1) at packet.c:126
#4 0x0804a299 in encode_answer (q=0x9176c90, answer=0xbfbe71fc) at answer.c:76
#5 0x0805ffbe in answer_query (nsd=0x807f3e0, q=0x9176c90) at query.c:1204
#6 0x080605a6 in query_process (q=0x9176c90, nsd=0x807f3e0) at query.c:1353
#7 0x0806645a in server_process_query (nsd=0x807f3e0, query=0x9176c90)
    at server.c:1211
#8 0x08066ab5 in handle_udp (netio=0x9175c88, handler=0x9175d10,
    event_types=NETIO_EVENT_READ) at server.c:1408
#9 0x08058806 in netio_dispatch (netio=0x9175c88, timeout=0x0, sigmask=0x0)
    at netio.c:258
#10 0x08066875 in server_child (nsd=0x807f3e0) at server.c:1343
#11 0x08064506 in restart_child_servers (nsd=0x807f3e0, region=0x9170530,
    netio=0x9174c80, xfrd_sock_p=0xbfc055c8) at server.c:292
#12 0x08064e9a in server_start_children (nsd=0x807f3e0, region=0x9170530,
    netio=0x9174c80, xfrd_sock_p=0xbfc055c8) at server.c:567
#13 0x08065caa in server_main (nsd=0x807f3e0) at server.c:977
#14 0x0805ad33 in main (argc=0, argv=0xbfc05924) at nsd.c:1063

(gdb) print domain->number
$4 = 1852383333

Hi Stephane,

Since I cannot reproduce, it is not simply the TXT record itself. Can
you send me (offlist) the zonefile(s), config, and what OS/platform you use?

The error printed says that the memory database has been corrupted.

Best regards,
   Wouter

a message of 15 lines which said:

This zone file, which seems legal (two strings in one TXT record, see
RFC 1035, section 3.3.14 which says "one or more"):

TXT "Name of Facility or similar" "City, Country"

crashes nsd when queried with QTYPE=TXT or ANY:

OK, problem solved. This happened when running a recent version of the
nsd daemon with a database compiled by an old version of
zonec. Nothing in the database tells the daemon that the format is
different. TXT records are stored in an unexpected way => crash.

So, always check you use the right zonec. Its path seems hardcoded in
nsdc so setting PATH does not help.

[Analysis and solution by Wouter Wijngaards.]