Split DNS and BIND

At the beginning of the chapter, I alluded to enhanced support in BIND v9 for split DNS. This is achieved by the new view{} statement, which can be used in named.conf to associate multiple zone files with each zone name. In this way, different clients can be treated differently — e.g., external users receive one set of answers regarding a given name domain, and internal users receive different answers about the same domain.

If you use view{} functionality for one zone, you must use it for all. Put another way, if even one view is defined, then allzone{} statements must be nested within view{} statements. Standalone (nonnested) zone{} statements may only be used in the complete absence of view{} statements.

The syntax of view{} statements is shown in Example 6-7. Example 6-7. Zone-view syntax

view "view-name" {

match-clients { match-list; }; recursion yes|no;

zone "domain.name" {

// standard BIND 8/9 zone{} contents here };

// additional zones may be defined for this view as well };

The match-clients match list has the same format and built-in labels as the element lists described earlier in this chapter under Section 6.4.4.1. Nested zone{} statements are no different than ordinary standalone zone{} statements.

Example 6-8 illustrates two views defined for a split DNS scenario in which internal users’ queries are answered with complete zone information, but external users are served from a zone file containing a subset. Internal users may also query for information about an internal zone, intranet.ourorg.org, for which the DNS server won’t answer any external queries.

Example 6-8. Some example views view "inside" {

// Our internal hosts are:

match-clients { 192.168.100.0/24; };

// ...and for them we’ll do recursive queries... recursion yes;

// Here are the zones we’ll serve for them: zone "ourorg.ORG" {

type master;

file "master/ourorg_int.hosts"; };

// Here’s a subdomain that isn’t searchable in any form by outsiders zone "intranet.ourorg.ORG" { type master; file "master/intranet.ourorg.hosts"; }; }; view "outside" {

//Client view for "none of the above" match-clients { any; };

// We don’t recurse for the general public recursion no;

// Answer outside queries from a stripped-down zone file zone "ourorg.ORG" {

type master;

file "master/ourorg_ext.hosts"; };

};

As the comments in Example 6-8 imply, the view{} definition is parsed top to bottom: when a user’s IP address is compared against the defined views, it will progress down the list until a match is found.

6.4.5 Zone File Security

Our secure DNS service is trapped in its padded cell and very particular about what it says to whom; in other words, it’s shaping up nicely. But what about the actual zone databases?

The good news here is that since our options are considerably more limited than with named.conf, there’s less to do. The bad news is that there’s at least one type of resource record that’s both obsolete and dangerous, and to be avoided by the security conscious.

Example 6-9 shows a sample zone file for the hypothetical domain boneheads.com. Example 6-9. Sample zone file

$TTL 86400

// Note: global/default TTL must be specified above. BIND v8 didn’t check for this,

// but BIND v9 does.

@ IN SOA cootie.boneheads.com. hostmaster.boneheads.com. ( 2000060215 ; serial

10800 ; refresh (3H) 1800 ; retry (30m) 120960 ; expiry (2w) 43200 ) ; RR TTL (12H)

IN NS ns.otherdomain.com. IN NS cootie.boneheads.com. IN MX 5 cootie.boneheads.com. blorp IN A 10.13.13.4

cootie IN A 10.13.13.252

cootie IN HINFO MS Windows NT 3.51, SP1

@ IN RP john.smith.boneheads.com. dumb.boneheads.com. dumb IN TXT "John Smith, 612/231-0000"

The first thing to consider is the Start-of-Authority (SOA) record. In Example 6-9, the serial number follows the yyyymmdd## convention. This is both convenient and helps security since it reduces the chances of accidentally loading an old (obsolete) zone file — the serial number (2000060215 in Example 6-9) serves both as an index and as a timestamp.

The refresh interval is set to 10,800 seconds (three hours). Other common values for this are 3,600 seconds (one hour) and 86,400 (one day). The shorter the refresh interval, the less time it will take for changes to the zone's records to propagate, but there will be a corresponding increase in DNS-related network traffic and system activity.

The expiry interval is set to two weeks. This is the length of time the zone file will still be considered valid should the zone's master stop responding to refresh queries. There are two ways a paranoiac might view this parameter. On the one hand, a long value ensures that if the master server is bombarded with denial-of- service attacks over an extended period of time, its slaves will continue using cached zone data and the domain will still be reachable (except, presumably, for its main DNS server!). On the other hand, even in the case of such an attack, zone data may change, and sometimes old data causes more mischief than no data at all.

Like the refresh interval, the Time To Live interval (TTL) should be short enough to facilitate reasonably speedy propagation of updated records but long enough to prevent bandwidth cluttering. The TTL determines how long individual zone's RRs may remain in the caches of other name servers who retrieve them via queries.

Our other concerns in this zone file have to do with minimizing the unnecessary disclosure of information. First, we want to minimize address records (A-records) and aliases (CNAME records) in general, so that only those hosts who need to be are present.

We need to use Responsible Person (RP) and TXT records judiciously, if at all, but we must never, ever put any meaningful data into an HINFO record. HINFO is a souvenir of simpler times: HINFO records are used to state the operating system, its version, and even hardware configuration of the hosts to which they refer! Back in the days when a large percentage of Internet nodes were in academic institutions and other open environments (and when computers were exotic and new), it seemed reasonable to advertise this information to one's users. Nowadays, HINFO has no valid use on public servers other than obfuscation (i.e.,

intentionally providing false information to would-be attackers). In short, don't use HINFO records! RP is used to provide the email address of someone who administers the domain. It's best to set this to as uninteresting an address as possible — e.g., [email protected] or [email protected]. Similarly, TXT records contain text messages that have traditionally provided additional contact information (phone numbers, etc.), but should be kept down to only necessary information or, better still, be omitted altogether. Returning to Example 6-5, we see that the last few records are unnecessary at best and a cracker's goldmine at worst. I repeat, if you feel you must use RP and TXT, carefully weigh the usefulness of doing so against the risk. And don't use HINFO at all.