Delegation questions

Darcy Kevin (FCA) kevin.darcy at
Thu Aug 11 17:50:55 UTC 2016

Sorry, I left out the option of fixing the firewall rules.

Depending on your performance/resilience requirements, available bandwidth, latency, query patterns, etc. this may or may not be preferable to slaving the zone to your site. It’s hard to say without knowing a lot of details about your environment.

In any case, multi-hop forwarding is always the least-preferred option.

                                                                                                                                                                - Kevin

From: Darcy Kevin (FCA)
Sent: Thursday, August 11, 2016 1:44 PM
To: bind-users at
Subject: RE: Delegation questions

No, you would never get rid of a valid delegation of a child zone; why *reduce* the resolvability of that zone? Whatever you do to get around this connectivity issue would be *in*addition*to* the delegation, not as a replacement for it.

That having been said, I outlined your options in a previous post:

·         If you can make something on your site authoritative for the zone, then do that. That gives you more options (stub zone, multi-hop slaving, or – if you can convince the owners to publish appropriate NS records – regular iterative resolution will work without any special named.conf configuration at all).

·         If you can’t make *anything* at your site authoritative for the zone, then your only option is for your servers that *don’t* have connectivity to a source of resolution for the zone, to forward to one or more servers that *do* have the necessary connectivity. But now we’re talking about multi-hop recursive resolution, and that’s definitely sub-optimal.

- Kevin

From: bind-users [mailto:bind-users-bounces at] On Behalf Of Bob McDonald
Sent: Thursday, August 11, 2016 1:14 PM
Cc: bind-users at<mailto:bind-users at>
Subject: Re: Delegation questions

Let me be a bit more clear...
This is strictly internal. There are no external clients or servers involved. All three of the servers have recursion turned ON.
Server A has a domain (<>.)<>. has an NS record that points to server B and delegate<>. (yes there's really two, this is just an example)
Server B is at another company. (probably connected via some sort of IPSEC tunnel)
Server C has a slave copy of<>. from server A (and the associated NS record delegating<>. to server B)
Server C is at another site at the same company as server A
Currently, clients sending queries for domain<>. to server A get good results.
However, clients sending queries for domain<>. to server C get SERVFAIL because server C has no access to server B. (I'm guessing there is a firewall issue)
The question is if I get rid of the delegation and put in a stub zone on server A pointing to<>. on server B, can I use forwarders for<>. on server C to point at server A for resolution of<>.? (Will server A get answers directly from server B or will server A simply refer me to server B?)
Hope that's clearer.

On Thu, Aug 11, 2016 at 11:52 AM, Matthew Pounsett <matt at<mailto:matt at>> wrote:

On 11 August 2016 at 09:13, Bob McDonald <bmcdonaldjr at<mailto:bmcdonaldjr at>> wrote:
I have a child domain that is delegated to a second site. Pretty straightforward situation. In the parent zone I have NS records that point to the DNS servers at the second site.
The issue comes up when a slaved copy of the parent domain is running at a third site and that third site doesn't have a rule in their firewall allowing DNS access to the second site (where the child domain is delegated).
The question is this; can I use stub zones to reference the child domain on the master server (instead of delegation) and the use forwarding at the third site to direct queries for the child domain through the master server?
I hope the picture I've tried to describe is somewhat clear.

If the setup is exactly as you describe, then there's probably no reason for a name server authoritative for the parent zone to ever need to contact a server authoritative for the child zone.  Delegation from A to B doesn't imply direct communication between A and B.

That said, you never know where on the Internet queries for a zone will arrive from.  If you want the Internet at large to be able to resolve names in your zone, then you can't firewall yourself off from parts of the Internet.

If any of the servers in this scenario are also acting as recursive servers, then you have the same problem;  you never know where on the Internet an authoritative server you need to speak to is going to be, so you can't firewall your recursive server off from speaking to parts of the Internet and expect it to work reliably.


Please visit to unsubscribe from this list

bind-users mailing list
bind-users at<mailto:bind-users at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the bind-users mailing list