Delegation questions

[Darcy Kevin (FCA)]

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.darcy at fcagroup.com

From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Matthew Pounsett
Sent: Thursday, August 11, 2016 12:52 PM
To: Bob McDonald
Cc: bind-users at isc.org
Subject: Re: Delegation questions



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.




Regards,
Bob

_______________________________________________
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>
https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160811/e5bbb98e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3764 bytes
Desc: image001.jpg
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160811/e5bbb98e/attachment-0001.jpg>