<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 25, 2016 at 12:56 PM, project722 <span dir="ltr"><<a href="mailto:project722@gmail.com" target="_blank">project722@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">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:</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div>other_xfer_allowed_ns {</div><div>x.x.x.x; // This is our Secondary DNS server</div><div>127.0.0.1; // localhost can make zone transfers<br></div><div>x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers</div><div>x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers</div><div>x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers</div><div>x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers</div><div>}; // end of "other_xfer_allowed" ACL<br></div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">And in the "allow transfer" statement we have included that ACL. My question is:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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. </div></div></blockquote><div><br>No, if you allowed the IP range in your ACL, they don't need the TSIG key.<br></div><div>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.<br><br></div><div>The TSIG key was required on the slave in order to get the right view, if I remember correctly.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Next, </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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. </div></div></blockquote><div><br></div><div>You have a few choices:<br></div><div>- 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.<br></div><div>- One view could 'forward' to the other view for zones it does not have.  (Doubles the query logging, if you have that turned on.)<br></div><div>- 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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Now, last question. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I have a concern about the allow-query statement. On our production server we have an ACL list we'll call it "trusted". </div><div style="font-size:12.8px">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?</div></div></blockquote><div><br></div><div>Seems like the 'any' would override the 'trusted'.  Probably not what you wanted.</div></div><br>-- <br></div><div class="gmail_extra">Bob Harold<br><br></div></div>