Re: Help requested for zone delegation using DLZ

"Michael Kirkpatrick" <[email protected]> Wed, 4 Nov 2009 22:07:49 -0600
Newsgroups gmane.network.dns.bind9.dlz
Message-ID <055001ca5dcd$8a1ac710$bdecfea9@Main>
Here is what I have found with sub delegation.

All requests initially go to the name servers of example.com.
They pick up the name servers to look at for us.example.com.
Then they query the name servers of us.example.com.  Basically a little
recursion is going on.

I can't stress this enough.  Always follow the name with a "period".
It dawned on me when I looked over your settings again that you had entries
as example.com without a trailing period.  In bind it interprets that as
example.com.example.com if you don't have that period.  Basically shorthand
so you can just enter @ or www without having to spell out the entire domain
name.  

On server A:
You need an NS record pointing to server B for us.example.com

On Server B:
Don't forget to have the same NS record pointing to itself.

Basically the NS records on server A and server B are going to be the same
for us.example.com.

This is how I sub delegated one of my domains (Raw File Format):
Primary: ns1.example.com (10.0.0.1)
Secondary: ns2.example.com (10.0.0.2)
Sub Primary: sub1.example.com (192.168.0.1)
Sub Primary: sub2.example.com (192.168.0.2)

Primary & secondary servers:
@ IN  SOA  example.com.  ns1.example.com.  hostmaster.example.com. (.....)
@  NS  ns1.example.com.
@  NS  ns2.example.com.
us    NS  sub1.example.com.
us    NS  sub2.example.com.
sub1  A   192.168.0.1
sub2  A   192.168.0.2
ns1   A   10.0.0.1
ns2   A   10.0.0.2


Sub Primary (192.168.0.1) & Secondary (192.168.0.2) servers:
@ IN SOA us.example.com. sub1.example.com.  hostmaster.example.com. (.....)
@     NS  sub1.example.com.
@     NS  sub2.example.com.
@     A  127.0.0.1
www   A  127.0.0.2


Hopefully this will shed a little light on what you may be doing wrong.
If you do an nslookup on www.us.example.com and get 127.0.0.2 back, then the
sub delegation is working properly.  Make sure you do the nslookup against
ns1.example.com or ns2.example.com.  That will force nslookup to recurse to
sub1.example.com or sub2.example.com for the final answer. 

Dig on the other hand will often refer to the root servers on the web and if
you are tinkering around with this and literally using example.com then
there is a good change dig will hit the true name servers for that domain
instead of your local domain servers.  Also depending on your distribution
dig may not be set up to do automatic recursion by default.  You may have to
supply the proper flag to get dig to recurse.


On Wed, Nov 4, 2009 at 1:16 PM, Mike Toler <[email protected]>
wrote:
> Well, still no luck.
>
<SNIP>


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july