Split horizon DNS can be used to maintain a different set of IP addresses for each configured zone. The most practical usage is to make the DNS server reply with local network IP addresses for hosts on the local network but still respond with external IP addresses for clients outside the local network. The problem is that if a slave and master server are placed both inside and outside of the local network yet still connected inside a local network then zone transfers will not work properly since the public zone may end up being updated by the local zone.

Suppose that a master and a slave server are separated via the Internet but that they share a VPN connection:

In this case, setting the master to update the slave via y.y.y.y might overwrite the slaves's internal zone on a.a.a.a with the public zone. Conversely, if the master would be made to update the slave via b.b.b.b, then the slave's public zone on x.x.x.x might be overwritten with the master's internal records.

One solution would be to push all external zone updates through the public addresses (x.x.x.x, respectively y.y.y.y) and the internal zone updates through the internal addresses (a.a.a.a, respectively b.b.b.b) but there are certain shortcomings to that solution:

• both addresses x.x.x.x, respectively y.y.y.y must be static and in case there ever is a change to any of them, then both the master and the slave will have to be updated to change the addresses,
• updates via the Internet will occur on public channels, perhaps secured with encryption, but still it is quite redundant when there is a secure VPN connection between the master and the slave DNS servers.

The solution is to create a pair of update keys for both the external and internal views such that updates to the external zone will only be allowed via the external key and updates to the internal zone will only be allowed via the internal key. By using two different keys, ISC bind will be able to differentiate between the requests, even if the internal VPN addresses are used for zone transfers.

Reusing the abstract example but using concrete values where relevant:

To create a pair of keys, issue:

rndc-confgen

twice and add two keys to the /etc/bind/rndc.key file that will be used for the external, respectively internal views.

For example:

key "external-key" {
        algorithm hmac-md5;
        secret "QT57FcMhpbdHxBB4tPKS2w==";
};

key "interal-key" {
        algorithm hmac-md5;
        secret "sqHzF34XESB4vPlCJLe1jQ==";
};

Next, the split horizon configuration will have to be updated to specify which key will be allowed to update the external or internal views.

For instance, the following split horizon configuration defines two views internal and external with three zones each (zone1, zone2, zone3):

view "internal" {
    match-clients { key internal-key; !key external-key; 127.0.0.1; 192.168.5.0/24; };

    // Sync
    server 192.168.5.1 { keys internal-key; };
    server 192.168.5.2 { keys internal-key; };

    include "/etc/bind/named.conf.zone1-internal";
    include "/etc/bind/named.conf.zone2-internal";
    include "/etc/bind/named.conf.zone3-internal";
};

view "external" {
    match-clients { key external-key; !key internal-key; any; };

    // Sync
    server 192.168.5.1 { keys external-key; };
    server 192.168.5.2 { keys external-key; };
    
    include "/etc/bind/named.conf.zone1";
    include "/etc/bind/named.conf.zone2";
    include "/etc/bind/named.conf.zone3";
};

The match-clients statement for the internal view will match any request (zone transfer or lookup) coming from:

• a client identified by the internal-key (defined previously in /etc/bind/rndc.key),
• excluding clients identified by the external-key (defined previously in /etc/bind/rndc.key),
• any request from the local host and from the local network

Conversely, the external view will match any request (zone transfer or lookup) coming from:

• a client identifed by the external-key (defined previously in /etc/bind/rndc.key),
• excluding clients identified by the internal-key (defined previously in /etc/bind/rndc.key),
• any other client

Furthermore, each slave DNS server is defined with the corresponding key for the internal or external views:

    server 192.168.5.1 { keys internal-key; };
    server 192.168.5.2 { keys internal-key; };

respectively:

    server 192.168.5.1 { keys external-key; };
    server 192.168.5.2 { keys external-key; };

The last step is to update the zone files for both the master and the salve and always use the internal VPN address.

For the master's external zone:

zone "zone1.net" {
  type master;
  notify yes;
  also-notify { 192.168.5.1; 192.168.5.2; };
  allow-transfer { 192.168.5.1; 192.168.5.2; };
  file "/etc/bind/db.zone1.net";
};

respectively the master's internal zone:

zone "zone1.net" {
    type master;
    notify yes;
    also-notify { 192.168.5.1; 192.168.5.2; };
    allow-transfer { 192.168.5.1; 192.168.5.2; };
    file "/etc/bind/db.zone1.net-internal";
};

Similarly, for the slave's external zone:

zone "zone1.net" {
  type slave;
  masters { 192.168.5.10; };
  file "/etc/bind/db.zone1.net";
};

respectively, the slave's internal zone:

zone "zone1.net" {
    type slave;
    masters { 192.168.5.10; };
    file "/etc/bind/db.zone1.net-internal";
};

Following the pattern, the other zones zone2 and zone3, contained within both internal and external split views will have to be defined.

If one takes a closer look at the diagram in the topology chapter, Slave A and Salve B may be placed anywhere provided that there is a local network connection to the master: for example, Slave A could be the DNS provider for the entire 192.168.5.0/24 subnet and only listen to queries on 192.168.5.0/24 whilst updating the internal view and disregarding the external view.

A good practical scenario therefore would be in an instance where Slave A is the router for the 192.168.5.0/24 network and does not offer any public zones but instead only performs internal network domain resolution and resolves external domains.

If such a configuration is desire, then Slave A could have the following split-horizon configuration with only a single internal view:

view "internal" {
        match-clients { key internal-key; !key external-key; 127.0.0.1; 192.168.5.0/24; };

        // Sync
        server 192.168.5.1 { keys internal-key; };
        server 192.168.5.2 { keys internal-key; };

        include "/etc/bind/named.conf.internal";
};

with the zones defined in /etc/bind/named.conf.internal:

zone "zone1.net" {
    type slave;
    masters { 192.168.5.10; };
    file "/etc/bind/db.zone1.net-internal";
};

// ... similarly, for zone2.net and zone3.net

Now Slave A will listen to zone updates from the master at 192.168.5.10, will provide domain resolution for the 192.168.5.0/24 network but will not provide any external resolution for the domains defined in zone1.net, zone2.net or zone3.net.