clueing in TLD registries for delegations to non-BIND servers

[please do not explicitly send copies of followups to me]

Brad Knowles wrote/schrieb/scripsit:
> 	In which case, it is impossible to configure nsd to "do the right 
> thing", even if this feature wasn't turned on by default.  If you 
> don't configure the root zone, then you get SERVFAIL instead.  If you 
> do, then you get bogus information.  We need a third way, one that 
> gives us the right answer.

There is no One True Lame Delegation Answer. Servers have always re-
sponded differently when a delegation was lame. For example, suppose
I had configured the cabal1.net nameservers like:

  $ORIGIN cabal1.net.
  ; SOA yadda yadaa
  foobar	NS	k
  k		A	193.0.14.129
  ; address of k.root-servers.net

Then, when a client had learned that k.cabal1.net at address 193.0.14.129
was supposed to know about foobar.cabal1.net, this nameserver, when asked
for the address of foobar.cabal1.net, would respond with an authoritative
referral to the net servers. The client would notice that this was a lame
delegation and then throw away the information received, because it would
be vulnerable to poisoning otherwise.
Similarly, BIND servers usually have a root.cache file, even when they
are not acting as recursive resolvers. As a consequence, under certain
circumstances, all they could do when asked for information they did
not have was to return their knowledge of the root servers. They would
do this non-authoritatively because the root.cache information is not
their authoritative knowledge. No matter if this is even an authorita-
tive answer (i.e. the server had a local root zone configured) or not,
the client will notice that the delegation is lame and then throw away
the (possibly bogus) information.
So, there is absolutely nothing magic about returning a referral to the
roots. Many possible -- and correct -- responses to a lame delegation
exist and one of them is to simply return SERVFAIL for lack of better
knowledge.

-Stefan
-- 
 junior guru                               SP666-RIPE  SMP@{IRC,SILC}