Delegation of already loading zones?

Kevin Darcy kcd at chrysler.com
Mon Jun 8 19:04:09 UTC 2009


There's a standard that says *all* zones beneath the root should be 
delegated hierarchically. It's a very broad rule that doesn't depend on 
what you happen to be "loading" at any particular time on any particular 
server.

It may seem overkill now, if all of your nameservers slave all of your 
zones, but what if some day you want to set up a slave of example.com 
that does *not* happen to also be a slave of test.example.com? In the 
absence of those delegation records in its slave copy of the zone, it 
won't know that test.example.com exists. If any client queries such a 
nameserver for a test.example.com name, it'll get a "no such name" 
(NXDOMAIN) response.

It's good form, and a good habit to get into, to always delegate zones, 
even if the delegated zone is slaved on all of your (current set of) 
nameservers. Give yourself some flexibility and scalability for the future.

- Kevin

Todd Snyder wrote:
> Good day,
>
> Looking through configuration of one of my servers (ns01.local), I have
> example.com loading, and test.example.com loading.
>
> In example.com, someone has delegated test.example.com back to the
> server:
>
> test.example.com		IN	NS	ns01.local
>
> Since I am loading test.example.com specifically, that delegation
> appears redundant.  Are there cases where that delegation is required?
> Is there a standard that says I should do that for all zones I'm loading
> that are subzones of another zone I'm loading?  Is this just an oddball
> configuration that should be cleaned up?
>
> Thanks,
>
> Todd.
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>   




More information about the bind-users mailing list