NS record question
bobvance at alumni.caltech.edu
Mon Mar 26 19:07:12 UTC 2001
Oops. Accidentally sent too soon :|
>There is no NOTIFY issue. Notifies get sent to slave servers, not to
>zones. This discussion was about omitting NS records for delegation
>child is hosted from the same server. Not a discussion about the NS
>residing and a zones apex.
My point was that if you had a secondary server for the sub-zone, which
would otherwise work correctly (even without the NS records) for lookup
requests to that sub-zone, but there were no NS records, then the
secondary would not get NOTIFYed when changes were made on the primary.
At least, I thought that was correct -- that the primary uses the NS
records to decide whom to NOTIFY.
Besides, you were the one that brought up secondary servers :)
Tks | <mailto:BVance at sbm.com>
BV | <mailto:BobVance at alumni.caltech.edu>
Sr. Technical Consultant, SBM, A Gates/Arrow Co.
Vox 770-623-3430 11455 Lakefield Dr.
Fax 770-623-3429 Duluth, GA 30097-1511
From: roy at node10c4d.a2000.nl [mailto:roy at node10c4d.a2000.nl]On Behalf Of
Sent: Monday, March 26, 2001 1:33 PM
To: Bob Vance
Cc: bind-users at isc.org
Subject: RE: NS record question
On Mon, 26 Mar 2001, Bob Vance wrote:
> I had noticed that creating a sub-zone on the same server without
> delegation worked in the simple environment of my home network with
> one nameserver. I later went ahead and did the delegation to itself
> when I realized my omission, but it got me to wondering about the same
> So I'm also trying to figure out exactly where it breaks down.
> A secondary server should be authoritative and he knows how to get
> transfers done, so he should be able to answer OK without NS records.
This is not so much a zone-transfer issue. He indeed should be OK when
asked for information from its zone. But consider the following:
3 nameservers: 188.8.131.52, 184.108.40.206 and 220.127.116.11
3 zones: "mil." "army.mil." and "navy.mil.", No NS records at .mil for
army.mil. and navy.mil.
18.104.22.168 is master for "mil."
22.214.171.124 is master for "army.mil."
126.96.36.199 is master for "navy.mil."
188.8.131.52 is slave for "mil."
184.108.40.206 is slave for "army.mil."
220.127.116.11 is slave for "mil."
18.104.22.168 is slave for "navy.mil."
When a resolve queries root for "ship.navy.mil.", root refers to
22.214.171.124 and 126.96.36.199 for the "mil." domain.
A resolver chooses on of those, say 188.8.131.52.
When a resolver queries 184.108.40.206 for "ship.navy.mil.", 220.127.116.11 wil not
refer to 18.104.22.168, there are no NS records for childzones in the .mil
because parent and child are hosted on the same server. Now, the
hangs in the blue, depressed and lonely, cause no-one can answer its
question. Even worse, it will get authoritative a "NXDOMAIN" back.
> Another server somewhere trying to get sub-zone.foo.com would be
> referred to the nameserver(s) for foo.com. -- but then he (or they)
> would know that they are authoritative for sub-zone.foo.com and should
> I guess without the NS records there would be a NOTIFY issue.
There is no NOTIFY issue. Notifies get sent to slave servers, not to
zones. This discussion was about omitting NS records for delegation when
child is hosted from the same server. Not a discussion about the NS
residing and a zones apex.
More information about the bind-users