2

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
  • 1
  • 7
daniel_p
  • 21
  • 1
  • I suggest using a different master for the internal view on the slave; how is the master supposed to know that an AXFR request for "example.com" coming in on 10.1.10.99 is to be the internal or the external view? According to the ACL it should serve the external view, so that's what you're getting. – wurtel Nov 25 '19 at 15:02
  • A view is just a ways to present to a client different content based on its IP address. If your slave nameserver has only one IP address it will always match one view and get content from it. Zone transfers is not for transmitting configuration like views from servers. – Patrick Mevzek Nov 25 '19 at 17:52
  • This question has been already answered so I will not add the answer again. Anyway what I see there is syntax mistake... Negation should be set for whole block / value. There would be **!key external_key;** instead of **key !external_key;``. – Kamil J Jan 26 '20 at 00:56

1 Answers1

2

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
  • 33,741
  • 5
  • 65
  • 90
  • 1
    What is described in the ISC article certainly works if your setup matches what they describe, but the optimization (?) of introducing one less key comes with so much more required thought about all aspects of the setup and any necessary adjustments if your setup differs from theirs that I don't think it's a good trade-off. – Håkan Lindqvist Nov 26 '19 at 09:24
  • 1
    This approach is working (I have used it several times already). You can add keys directly to ACL and I recommend to start with keys and then follow with IPs - e.g. ``acl "internals" { !key extenal_key; key internal_key; 127.0.0.0/8; 10.1.20.0/24; };``./ What would be also good idea is to set **notify explicit;** to not send out automatically notification for the change. Next to it with each zone set up **also-notify** where you can also use IP with the key so even notification will reach "correct view" on the slave. – Kamil J Jan 26 '20 at 00:54