SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)

[Anne Bennett]

Tony Finch <dot at dotat.at> enlightens me thus:

> The difference between stub and static-stub is that stub works like the
> root zone hints, i.e. the servers in the zone override the ones that you
> configure for a stub zone, whereas the servers you configure for a
> static-stub zone override the servers in the zone.

... so, since I want my parent zone to be able to give me the
set of servers it wants me to use, I configured my resolver
to have (this snippet from "named-checkconf -p" to deal with
include files and such):

  zone "concordia.ca" {
        type stub;
        file "StubData/concordia.ca.SEC";
        masters {
                132.205.1.1 ;
                132.205.7.51 ;
        };
        multi-master yes;
  };

"named-checkconf" gave no errors.  I issued a "reconfig", again
no errors logged or reported.  I can confirm that the zone was
transferred correctly (showing me the internal view), because
I have "masterfile-format text" as a general option (small
enough number of zones that performance is not an issue, but
human ability to debug *is*), and "StubData/concordia.ca.SEC"
contains a perfectly normal-looking zone "stub":

----------------------------------------------------------
$ORIGIN .
$TTL 86400      ; 1 day
concordia.ca            IN SOA  ns1.concordia.ca. hostmaster.concordia.ca. (
                                2028969738 ; serial
                                43200      ; refresh (12 hours)
                                1800       ; retry (30 minutes)
                                2592000    ; expire (4 weeks 2 days)
                                1800       ; minimum (30 minutes)
                                )
                        NS      ns1.concordia.ca.
                        NS      ns2.concordia.ca.
----------------------------------------------------------

It all looks just peachy, but when I issued:
  dig @localhost -t ns concordia.ca.
it gave me a SERVFAIL.  I couldn't find anything abnormal
in the syslogs.  I can't for the life of my figure out why
it's unhappy.  How can I debug this?  Is it normal that a
zone could be badly enough out of whack to SERVFAIL, yet
the named would syslog nothing?

(I'm syslogging default "syslog_all", minus edns-disabled,
lame-servers, rpz, and unmatched.)


Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
anne at encs.concordia.ca                                    +1 514 848-2424 x2285