Knowledge Base ISC Main Website Ask a Question/Contact ISC
Understanding views in BIND 9, by example
Author: Brian Conry Reference Number: AA-00851 Views: 23674 Created: 2013-01-09 19:52 Last Updated: 2015-02-23 16:18 100 Rating/ 2 Voters

Views in BIND have a bad reputation, with some people advocating that they should not be used. It is true that views add complexity to a BIND configuration, but this article will explain how that complexity can be managed and allow views to be used effectively.

One of the first thing to understand with views is that the zones loaded into memory in each view are completely independently of any other copy of that zone loaded in any other view.

Caches and views

Caches are also unique to each view by default. Unlike zones, however, they can be explicitly shared using the attach-cache option.  See How do I configure multiple views to share the same recursive cache? for more details.

One way to think about multiple views is as if each view were its own instance of BIND, with a fancy multiplexer in front of them all that determines which instance will receive each incoming request packet.

When you think about each view as its own process, it makes it easy to see that for slave zones each view needs to receive its own NOTIFY message when zone data changes. It also follows naturally that each view needs to have a means of requesting zone data from the correct view on the master (assuming that the master also has multiple views). All of this applies even when the master and slave are located in different views within the same BIND instance!

The multiplexer in front of the views can use up to three different pieces of information about an incoming request to determine which view it should be sent to: the source IP address (with the match-clients statement), the destination address (with the match-destinations statement), and whether or not the request is signed with a specific key (with both match-clients and match-destinations).

Let's get started with the examples.

These Examples are Simplified

In order to more clearly demonstrate the principles of managing views, these examples do not go out of their way to also demonstrate other principles of good server management, such as allowing dynamic updates or good security practices.

Example 1 - A single server, no zones in common

In the first example we have, perhaps, the simplest possible setup with multiple views — a single server with views that don't need to share any zone data.

# named.example01.conf

acl trusted { 192.168.7.0/24; localhost; };
acl guest   { 192.168.8.0/24; };

view trusted {
    match-clients { trusted; };

    allow-recursion { any; };

    zone "myzone.example" {
        type master;
        file "db.myzone.example";
    };
    zone "7.168.192.in-addr.arpa" {
        type master;
        file "db.192.168.7";
    };
};

view guest {
    match-clients { guest; };

    allow-recursion { any; };
};

This setup is something like someone might in a small office (or maybe at home) with a trusted network for known clients and an untrusted guest network for visitors. This setup features a local zone that only the devices on the trusted network can see, only acts as a resolver for local clients, and does not allow clients on the guest network to "snoop" in the cache that "trusted" clients use.

How views affect rndc commands

As long as a zone name is unambiguous you can use it with rndc commands the same as when not using views. If the zone exists in multiple views then it will need to be qualified by both the class (nearly always IN for internet) and the view name.

Example 2 - A single server, one common (but different) zone

On the same network as before, suppose that the operator decides that they want to provide names to guests for a few select services that they offer within the network.

# named.example02.conf

acl trusted { 192.168.7.0/24; localhost; };
acl guest   { 192.168.8.0/24; };

view trusted {
    match-clients { trusted; };

    allow-recursion { any; };

    zone "myzone.example" {
        type master;
        file "trusted/db.myzone.example";
    };
    zone "7.168.192.in-addr.arpa" {
        type master;
        file "trusted/db.192.168.7";
    };
};

view guest {
    match-clients { guest; };

    allow-recursion { any; };

    zone "myzone.example" {
        type master;
        file "guest/db.myzone.example";
    };
};

Note that a subdirectory has been created for each view and that the zone data files for both views have been placed in their respective subdirectory. Keeping the zone data files separated this way will help prevent confusion and problems later.

Example 3 - Adding a second server

DNS Servers are social creatures and like to have company, so the operator of this network has decided that to add a second DNS server.


