bind-9.4.0 bug, assertion failed, signed zone

2 msg	Compiling with large file support
1 msg	SQLite SDB
3 msg	plz review 'dnscap' before i freeze its UI
13 msg	Resolv local network names [Newbie question]
2 msg	Upgrading Bind-8.2.2-P5 to 8.4.7
2 msg	BIND (8) Solaris to AIX (BIND 9) & Will sta...
2 msg	nsupdate .jnl files and flushing
1 msg	Francisco Raul Collet Silva/Safra está ausente ...
4 msg	Ignoring out-of-zone data
11 msg	intelligent NAMED
7 msg	log rotation
5 msg	High load on primary
2 msg	one domain is dig from one server but not with ...
2 msg	expiring secondary zones and parent delegation ...
7 msg	DNS timeout problems
4 msg	Can DNAME records be deployed in the wild?
3 msg	whois
3 msg	BIND Files DB-000
5 msg	dig on Windows

bind-9.4.0 bug, assertion failed, signed zone
\ Shumon Huque (29 Apr 2007)
. \ Evan Hunt (29 Apr 2007)

Subject:	bind-9.4.0 bug, assertion failed, signed zone
Group:	Bind-users
From:	Shumon Huque
Date:	29 Apr 2007

I think I've encountered a bug in bind-9.4.0. I can reliably get it to
abort with an assertion failure by querying for certain records in a
signed zone. syslog reports:

named[14551]: db.c:814: REQUIRE(dns_db_iszone(db) == isc_boolean_true) failed
named[14551]: exiting (due to assertion failure)

The zone passes consistency checks with named-checkzone. The problem
seems to be related to recursive queries for a delegation record similar
to:

subzone.example1.com IN NS blah.example2.com

The assertion failure happens when I first issue a recursive query for
"subzone1.example.com NS" (causing named to recurse for the A record to
insert in the additional section), followed by a recursive query for
subzone1.example.com RRSIG. The name has one RRSIG covering it's NSEC RR.
The sequence of queries was generated by a zone walking program.

No failure happens if I issue non-recursive queries, or if I issue
recursive queries from clients that are not allowed to cause recursion
(eg. by not matching the allow-query-cache and allow-recursion ACLs).

I am hesitant to post the actual records that cause the problem on the
list, because arbitrary clients might be able to crash my nameserver.
But I'd be happy to provide them (and the zone contents) via e-mail to
anyone willing to look into the problem.

A stack backtrace shows the following:

[1] __lwp_kill(0x0, 0x6, 0x0, 0xff03c000, 0x56f95c, 0x56f964), at 0xff020218
[2] raise(0x6, 0x0, 0xfef1e8d8, 0x56f988, 0x56f98c, 0x0), at 0xfefd0c80
[3] abort(0x582e68, 0x56ac60, 0x566460, 0xfffffffb, 0x484fc4, 0x49cadc), at 0xfefb6e98
=>[4] assertion_failed(file = 0x49cadc "db.c", line = 814, type = isc_assertiontype_require, cond = 0x49cae4 "dns_db_iszone(db) == isc_boolean_true"), line 159 in "main.c"
[5] dns_db_getoriginnode(db = 0x8d4ee0, nodep = 0xfef1ecd4), line 814 in "db.c"
[6] query_addsoa(client = 0x71eb90, db = 0x8d4ee0, version = (nil), zero_ttl = isc_boolean_false), line 2038 in "query.c"
[7] query_find(client = 0x71eb90, event = (nil), qtype = 46U), line 4221 in "query.c"
[8] ns_query_start(client = 0x71eb90), line 4583 in "query.c"
[9] client_request(task = 0x59d5a8, event = 0x722c80), line 1741 in "client.c"
[10] dispatch(manager = 0x589ec0), line 867 in "task.c"
[11] run(uap = 0x589ec0), line 1010 in "task.c"

Thanks for any help!
--Shumon.