2

Running Bind 9.8.2. 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 {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Corporate server farm range is allowed to make 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 something like that needs to be done since it was required to be configured on slave server, but I am not sure.

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.

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 "allowed". We have an allow query statement in the global options to only allow queries from IP's in the allowed 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 an "allowed" ACL for queries? Is this bad design? Doesn't the zone statement take precedence over the global statement?

1 Answer 1

3

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 something like that needs to be done since it was required to be configured on slave server, but I am not sure.

First of all, regarding "provide them my TSIG key": No, it doesn't make much sense to just generate one single key and share it with everyone involved in your setup.
I would say create one key per party, you can have as many keys as you want after all. This way you can give different access to different parties and revoke one party's access without revoking everyone's access.

Also, using TSIG for some things does not necessarily imply using TSIG for all things (although it is often preferable), it is possible to mix IP-based and key-based access control if that works for your scenario.


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.

Every query will hit only one view (the first view that matches).
The implication is that if the data is not available in the view that a client hits with their queries, either in a zone in that view or through recursion (if recursion is available to the client and they request it), they cannot get at that data.

It's entirely possible that you will need more zones duplicated between views.


I have a concern about the allow-query statement. On our production server we have an ACL list we'll call it "allowed". We have an allow query statement in the global options to only allow queries from IP's in the allowed 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 an "allowed" ACL for queries? Is this bad design? Doesn't the zone statement take precedence over the global statement?

Yes, an allow-query specified in a zone will override the global allow-query value. For queries that do match your zones this means that the global setting is not used, however if recursion is enabled then you are also dealing with queries that do not match any of your zones.

Please see the allow-* settings in the manual for how these settings interact.

2
  • I've updated my question to include NOT forcing these other servers to use a key and how to set that up.
    – user53029
    Aug 25, 2016 at 21:57
  • nvm. I got it figured out.
    – user53029
    Aug 25, 2016 at 22:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .