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-us...@isc.org
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-boun...@lists.isc.org] On Behalf Of Bob
McDonald
Sent: Thursday, August 11, 2016 1:14 PM
Cc: bind-us...@isc.org<mailto:bind-us...@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.
Bob
On Thu, Aug 11, 2016 at 11:52 AM, Matthew Pounsett
<m...@conundrum.com<mailto:m...@conundrum.com>> wrote:
On 11 August 2016 at 09:13, Bob McDonald
<bmcdonal...@gmail.com<mailto:bmcdonal...@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.
Regards,
Bob
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
