clueing in TLD registries for delegations to non-BIND servers

On 08.02 23:33, Bruce Campbell wrote:
> On Sat, 8 Feb 2003, Brad Knowles wrote:
> 
> > At 7:47 PM +0100 2003/02/07, Jakob Schlyter wrote:
> >
> > >  if you do not include a hints file in nsd's database, it will return
> > >  SERVFAIL.
> 
> Actually (having burnt my fingers on this one), you really do not want to
> configure any zones into nsd (including '.') unless you are authoritative
> for those zones.  Since nsd is (by design) an authoritative-only
> nameserver, any zones configured will be answered authoritatively.
> 
> > 	Are you saying that it will hand out a referral if this
> > information is configured into the database?
> 
> nsd will return authoritative NXDOMAIN with authority of '.' on unknown
> queries if '.' is configured.  This is probably not what is wanted in most
> cases.

If you load a root zone into a name server and tell it to be authoritative for
it (default in nsd) it serves that zone authoritatively. Anything else 
would be strange, wouldn't it? So if a TLD is not in that zone the only
correct answer is an autoritative NXDOMAIN.

(If you take a hints file, add a SOA record, and then tell NSD it is a
root zone, the outcome is the same. How can the poor program know it
is really a hints file with a SOA added and not a zone file? ;-()

The next release of nsd (actually zonec) will require a special flag 
to allow compiling the '.' zone. Just another feeble attempt to prevent
bullets in feet caused by the preconceptions that all name servers need
a hints file to work. 
I hope it will be more successful than all the other
"Do you really want to do this [y/n]?" questions.

Imho non-recursing name servers should not answer anything they are not
authoritative for. Such queries should not go to them and being 
extra helpful without knowing authoritative information is never good. 
This is why I always ask more than one person for directions especially
if the first person I asked is very nice and helpful.
It is better to admit one does not know. 
(RFC 1123 section 6.1.2.5 codifies this)

Daniel