Root server cannot be a forwarder?

[Kevin Darcy]

April wrote:
> Joseph S D Yao wrote:
>   
>> On Wed, Oct 18, 2006 at 09:43:51AM -0700, yinzhang57 at yahoo.com wrote:
>>     
>>> Heard that on a BIND root server, recursion is disabled and it will not
>>> do recursion, therefore cannot be a forwarder?
>>>       
>> Good heavens, much more heat than light on this one!
>>
>>
>> BIND is software that implements DNS, and it is written to allow people
>> to configure it in quite a variety of different ways.
>>
>> I should note that recursion and forwarding are two completely different
>> things.
>>
>> A name server may be configured to be an authoritative server for the
>> root domain (".") or not - or to be so for some queries but not for
>> others.  It may be configured to be a recursive resolver or not, or only
>> for a certain set of queries.  It may be configured to forward certain
>> queries to certain other name servers, or all queries to certain other
>> name servers, or none, and differently for different sets of queries.
>> So we see that these three attributes:
>> 	- authoritative server for the root domain (".")
>> 	- can recursively resolve
>> 	- can forward queries to other configured servers
>> are not only completely independent of each other, but also may be
>> independently adjusted depending on the queries.
>>
>> But this is only the tool.  There is also policy to consider!
>>
>> If we actually are talking about root name servers, which is exactly
>> what the above question asks, but which certain eminent and most worthy
>> personages contest, there is an RFC 2870 which describes root name
>> server operational requirements.  It falls into the set of RFCs also
>> called Best Current Practices (BCP 40).  Although it is not explicit
>> about which internet it is discussing, it is nearly certain that it is
>> intended for the public Internet.  Other internets may wish to choose
>> useful parts from it for their own root servers.
>>
>> Among other things, this RFC advises:
>>
>>    2.5 Servers MUST provide authoritative responses only from the zones
>>        they serve.  The servers MUST disable recursive lookup,
>>        forwarding, or any other function that may allow them to provide
>>        cached answers.  They also MUST NOT provide secondary service for
>>        any zones other than the root and root-servers.net zones.  These
>>        restrictions help prevent undue load on the root servers and
>>        reduce the chance of their caching incorrect data.
>>
>> If this is in fact the type of thing about which you are asking, you may
>> wish to refer to this document at
>> <http://www.rfc-editor.org/rfc/rfc2870.txt> or one of the many other
>> places at which you will find this document.  Note that some of this is
>> dated, and may need explanation by people who are experienced with the
>> current way of DNS, such as Paul Vixie, Mark Andrews, Jim Reid, Barry
>> Margolin, Kevin Darcy, or several others who just weren't on the page I
>> happened to pull up.
>>
>>
>> --
>> Joe Yao
>> -----------------------------------------------------------------------
>>    This message is not an official statement of OSIS Center policies.
>>     
>
> Thanks Joe.
>
> My question is not about policies as the DNS RFC mentioned, but related
> to the BIND implementation. Does the behavior of a BIND server change,
> when it is configured to be authoritative to the root zone?
>
> Based on what suggested here, as every piece is independent, the
> behavior will not change - hope my interpretation is correct. However,
> this is different from what I gatherd from the others.
>   
For the third or fourth time, configuring a BIND instance (or view) as 
authoritative for the root zone does *not* change the default setting of 
recursion yes/no.

Being authoritative for the root zone, however, puts limitations on the 
instance's ability to be a forwarder, since it can't "forward by 
default". This is because anything that "defaults" would be considered 
to be in the root zone, and since it's authoritative for the root zone, 
it would answer from that instead of forwarding.

Is it clear now? You can be both a root server and a forwarder, but your 
forwarding would need to be limited and specific. You can't be a 
"general" forwarder.

Why on earth someone would want to combine those functions, I have no 
idea. Worse come to worst, just set up separate views for the separate 
functions (assuming you can differentiate your clients somehow).

                                                                         
                                 - Kevin