Internal and External view on same slave server? - RESOLVED

[Jeff Lightner]

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 at 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.
----------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090317/4bd76ae4/attachment.html>