Views causing zone transfer problems? RESOLVED

[Scott Lacy]

I needed to put a second IP on my master DNS server, and have the
internal and external zones send their notifies from different IPs via
notify-source.  On the secondaries, have the zones set up with masters
from the corresponding IP on the master.  Then set up the views
accordingly with the ACL excluding the external notification IP in the
internal view.

The ACLs were set up correctly, but it wasn't going to work with one
IP.  Adding the virtual IP on the master allows different notification
sources and changing the ACLs accordingly on the secondaries.

Thanks for your help everyone!



On 9/20/07, Chris Buxton <cbuxton at menandmice.com> wrote:
> The problem is, the notify packets are hitting the external view. Use
> a match-destination (check the spelling on that) statement in the
> slave's views, and make sure the master is notifying the correct
> slave interface.
>
> Chris Buxton
> Men & Mice
>
> On Sep 20, 2007, at 10:38 AM, Scott Lacy wrote:
>
> > So far, it seems to boil down to what view the slave has of the master
> > (68.143.210.80).  If the slave sees the master as external, then
> > external view zone transfers work.  If the slave sees it as internal,
> > then internal zone transfers work.
> >
> > I have transfer-source statements set up for each zone appropriately
> > (external interface for external view, internal interface for internal
> > view), yet the serial number it pulls is always dependent on what acl
> > the master server's ip address falls under on the slave (internal or
> > external).
> >
> > Any suggestions short of moving the master for one of the zones to
> > another IP?
> >
> > Thanks!
> >
> > On 9/20/07, Scott Lacy <eslacy at gmail.com> wrote:
> >> Hi all,
> >>
> >> I'm having an odd problem with zone transfers relating to views in
> >> Bind 9:
> >>
> >> I have a master with one interface, and a slave with two physical
> >> interfaces (10.30.80.5 and 68.143.211.2), one for each view (internal
> >> and external).  The problem I am having is that when I do a reload
> >> for
> >> one of my zones (regardless of whether it is internal or external),
> >> the slave is consistently querying serial numbers for the external
> >> view.  I think it's seeing the master as external, thus it is always
> >> querying the external zone's serial rather than the internal.  If
> >> I do
> >> it the other way, though, it would always query the internal zone's
> >> serial.  Am I going to need to set up a second IP on the master to
> >> get
> >> this working properly?  Conf files and logs follow.  I really
> >> appreciate any help/advice I can get.
> >>
> >> Master named.conf:
> >>
> >> options {
> >>         directory "/var/named";
> >>         query-source address * port 53;
> >>         allow-transfer { 10.30.80.5; 68.143.211.2; };
> >>
> >> };
> >>
> >> acl "internalnets" { !68.143.211.2; 10.0.0.0/8; 68.143.211.0/16; };
> >>
> >> view "internal" {
> >>
> >>         match-clients {
> >>                 internalnets;
> >>                 };
> >>
> >> (miscellaneous zone info here, pretty vanilla)
> >>
> >>
> >> view "external" {
> >>
> >> match-clients { any; };
> >> recursion no;
> >>
> >> (miscellaneous zone info here, pretty vanilla)
> >> }
> >>
> >>
> >>
> >> Slave named.conf:
> >>
> >> options {
> >>         directory "/var/named";
> >>         dump-file "/var/named/data/cache_dump.db";
> >>         statistics-file "/var/named/data/named_stats.txt";
> >>         notify no;
> >>         /*
> >>          * If there is a firewall between you and nameservers you
> >> want
> >>          * to talk to, you might need to uncomment the query-source
> >>          * directive below.  Previous versions of BIND always asked
> >>          * questions using port 53, but BIND 8.1 uses an unprivileged
> >>          * port by default.
> >>          */
> >>          // query-source address * port 53;
> >> };
> >>
> >> //68.143.210.80 is the master nameserver
> >> acl "internalnets" { !68.143.210.80; 10.0.0.0/8; 68.143.211.0/16; };
> >>
> >> view "internal" {
> >>         match-clients {
> >>                 internalnets;
> >>                 };
> >>
> >> a sample internal zone:
> >>
> >> zone "fubar.com" IN {
> >>         type slave;
> >>         masters { 68.143.210.80; };
> >>         transfer-source 10.30.80.5;
> >>         file "/var/named/internal/fubar.com";
> >> };
> >>
> >>
> >>
> >>
> >> view "external" {
> >>
> >> match-clients { any; };
> >> recursion no;
> >>
> >> a sample external zone:
> >>
> >> zone "fubar.com" IN {
> >>         type slave;
> >>         masters { 68.143.210.80; };
> >>         transfer-source 68.143.211.2;
> >>         file "/var/named/external/fubar.com";
> >> };
> >>
> >>
> >>
> >> If I increment the serial on the external zone on the master and
> >> reload via "rndc reload fubar.com IN external" on the master, the
> >> slave logs:
> >>
> >> Sep 20 09:18:28 slave-dns named[4951]: client 68.143.210.80#32963:
> >> view external: received notify for zone 'fubar.com'
> >> Sep 20 09:18:28 slave-dns named[4951]: zone fubar.com/IN/external:
> >> Transfer started.
> >> Sep 20 09:18:28 slave-dns named[4951]: transfer of 'fubar.com/IN'
> >> from
> >> 68.143.210.80#53: connected using 68.143.211.2#37095
> >> Sep 20 09:18:28 slave-dns named[4951]: zone fubar.com/IN/external:
> >> transferred serial 2007060415
> >> Sep 20 09:18:28 slave-dns named[4951]: transfer of 'fubar.com/IN'
> >> from
> >> 68.143.210.80#53: end of transfer
> >>
> >>
> >> If I increment the serial on the internal zone on the master and
> >> reload via "rndc reload fubar.com IN internal" on the master, the
> >> slave logs:
> >>
> >> Sep 20 09:19:45 slave-dns named[4951]: client 68.143.210.80#32963:
> >> view external: received notify for zone 'fubar.com'
> >> Sep 20 09:19:45 slave-dns named[4951]: zone fubar.com/IN/external:
> >> notify from 68.143.210.80#32963: zone is up to date
> >>
> >
> >
>
>