clueing in TLD registries for delegations to non-BIND servers

 * > 	It should be configured to hand out a referral.
 * 
 * if you do not include a hints file in nsd's database, it will return
 * SERVFAIL.
 * 
 * > >  bind9 will reply with REFUSED if the hints file is missing and it is
 * > >  configured to be authoritative only.
 * >
 * > 	Are you sure?  For which version of BIND 9?  My understanding is
 * > that they had a pre-compiled list of the root servers built into the
 * > source code, and that this would be used to generate the initial
 * > "hints" zone, thus allowing you to avoid having this file.  Indeed, I
 * > wouldn't be surprised at all if the built-in data over-rode the file,
 * > but maybe that's going too far.
 * 
 * if you set up bind9 with a authoritative-only view it will return REFUSED.
 * in a "normal" configuration, it will use pre-compiled root-hints.
 * 


Also see Appendix B in the REQUIREMENTS doc in the distribution. This
argues why a SERVFAIL is returened if there is no hints file present.

"
B.1. Returning the root delegation when no answer can be found

   From RFC1034/1035 it is not obvious if returning a root delegation
   is a (non-)requirement for authoritative servers.

   We have decided not to implement a root-hints since an
   authoritative server should in normal circumstances only receive
   queries for which the server is authoritative.
   
   Also see RFC 1123 section 6.1.2.5.

   Whenever an answer cannot been provided we return a SERVFAIL. It
   has been argued that this is a policy decision and thus a REFUSE
   should be returned. However, in the spirit of RFC1034/1035 a server
   should return cached data, if that cache cannot be reached a SERVFAIL
   is an appropriate response.

   Also see the discussion on the 'namedroppers list' Starting April
   2002 with subject "name server without root cache "
   (ftp://ops.ietf.org/pub/lists/)

'


--Olaf