Thinking about each view as an independent server helps us to remember that we need to make a way for each view on Server 2 to talk to the same view on Server 1. If we don't do anything explicitly to make it happen then both views on Server 2 will be talking to the trusted view on Server 1 because of Server 2's IP address. While we could use set up additional IPs for this, using TSIG keys gives us the most flexibility and doesn't require any OS changes to configure the additional IPs on the servers.

Further information on TSIG

For information on generating and using TSIG see chapter 4 of the BIND 9 Administrator Reference Manual (ARM) appropriate for your version.  The ARM for many BIND versions can be found at Software Products:BIND9:Documentation.  A copy of the ARM is also included with every BIND 9 source tarball and Windows zip file downloaded from the ISC.

Version 9.9.0+ required for these examples

The following configurations require BIND version 9.9.0 or greater. The also-notify statement does not allow keys to be specified in any lower versions. Without the ability to specify a key in the also-notify statement you have to use other ways to distinguish between views, such as the method described in My slave server for both an internal and an external view has both views transferred from the same master view - how to resolve?.

# named.example3.server1.conf

key trusted-key {
    algorithm HMAC-MD5;
    secret some-secret;
};

key guest-key {
    algorithm HMAC-MD5;
    secret another-secret;
};

acl trusted { !key guest-key; key trusted-key; 192.168.7.0/24; localhost; };
acl guest   { !key trusted-key; key guest-key; 192.168.8.0/24; };

options {
    notify explicit;
    allow-transfer { none; };
};

view trusted {
    match-clients { trusted; };

    allow-recursion { any; };

    allow-transfer { key trusted-key; };

    zone "myzone.example" {
        type master;
        file "trusted/db.myzone.example";
        also-notify { 192.168.7.28 key trusted-key; };
    };
    zone "7.168.192.in-addr.arpa" {
        type master;
        file "trusted/db.192.168.7";
        also-notify { 192.168.7.28 key trusted-key; };
    };
};

view guest {
    match-clients { guest; };

    allow-recursion { any; };

    allow-transfer { key guest-key; };

    zone "myzone.example" {
        type master;
        file "guest/db.myzone.example";
        also-notify { 192.168.7.28 key guest-key; };
    };
};

# named.example3.server2.conf

key trusted-key {
    algorithm HMAC-MD5;
    secret some-secret;
};

key guest-key {
    algorithm HMAC-MD5;
    secret another-secret;
};

acl trusted { !key guest-key; key trusted-key; 192.168.7.0/24; localhost; };
acl guest   { !key trusted-key; key guest-key; 192.168.8.0/24; };

options {
    notify explicit;
    allow-transfer { none; };
};

view trusted {
    match-clients { trusted; };

    allow-recursion { any; };

    zone "myzone.example" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.myzone.example";
    };
    zone "7.168.192.in-addr.arpa" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.192.168.7";
    };
};

view guest {
    match-clients { guest; };

    allow-recursion { any; };

    zone "myzone.example" {
        type slave;
        masters { 192.168.7.27 key guest-key; };
        file "guest/db.myzone.example";
    };
};

The "!key ..." parts of the acls are important to force signed requests to be rejected from inappropriate matches before they have a chance to match on the source IP.

Note that, as written, this example allows anyone, on any network, with the TSIG key to sign regular DNS requests in order to select which view they want their answer from and also to request zone transfers.  Depending on who has the key and what their motivation is, this could be considered to be either a serious problem or a nice feature.  See Using Access Control Lists (ACLs) with both addresses and keys for more information on how these ACLs could be improved.

Another significant thing that this example demonstrates in the server1 configuration is that many options can be specified in both a "global" options section and inside of views, with the value specified in the view overriding the "global" value.

I've chosen to set the notify option to "explicit". This disables the default behavior of sending NOTIFY messages to every name server listed in the zone data (except for the master listed in the SOA, which is already exempted) because those NOTIFY messages would be sent unsigned instead of with the proper view identification key.

Example 4 - Now with shared zones

Since the last example, the network operator has decided that they're going to create DDNS records for their guest clients in a set of new zones.  While this information will mostly be used by systesm on the trusted network, the operator would like to allow the guest clients to see their own dynamically-created DNS records, which means making the same zones available in both views..

