Darcy Kevin (FCA)
kevin.darcy at fcagroup.com
Thu Aug 11 17:43:54 UTC 2016
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.
From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Bob McDonald
Sent: Thursday, August 11, 2016 1:14 PM
Cc: bind-users at isc.org
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 (example.com<http://example.com>.)
example.com<http://example.com>. has an NS record that points to server B and delegate child.example.com<http://child.example.com>. (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 example.com<http://example.com>. from server A (and the associated NS record delegating child.example.com<http://child.example.com>. to server B)
Server C is at another site at the same company as server A
Currently, clients sending queries for domain child.example.com<http://child.example.com>. to server A get good results.
However, clients sending queries for domain child.example.com<http://child.example.com>. 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 child.example.com<http://child.example.com>. on server B, can I use forwarders for child.example.com<http://child.example.com>. on server C to point at server A for resolution of child.example.com<http://child.example.com>.? (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 conundrum.com<mailto:matt at conundrum.com>> wrote:
On 11 August 2016 at 09:13, Bob McDonald <bmcdonaldjr at gmail.com<mailto:bmcdonaldjr at gmail.com>> 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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users