Justin Dixon sent an email suggesting: Use TSIG to select the correct view...Example at below URL from the BIND FAQ on www.isc.org.
https://www.isc.org/node/282 I didn't actually do the TSIG setup (need to do that one of these days...). However, the rest of the link indicated steps close to what I had done. I had an internal facing NIC with an alias IP already as well as an external (internet) facing NIC. I did not have the "notify-source" statement however so added that. Even after that I still had issues. Robert Davis sent an email suggesting: Read Cricket Liu's _DNS & BIND Cookbook_, "3.19: Setting Up a Slave Name Server for a Zone in Multiple Views". I found an online preview that included that section. After reviewing that and my named.conf files a few times I realized I'd set "allow-transfer { watercom; };" in each of my zone definitions and watercom was an acl for the primary (rather than the alias) IPs of the internal facing NICs. I created a new ACL For the alias IPs and removed this from each of the zones. I then added the original line to the external view and a new line saying "allow-transfer { watercomaliasips; }; to the internal zone. This worked fine. This morning I found that I'd accidentally disabled recursion for internal users because the link above seemed to suggest query-source for view should be the same IP as the transfer-source and notify-source. It turns out that is not correct. The query-source is the IP in the server that queries others (e.g. queries the root servers) so should be the external facing NIC rather than either the primary or alias IP on the internal facing NIC. After correcting that recursion worked for internal users. (External users can't do recursion because I'd explicitly turned that off in the global options last year.) Thanks Robert and Justin for taking the time to respond. ________________________________ From: Jeff Lightner Sent: Friday, March 13, 2009 4:15 PM To: bind-users@lists.isc.org Subject: Internal and External view on same slave server? We recently decided to create internal and external views for some zones. This worked fine on the master server. However, initiating zone transfer on slave from master it loaded all the zone names I'd created but put exactly the same information into both sets. This information was for the internal view which is the first one in both named.conf files. On doing some research I saw mention of needing to configure different slaves for internal and external view. This mentioned need for separate IPs. Since I can't just build a new slave server I instead opted to create an alias IP using the same NIC as primary IP. Of course the question there is how to force the transfer request to come from the primary IP or the alias IP dependent on which view the zone is in. Further research suggested use of the transfer-source option in the view to specify the IP to be used to request the transfer. I added this. Also I already had allow-transfer for the primary IP. I left that in the external view zone entries in named.conf. I then created a separate allow-transfer in the internal view zone entries to use the alias IP. On checking logs I'm seeing REFUSED from the master in the slave's logs but I am seeing the slave's alias IP making the request on the master. I don't see the slave's primary IP making requests on the master. Is what I'm trying to do possible? If not can someone explain why? Given that I'm restricting the IP allowed to transfer and the IP requesting the transfer it seems this should be working. At worst it seems it should only have quit working for one view but its not working for either one. If it is possible can someone let me know how they've achieved it? Please consider our environment before printing this e-mail or attachments. ---------------------------------- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. ----------------------------------
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