The key to making this work is to once again think about the views as independent servers and so to create an explicit relationship between the two views. We continue to use keys to make sure that the NOTIFY messages and transfer requests get sent to the correct view, where the key used matches the view that we want to receive the message.

Version 9.9.0+ required for these examples

As with example 3, this example also requires BIND version 9.9.0 or higher.  For information about how to accomplish this with lower versions of BIND 9 see How do I share a dynamic zone between multiple views?.

## named.example4.server1.conf

key trusted-key {
    algorithm HMAC-MD5;
    secret some-secret;
};

key guest-key {
    algorithm HMAC-MD5;
    secret another-secret;
};

key update-key {
    algorithm HMAC-MD5;
    secret yet-another-secret;
};

acl trusted { !key guest-key; key trusted-key; 192.168.7.0/24; localhost; };
acl guest   { !key trusted-key; key guest-key; 192.168.8.0/24; };

options {
    notify explicit;
};

view trusted {
    match-clients { trusted; };

    allow-recursion { any; };

    allow-transfer { key trusted-key; };


    allow-update { key update-key; };

    zone "myzone.example" {
        type master;
        file "trusted/db.myzone.example";
        also-notify { 192.168.7.28 key trusted-key; };
    };
    zone "7.168.192.in-addr.arpa" {
        type master;
        file "trusted/db.192.168.7";
        also-notify { 192.168.7.28 key trusted-key; };
    };
    zone "guests.example" {
        type master;
        file "trusted/db.guest.example";
        also-notify {
            192.168.7.28 key trusted-key;
            127.0.0.1    key guest-key;
        };
    };
    zone "8.168.192.in-addr.arpa" {
        type master;
        file "trusted/db.192.168.8";
        also-notify {
            192.168.7.28 key trusted-key;
            127.0.0.1    key guest-key;
        };
    };
};

view guest {
    match-clients { guest; };

    allow-recursion { any; };

    allow-transfer { key guest-key; };

    zone "myzone.example" {
        type master;
        file "guest/db.myzone.example";
        also-notify { 192.168.7.28 key guest-key; };
    };
    zone "guests.example" {
        type slave;
        masters { 127.0.0.1 key trusted-key; };
        file "guest/db.guest.example";
        also-notify { 192.168.7.28 key guest-key; };
    };
    zone "8.168.192.in-addr.arpa" {
        type slave;
        masters { 127.0.0.1 key trusted-key; };
        file "guest/db.192.168.8";
        also-notify { 192.168.7.28 key guest-key; };
    };
};

## named.example4.server2.conf

key trusted-key {
    algorithm HMAC-MD5;
    secret some-secret;
};

key guest-key {
    algorithm HMAC-MD5;
    secret another-secret;
};

acl trusted { !key guest-key; key trusted-key; 192.168.7.0/24; localhost; };
acl guest   { !key trusted-key; key guest-key; 192.168.8.0/24; };

view trusted {
    match-clients { trusted; };

    allow-recursion { any; };

    zone "myzone.example" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.myzone.example";
    };
    zone "7.168.192.in-addr.arpa" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.192.168.7";
    };
    zone "guests.example" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.guest.example";
    };
    zone "8.168.192.in-addr.arpa" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.192.168.8";
    };
};

view guest {
    match-clients { guest; };

    allow-recursion { any; };

    zone "myzone.example" {
        type slave;
        masters { 192.168.7.27 key guest-key; };
        file "guest/db.myzone.example";
    };
    zone "guests.example" {
        type slave;
        masters { 192.168.7.27 key guest-key; };
        file "guest/db.guest.example";
    };
    zone "8.168.192.in-addr.arpa" {
        type slave;
        masters { 192.168.7.27 key guest-key; };
        file "guest/db.192.168.8";
    };
};



© 2001-2016 Internet Systems Consortium

Please help us to improve the content of our knowledge base by letting us know below how we can improve this article.

If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback.

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback
  • There is no feedback for this article
Info Submit Feedback on this Article
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu