External, authoritative nameservers play a particularly important role in name resolution: they make your external zone data available to nameservers on the Internet. When people on the Internet send us email or visit our web site, they rely on data served by these nameservers.

In Chapter 11, we described the nameservers that “advertised” our external zones. One, ns.movie.edu , the primary for our external zones, sat outside our firewall on our perimeter network. Our ISP’s nameserver, ns1.isp.net, acted as a slave for our external zones.

These nameservers, because they’re directly exposed to the Internet, require special attention. We should disable recursion on ns.movie.edu , because it has no business handling recursive queries. This helps protect it against brute-force denial-of-service attacks, because its capacity to handle nonrecursive queries is many times its capacity to serve recursive queries. We should also limit zone transfers to just our ISP’s nameserver, preferably using TSIG. This helps protect the nameserver against denial-of-service attacks in which the attacker simply tries to start numerous concurrent zone transfers. And we can implement ACLs on our router or external firewall to limit the network traffic that our external nameservers are exposed to: minimally, we need to allow inbound UDP and TCP to port 53 and outbound UDP and TCP from our nameserver’s port 53.

We might later decide to enhance our external DNS infrastructure by setting up a new primary nameserver for our external zones, this one inside the firewall. In fact, using views, we can configure the internal movie.edu primary as the primary for the external movie.edu, too. This might be more convenient for us as administrators because it allows us to make changes to either the internal or external namespace from the same host. Here’s how the primary’s named.conf file might look:

options {
    directory "/var/named";
};

acl "internal" {
    127/8; 192.249.249/24; 192.253.253/24; 192.253.254/24; 192.254.20/24;
};

view "internal" {
    match-clients { "internal"; };
    recursion yes;

    zone "movie.edu" {
        type master;
        file "db.movie.edu.internal";
        forwarders {};
     };

    zone "249.249.192.in-addr.arpa" {
        type master;
        file "db.192.249.249";
    };

zone "253.253.192.in-addr.arpa" {
        type master;
        file "db.192.253.253";
    };

    zone "254.253.192.in-addr.arpa" {
        type master;
        file "db.192.253.254";
    };

    zone "20.254.192.in-addr.arpa" {
        type master;
        file "db.192.254.20";
    };

    zone "." {
        type hint;
        file "db.cache";
    };
};

key "ns.movie.edu" {
    algorithm hmac-md5;
    secret "JprUYzd+p2TO/B7k9k9Gdg==";
};

view "external" {
    match-clients { key "ns.movie.edu"; };
    recursion no;

    zone "movie.edu" {
        type master;
        file "db.movie.edu.external";
    };

    zone "4.1.200.in-addr.arpa" {
        type master;
        file "db.200.1.4";
    };
};

To minimize the traffic we need to allow through the firewall, we can ask our ISP to use our slave nameserver on the DMZ, ns.movie.edu , as its master for movie.edu and 4.1.200.in-addr.arpa.

Since we probably don’t want to allow queries from nameservers on the Internet to a nameserver inside the firewall, we need to configure the new primary nameserver as a hidden primary. This is a primary that, like the unregistered slaves we introduced in Chapter 8, isn’t listed in the NS records for our external zones—not the NS records in the zones themselves and not in their parent zones. This prevents any Internet nameserver from trying to query it during the normal name resolution process. All we need to do to configure the new nameserver as a hidden primary is to leave it out of the list of nameservers we register through our registrar and not add any NS records referring to it to our external zones.

Figure 16-1 shows how this works.

Figure 16-1. External authoritative nameservers, including a hidden primary

We should protect the hidden primary by allowing only DNS traffic between it and our slave nameservers out on the Internet, in order to support NOTIFY messages the primary sends to the slaves, and refresh queries and zone transfer requests from the slaves to the primary. This requires allowing the traffic outlined in Table 16-1.

We can even tighten these rules a little using the notify-source and query-source substatements to nail down the source UDP ports.

