DNS View Declaration and Options

DNS views enable a DNS server to respond to queries differently based on the source of the query, the destination [address] of the query, and whether the query is recursive or not. The most common application of views is the so-called split DNS configuration, where a limited or varied set of resolution information is provided by a DNS server based on whether the query originated within an organization or externally, e.g., via the Internet. Thus for example, an A record query for www.ipamworldwide.com may resolve to a different IP address if the query is from an internal querier vs. from an external querier. The general format of the view declaration is as follows.

where view-name is the name assigned to the view, class is the class of the view, IN by default, and address_match_list is a reference to a set of addresses or networks as defined in the next subsection. Views may also have options relevant only to each view as highlighted in the BIND Options Reference table. The zone statement blocks within the view declaration are each of the format described above in the zone declaration section and define the zone type, class, and options associated with the version of the zone within this view.

Note that applications of views are not limited to the split DNS (internal/external) configuration. Views can be employed whenever you would like to offer a particular "version" of a domain to one community of resolvers or clients, and a different version to another community. For example, most companies desire to restrict access to their payroll or financial systems to a very small and known community of users, to the point of not resolving hostnames even resembling such a system. However, creating "unguessable" host names for these systems renders access very difficult for legitimate users.

While it is certainly obvious that resolution of payroll.ipamworldwide.com should be prohibited for external clients, it is likely that most internal users should also not be able to resolve it, except those within the permitted community of users. Hence, two views could be defined, one called "payroll" in which the payroll.ipamworldwide.com A record, among others, is configured, and another called "default" in which the A record is not configured.

Let's assume the permitted community of interest resides within the payroll department, which utilizes its own subnet. We can define an address match list called permitted-community-acl to define this payroll network. We can define the match-clients directive within the payroll view declaration to restrict applicability to those clients falling within the definition of the permitted-community-acl address match list; that is, with a source address falling within the permitted-community-acl scope. Since we're filtering on the source of the query to resolve the view, we can set the match-destinations directive to any for both views and match-recursive-only to no on both, meaning that either recursive or non-recursive types of queries qualify.

In the following named.conf file snippet, the zone file db.ipamworldwide.com.payroll contains the payroll host A record while the db.ipamworldwide.com zone file does not.

Thus each view declares the same zone, ipamworldwide.com, but each references a different zone file which contains different resource record information.

Note that the ordering of view definitions within the named.conf file is significant. During resolution the query will be matched against defined views in order. The first match will lead the server to resolve the query within the matching view without considering other views defined further down. You should generally place the default or "catch-all" view last, meaning that if the query does not match other defined views, the default view will apply.