3

I have a simple lab/testing Master/Slave configuration (showed below) and I would like to transfer both views to the slave.

Unfortunately after the zone transfer both views in slave have records from "external" view from the master. I've read several other topics concerning similar problem on serverfault but nothing worked for me.

Master (10.1.10.99):

acl "internals" {
    127.0.0.0/8;
    10.1.20.0/24;
};

acl "externals" {
    10.1.10.0/24;
};


key "external_key" {
algorithm hmac-md5;
secret "xxxxx";
};

view "internal"
{
also-notify {10.1.10.103; };

match-clients {key "!external_key"; "internals"; };

zone "example.com" {
    type master;
    file "/etc/bind/db.example.com";
};

[...]

view "external"
{

    match-clients {key "external_key";  "externals"; };
    server 10.1.10.103 { keys "external_key";};
    zone "example.com" {
        type master;
        file "/etc/bind/db.external.example.com";
    };
};

Slave (10.1.10.103):

acl "internals" {
    127.0.0.0/8;
    10.1.20.0/24;
};

acl "externals" {
    10.1.10.0/24;
};


key external_key {
algorithm hmac-md5;
secret "xxxxx";
};

view "internal"
{

match-clients {key "!external_key" ;"internals"; };
zone "example.com" {
    type slave;
    masters {10.1.10.99;};
};

[...]

};

view "external"
{
    match-clients {key "external_key"; "externals"; };
    server 10.1.10.99 { keys "external_key";};
    zone "example.com" {
        type slave;
        masters { 10.1.10.99;};

    };
};

On my slave I get:

Nov 24 23:36:24 ubuntu named[654]: zone example.com/IN/external: Transfer started.
Nov 24 23:36:24 ubuntu named[654]: zone example.com/IN/internal: Transfer started.
Nov 24 23:36:24 ubuntu named[654]: transfer of 'example.com/IN/external' from 10.1.10.99#53: connected using 10.1.10.103#58947 TSIG external_key
Nov 24 23:36:24 ubuntu named[654]: transfer of 'example.com/IN/internal' from 10.1.10.99#53: connected using 10.1.10.103#46287
Nov 24 23:36:24 ubuntu named[654]: zone example.com/IN/external: transferred serial 2006020201: TSIG 'external_key'
Nov 24 23:36:24 ubuntu named[654]: transfer of 'example.com/IN/external' from 10.1.10.99#53: Transfer status: success
Nov 24 23:36:24 ubuntu named[654]: transfer of 'example.com/IN/external' from 10.1.10.99#53: Transfer completed: 1 messages, 6 records, 259 bytes, 0.008 secs (32375 bytes/sec)
Nov 24 23:36:24 ubuntu named[654]: zone example.com/IN/internal: transferred serial 2006020201
Nov 24 23:36:24 ubuntu named[654]: transfer of 'example.com/IN/internal' from 10.1.10.99#53: Transfer status: success
Nov 24 23:36:24 ubuntu named[654]: transfer of 'example.com/IN/internal' from 10.1.10.99#53: Transfer completed: 1 messages, 6 records, 177 bytes, 0.009 secs (19666 bytes/sec)

And it looks like both views are transferred properly, but on the master I get:

Nov 24 23:36:23 ubuntu named[2240]: client @0x7f4a700d5cb0 10.1.10.103#58947/key external_key (example.com): view external: transfer of 'example.com/IN': AXFR started: TSIG external_key (serial 2006020201)
Nov 24 23:36:23 ubuntu named[2240]: client @0x7f4a700d5cb0 10.1.10.103#58947/key external_key (example.com): view external: transfer of 'example.com/IN': AXFR ended
Nov 24 23:36:23 ubuntu named[2240]: client @0x7f4a70057690 10.1.10.103#46287 (example.com): view external: transfer of 'example.com/IN': AXFR started (serial 2006020201)
Nov 24 23:36:23 ubuntu named[2240]: client @0x7f4a70057690 10.1.10.103#46287 (example.com): view external: transfer of 'example.com/IN': AXFR ended

Which looks like external view is transferred twice.

I also tried to follow: https://kb.isc.org/docs/aa-00296 but it didn't help.

Any suggestions/help would be appreciated.

ginerama
  • 216
daniel_p
  • 31

1 Answers1

3

Currently the slave matches the "wrong" view when no key is used (based on your IP matching rules).

The most obvious and robust solution is probably to set up one key per view for this purpose and match based on all keys (positive/negative) in each view.
That way you eliminate the current factors of which view has a key associated with it, combined with the view order, combined with your IP-based matching rules for regular clients. With your current approach that combination is crucial to get right (and the question stems from that not being right).

Håkan Lindqvist
  • 36,421