Our views configuration duplicates these restrictions on the primary itself, using TSIG keys rather than IP addresses. (Notice the use of a TSIG key in the external view’s match-clients substatement.) This gives us redundant, independent mechanisms protecting our primary nameserver—important for “defense in depth.”

That’s only half of our external DNS infrastructure. We also need to let internal resolvers and nameservers resolve Internet domain names. We can satisfy that requirement by allowing our internal nameservers to query arbitrary nameservers on the Internet, assuming our firewall is capable of that. That can be dangerous, though, for reasons we discussed back in Chapter 11. Consequently, most organizations run forwarders, which basically act as DNS proxy servers. (We introduced them back in Chapter 10.) We’ll set up two forwarders, for redundancy, near our connection to the Internet. The forwarders can send queries through our firewall to nameservers on the Internet and receive responses; nameservers on the Internet, however, won’t be allowed to query our forwarders. We can enforce this using an allow-query ACL in our forwarders’ named.conf files and state-based UDP filtering on our firewall. As with the ACLs protecting the hidden primary, this gives us defense in depth.

Be sure to run the latest version of BIND, at least 9.3.0, on your internal nameservers to ensure that they choose intelligently between the two forwarders, as described in Chapter 10. Older BIND nameservers (e.g., before 9.3.0) with simpler forwarder selection algorithms can have problems if their first forwarder fails. Since they blindly try the first forwarder each time they forward a query, each forwarded query will take longer to process—sometimes several seconds longer. This can quickly add up on a nameserver processing hundreds of queries per second, even to the point of causing the nameserver to refuse new recursive queries. (Remember the default limit of 1,000 concurrent recursive queries?)

As recommended back in Chapter 11, we’ll configure our internal nameservers to forward only queries for domain names outside our internal namespace. Any domain names ending in movie.edu should be resolved internally, via iterative queries. On authoritative movie.edu nameservers, this requires adding an empty forwarders substatement within the movie.edu zone statement, like so:

zone "movie.edu" {
    type slave;
    masters { 192.249.249.1; };
    file "bak.movie.edu";
    forwarders {};
};

On other nameservers, such as the fx.movie.edu nameservers, we can add a stub movie.edu zone:

zone "movie.edu" {
    type stub;
    masters { 192.249.249.1; };
    file "bak.fx.movie.edu";
    forwarders {};
};

This gives those nameservers the NS records they need to resolve movie.edu domain names—and a rule that tells them to resolve those domain names without relying on the forwarders—without the overhead of zone transfers.

Let’s not forget to set up a similar configuration for our reverse-mapping zones, too, if any of them are parent zones. We don’t want queries for domain names in our reverse-mapping zones to leak to our forwarders and possibly out to the Internet.

Figure 16-2 shows how this works.

Figure 16-2. Forwarding infrastructure

Could we have saved a few bucks on hardware by using our external authoritative nameservers as forwarders, too? Sure, but that also would have presented a risk. Even if we’d created separate external authoritative and forwarder views, with recursion disabled in the external authoritative view and access to the forwarder view limited to our internal address space, the external nameservers would now be exposed to both queries and responses from arbitrary IP addresses on the Internet. That’s twice as many potential vectors hackers can use to attack our external nameservers—nameservers which are now twice as important, because they support both external authoritative name service and forwarding.

We’ve already discussed one aspect of our internal DNS architecture: the forwarding configuration. While that’s important, there’s more to cover. For movie.edu, we have a primary nameserver running on toystory.movie.edu and slaves on wormhole.movie.edu and zardoz.movie.edu . For fx.movie.edu, bladerunner.fx.movie.edu is the primary and outland.fx.movie.edu is a slave.

If we can scare up a little extra hardware, we might set up hidden primaries for movie.edu and fx.movie.edu, too. In our external authoritative DNS infrastructure, a hidden primary configuration is necessary to prevent nameservers on the Internet from trying to query our primary, which is inside the firewall and not reachable from the Internet. Internally, a hidden primary configuration offers different advantages.

