The bottom line is: any resolver which is using iterative resolution (as
opposed to just forwarding) to resolve names in a zone, needs to be able to
talk to at least *some* of the published nameservers for the zone, or to
“override” the regular referral-chain using something like a “stub” zone. But,
be aware, even if you define “stub”, those queries are going to be
*non-recursive* (RD=0), so they are not forwardable. In other words, you can’t
stub part of the way, and forward the rest of the way. That simply doesn’t work.
If you want to “slingshot” your resolution through another box, then really
your *only* choice is recursive resolution, and in BIND terms, that implies
defining one or more “forwarders”.
That being said, it’s a terrible way to do things. The firewalls should be
opened up so that nameservers can talk to each other directly. Direct
nameserver-to-nameserver communication is the assumption upon which the DNS
resolution architecture is based. Forwarding is just an ugly kludge to deal
with connectivity challenges.
Another option to consider: why don’t you make your “parent” nameservers
authoritative (e.g. by setting up master/slave) for the “child” zone as well,
and publish them in the NS records of the zone? That would be better than
forwarding. If you can make them authoritative, but for some reason *cannot*
publish them in the NS records, then at least that gets you far enough to be
able to use a “stub” zone on the “third site”.
- Kevin
[FCA_Pantone_email]
----------------------------------------------------------------------
Kevin Darcy
NAFTA Information Security Projects
FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA
Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matthew
Pounsett
Sent: Thursday, August 11, 2016 12:52 PM
To: Bob McDonald
Cc: bind-us...@isc.org
Subject: Re: Delegation questions
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
