A Zone Transfer Question

John Miller johnmill at brandeis.edu
Fri Feb 19 22:45:26 UTC 2016


Regardless of how NOTIFY's behaving (it's a nice-to-have, not a must),
you need to make sure zone transfers from master to slave are working.
If you can run

dig @10.4.1.101 rack1.com AXFR

from your slave, then zone transfers of rack1.com are working from
master to slave, and your issue lies somewhere in your config - a
serial number didn't get updated on the master?  Zone changes didn't
get saved?  Didn't actually reload the zone after editing the zone
file?

If your dig command doesn't work, then it might be either a config
issue or a networking issue - you'll have to figure out which.

And if you actually want people to use your zone or you want NOTIFY
working, two NS records (and possibly glue) are really a must.

Don't worry about dynamic updates at this point: make sure that when
you edit a zone file manually, increment the serial number, and reload
the zone on the master, that the slave fetches the zone within the
refresh interval.  Gotta walk before you run ;-)

John

On Fri, Feb 19, 2016 at 3:56 PM, David Li <dlipubkey at gmail.com> wrote:
> Hi John,
>
> Sorry I missed the options. I attached them below.
>
> I didn't have allow-transfer, allow-notify and also-notify. I only
> have allow-query. I read somewhere that NOTIFY is automatic for all
> slave zones. Is this the problem?
>
>
>
> For VM1 named.conf
>
> options {
>
>     directory "/var/named";
>     allow-query {
>        10.4.1/24;
>        127.0.0.1;
>     };
>
> };
>
> For VM2 named.conf
>
> options {
>
>     directory "/var/named";
>     allow-query {
>        10.4.3/24;
>        127.0.0.1;
>     };
>
> };
>
> On Fri, Feb 19, 2016 at 12:33 PM, John Miller <johnmill at brandeis.edu> wrote:
>> Hi David,
>>
>> Something I'm not seeing in your config is an options {} block that
>> lays out your defaults for allow-transfer, allow-notify, also-notify,
>> etc.  Those are important things to know when it comes to
>> troubleshooting zone transfer issues.  Unless you've got a specific
>> reason for not doing so, please include your entire named.conf file -
>> it'll make life much easier.
>>
>> And if you've solved things already - ignore!
>>
>> John
>>
>> On Fri, Feb 19, 2016 at 2:01 PM, David Li <dlipubkey at gmail.com> wrote:
>>> Hi John,
>>>
>>> Here are the files. They are all internal zones without any references
>>> to external name servers.
>>>
>>> VM1:
>>> ====
>>>
>>> named.conf:
>>> -------------
>>>
>>> #
>>> # master (on VM1)
>>> #
>>> zone "rack1.com" {
>>>     type master;
>>>     file "/var/named/db.rack1.com";
>>>     allow-update { key rndc-key-rack1; }; # For DHCP dynamic update
>>> };
>>>
>>> #
>>> # slave (on VM2)
>>> #
>>> zone "rack3.com" {
>>>     type slave;
>>>     file "/var/named/bak.rack3.com";
>>>     masters { 10.4.3.101; }; #VM3 named IP
>>> };
>>>
>>>
>>> zone file:
>>> /var/named/db.rack1.com
>>> -------------------------
>>>
>>> $ORIGIN .
>>> $TTL 907200     ; 1 week 3 days 12 hours
>>> rack1.com               IN SOA  dnsserver1.rack1.com. admin.rack1.com. (
>>>                                 8          ; serial
>>>                                 60         ; refresh (1 minute)
>>>                                 60         ; retry (1 minute)
>>>                                 604800     ; expire (1 week)
>>>                                 3600       ; minimum (1 hour)
>>>                                 )
>>>                         NS      dnsserver1.rack1.com.
>>> $ORIGIN rack1.com.
>>> dnsserver1              A       10.4.1.101
>>>
>>> $TTL 3600       ; 1 hour
>>> node1                   A       10.4.1.11
>>>                         TXT     "007ddd47ea6ddcd890312de89e37bde496"
>>> node2                   A       10.4.1.12
>>>                         TXT     "316a8d5e65fbd9f853df6d90ad1f24ecac"
>>> node3                   A       10.4.1.13
>>>                         TXT     "009da8179478f9169cb47965e53d19f134"
>>>
>>> On VM2
>>> =======
>>>
>>>
>>>
>>> named.conf file
>>> ---------------
>>>
>>>
>>>
>>>
>>> #
>>> # Master
>>> #
>>> zone "rack3.com" {
>>>     type master;
>>>     file "/var/named/db.rack3.com";
>>>     allow-update { key rndc-key-rack3; }; # For DHCP update
>>> };
>>>
>>>
>>> #
>>> # Slave
>>> #
>>> zone "rack1.com" {
>>>     type slave;
>>>     file "/var/named/bak.rack1.com";
>>>     masters { 10.4.1.101; }; # VM1 named IP address
>>> };
>>>
>>>
>>>
>>>
>>> zone file:
>>> ----------
>>>
>>> $ORIGIN .
>>> $TTL 907200     ; 1 week 3 days 12 hours
>>> rack3.com               IN SOA  dnsserver3.rack3.com. admin.rack3.com. (
>>>                                 2          ; serial
>>>                                 60      ; refresh ()
>>>                                 60       ; retry ()
>>>                                 604800     ; expire (1 week)
>>>                                 3600       ; minimum (1 hour)
>>>                                 )
>>>                         NS      dnsserver3.rack3.com.
>>> $ORIGIN rack3.com.
>>> dnsserver3              A       10.4.3.101
>>> $TTL 3600       ; 1 hour
>>> node1                   A       10.4.3.11
>>>                         TXT     "001395d7d2a164c7efde811584bbc470b9"
>>>
>>>



-- 
John Miller
Systems Engineer
Brandeis University
johnmill at brandeis.edu
(781) 736-4619


More information about the bind-users mailing list