DNS views and zone transfers

[Bob Harold]

On Thu, Aug 25, 2016 at 12:56 PM, project722 <project722 at gmail.com> wrote:

> I have successfully setup TSIG keys for "views" using a DNS master/server
> pair. Zone transfers are working as expected between the 2 servers for each
> view. Before we go live into production with this I need some clarification
> on a couple things. Our prod servers are also allowing zone transfers to a
> few other servers besides the slave server. We have an acl setup that looks
> similar to this:
>
> other_xfer_allowed_ns {
> x.x.x.x; // This is our Secondary DNS server
> 127.0.0.1; // localhost can make zone transfers
> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> }; // end of "other_xfer_allowed" ACL
>
> And in the "allow transfer" statement we have included that ACL. My
> question is:
>
> Now that we are using TSIG, will I need to get with the admins of all
> these other servers and provide them my TSIG key so they can request zone
> transfers? I would think somehting like that needs to be done since it was
> required to be configured on slave server, but I am not sure.
>

No, if you allowed the IP range in your ACL, they don't need the TSIG key.
It might be more secure to hand out TSIG keys and remove the IP ranges from
the ACL, so only the TSIG key will allow transfers, since IP addresses are
easier to spoof, but since a zone transfer requires TCP, spoofing is not
likely.

The TSIG key was required on the slave in order to get the right view, if I
remember correctly.


>
> Next,
>
> I setup views so that clients on the "internal" network when requesting a
> record would be presented with different records than clients on the
> outside. And at the moment there is only one zone that is required to have
> different records. However, It is my understanding that since views are
> based off source IP's, if I was to ONLY include that one zone in my
> "internal" view, if a record was requested for another zone from that same
> IP, they would probably get an nxdomain answer since that IP is limited to
> that one view.
>
> So, my question is, will I need to include all zones in both views so that
> all clients can get results, even though I would only have (at the moment)
> one zone that points to two different zone files? All others in both views
> would point to the same zone file, unless of course there is another zone
> we need to present a different view to for internal clients.
>

You have a few choices:
- Copies of zones in both views.  More memory used, more zone transfers,
but probably safest and best performance.  This is what I do.  The zones in
the two views will need to be in separate files, if they are "slave" zones,
otherwise Bind will get confused and complain, because it does not realize
that two different views are trying to write the same file.
- One view could 'forward' to the other view for zones it does not have.
(Doubles the query logging, if you have that turned on.)
- Views could do normal recursion for some zones if they can reach the
servers listed in the NS records and get the info from there.


>
> Now, last question.
>
> I have a concern about the allow-query statement. On our production server
> we have an ACL list we'll call it "trusted".
> We have an allow query statement in the global options to only allow
> queries from IP's in the trusted ACL. However every one of our zone entries
> in the conf file also has an "allow-query { any; }; statement. Doesn't that
> defeat the purpose of have a "trusted" ACL for queries? Is this bad design?
>

Seems like the 'any' would override the 'trusted'.  Probably not what you
wanted.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160830/224185bd/attachment.html>