Inside the firewall, using a hidden primary helps to insulate our resolvers and nameservers from occasional configuration and data-entry snafus, maintenance-induced outages, and the like. If we accidentally mess up while editing a zone datafile on the movie.edu primary and our nameserver starts spewing SERVFAIL responses to movie.edu queries, this won’t degrade our name service. Our slaves, which answer all queries from resolvers and other internal nameservers, won’t be affected. They’ll keep responding with the last good version of the zone they transferred, and won’t transfer a new copy of the zone until the primary is back up and responding authoritatively. We’ll have until movie.edu’s expiration time—weeks—to fix the problem. If we can’t fix the problem before the zone’s expiration time, we should probably consider a change of career.

As time goes on, we’ll probably need to expand our internal DNS infrastructure. Let’s say we need to provide name service to a new building on campus. Using the guidelines in Chapter 8, we should determine whether the resolvers in the building generate enough queries to warrant setting up a local nameserver. If not—assuming the connection from the building to the rest of the campus network is reliable—we can just configure the building’s resolvers to query our existing internal nameservers.

If the building merits its own nameserver, or if the connection to the rest of the network is slow or flaky, we can set up a local nameserver. If we expect the local resolvers to do most of their queries in movie.edu, we can configure the nameserver as a slave for the zone. If the building’s link to the campus network is slow, we can omit the NS records in movie.edu pointing to the slave to prevent other internal nameservers from trying to query it—making it what’s sometimes referred to as a stealth slave. We should also determine which reverse-mapping zones local resolvers will query the most, and whether we should configure the building’s nameserver as a slave for them, too.

While not strictly architectural, it’s a good idea to spend some time documenting DNS operations. For example, you can institute a change control process, which can include saving older versions of named.conf and zone datafiles, perhaps by checking each modified file in using the Revision Control System, RCS. In fact, before saving a new version of a zone datafile, and certainly before putting the zone into production, you should check its syntax using the named-checkzone command, introduced in Chapter 4. Likewise, check the syntax of new named.conf files using named-checkconf. You can use a script to automate the process of managing zone datafiles, which will:

To make it easier to monitor your nameservers, you can aggregate their syslog output on a single host. If you haven’t reconfigured named’s logging, that’s a simple matter of adding a line like:

daemon.*        @loghost

to the syslog.conf files on the hosts running your nameservers. If that catches syslog messages from network servers you don’t want sent, you can easily reconfigure your nameservers to use a unique facility name with a logging statement like this:

logging {
    channel default_syslog {
        syslog local0;
    };
};

Now adding the line:

local0.*        @loghost

to syslog.conf sends only named’s syslog messages to your log host (assuming you’re not using the local0 facility for anything else).

To ensure that you’re notified of important messages your nameservers log, set up a logfile monitor. swatch ^[*] is a popular (and free!) program that scans logfiles for regular expressions you specify and takes action—sends email, pages you—based on rules you establish.

Monitoring syslog output won’t detect all possible problems, though. In addition, you should probably set up some form of monitoring that uses DNS queries to check the integrity of your namespace. We might use dnswalk,^[*] a powerful program for checking zone data, for this. We could run dnswalk hourly from cron, for example:

0 * * * *     /usr/bin/dnswalk movie.edu. 2>&1 | mail -s "dnswalk:
`date`" [email protected]

If that generates more email than you’re interested in, grep the output for important error messages and only mail what matches.

Finally—and you experienced system administrators knew this already—you need to back up your nameservers regularly. Nightly backups of your hosts’ filesystems may be enough, or you may want to keep copies of important named.conf and zone datafiles on a central host for easier recovery or just for ready examination. rsync, which we introduced in Chapter 8, can come in handy for this task.

As the administrators of many zones and several BIND nameservers, we believe it’s critical to keep up with the latest developments. You can do so by subscribing to the BIND Users mailing list or, at minimum, BIND Announce, which we talked about in Chapter 3. Using these resources, you can stay up to date on BIND vulnerabilities, and the availability of patches and new versions of BIND.

Of course, we think a good way to keep up with DNS and BIND is to keep buying the latest edition of this book, too. See you next time!