16.4 DNS and Internet Firewalls

The Domain Name System wasn't designed to work with Internet firewalls. It's a testimony to the flexibility of DNS that you can configure DNS to work with, or even through, an Internet firewall.

That said, configuring the Microsoft DNS Server to work in a firewalled environment, although not difficult, takes a good, complete understanding of DNS. Describing it also requires a large portion of this chapter, so here's a roadmap.

We start by describing the two major families of Internet firewall software: packet filters and application gateways. The capabilities of each family have a bearing on how you'll need to configure your DNS servers to work through the firewall. The next section details the two most common DNS architectures used with firewalls, forwarders, and internal roots, and describes the advantages and disadvantages of each. Finally, we discuss split namespaces and the configuration of the bastion host, the host at the core of your firewall system.

16.4.1 Types of Firewall Software

Before you start configuring your DNS servers to work with your firewall, it's important that you understand what your firewall is capable of. Your firewall's capabilities will influence your choice of DNS architecture and will determine how you implement it. If you don't know the answers to the questions in this section, track down someone in your organization who does know and ask. Better yet, work with your firewall's administrator when designing your DNS architecture to ensure it will coexist with the firewall.

Note that this is far from a complete explanation of Internet firewalls. These few paragraphs describe only the two most common types of Internet firewalls and only in enough detail to show how the differences in their capabilities affect name servers. For a comprehensive treatment of Internet firewalls, see Elizabeth Zwicky, Simon Cooper, and D. Brent Chapman's Building Internet Firewalls (O'Reilly).

16.4.1.1 Packet filters

The first type of firewall we'll cover is the packet-filtering firewall. Packet-filtering firewalls operate largely at the transport and network levels of the TCP/IP stack (layers three and four of the OSI reference model, if you dig that). They decide whether to route a packet based upon packet-level criteria, such as the transport protocol (e.g., whether it's TCP or UDP), the source and destination IP addresses, and the source and destination ports (see Figure 16-1).

Figure 16-1. Packet filters operate at the network and transport layers of the stack

What's most important to us about packet-filtering firewalls is that you can typically configure them to selectively allow DNS traffic between hosts on the Internet and your internal hosts. That is, you can let an arbitrary set of internal hosts communicate with Internet name servers. Some packet-filtering firewalls can even permit your name servers to query name servers on the Internet, but not vice versa. All router-based Internet firewalls are packet-filtering firewalls. Check Point's FireWall-1, Cisco's PIX, and NetScreen's products are popular commercial packet-filtering firewalls.

16.4.1.2 Application gateways

Application gateways operate at the application protocol level, several layers higher in the OSI reference model than most packet filters (see Figure 16-2). In a sense, they "understand" the application protocol in the same way a server for that particular application would. An FTP application gateway, for example, can make the decision to allow or deny a particular FTP operation, like a RETR (a get) or a STOR (a put).

Figure 16-2. Application gateways operate at the application layer of the stack

The bad news, and what's important for our purposes, is that most application gateway-based firewalls handle only TCP-based application protocols. DNS, of course, is largely UDP-based, and we know of no application gateways for DNS. This implies that if you run an application gateway-based firewall, your internal hosts will likely not be able to communicate directly with name servers on the Internet.

The Firewall Toolkit from Trusted Information Systems (TIS, now part of Network Associates), a suite of application gateways for common Internet protocols, such as Telnet, FTP, and http, was used to build some of the first Internet firewalls. Many other firewall products include application gateways for various protocols. Note that these two categories of firewalls are really just generalizations. The state of the art in firewalls changes very quickly, and by the time you read this, you may have a firewall that includes an application gateway for DNS. Which family your firewall falls into is important only because it suggests what that firewall is capable of; what's more important is whether your particular firewall will let you permit DNS traffic between arbitrary internal hosts and the Internet.

16.4.2 A Bad Example

The simplest configuration is to allow DNS traffic to pass freely through your firewall (assuming you can configure your firewall to do that). That way, any internal name server can query any name server on the Internet, and any Internet name server can query any of your internal name servers. You don't need any special configuration.

Unfortunately, this is a bad idea, for two reasons:

Version control

The developers of the Microsoft DNS Server are constantly finding and fixing security-related bugs in the code. Consequently, it's important to run a recent version of the server, especially for name servers that are directly exposed to the Internet. If one or just a few of your name servers communicate directly with name servers on the Internet, upgrading them to a new version is easy. If all of the name servers on your network do, upgrading all of them is more difficult.

Possible vector for attack

Even if you're not running a name server on a particular host, a hacker might be able to take advantage of the fact that you allow DNS traffic through your firewall to attack that host. For example, a coconspirator working on the inside could set up a Telnet daemon listening on the host's DNS port, allowing the hacker to telnet right in.

For the rest of this chapter, we'll try to set a good example.

16.4.3 Internet Forwarders

Given the dangers of allowing bidirectional DNS traffic through the firewall unrestricted, most organizations elect to limit the internal hosts that can "talk DNS" to the Internet. With an application gateway firewall, or any firewall without the ability to pass DNS traffic, the only host that can communicate with Internet name servers is the bastion host (see Figure 16-3).

Figure 16-3. A small network, showing the bastion host

With a packet-filtering firewall, the firewall's administrator can configure the firewall to let any set of internal name servers communicate with Internet name servers. Often, a small set of hosts runs name servers under the direct control of the network administrator (see Figure 16-4).

Figure 16-4. A small network, showing select internal name servers

Internal name servers that can query name servers on the Internet directly don't require any special configuration. Their root hints files contain the Internet's root name servers, which enables them to resolve Internet domain names. Internal name servers that can't query name servers on the Internet, however, need to know to forward queries they can't resolve to one of the name servers that can. This is done with the Forwarders tab on the server's Properties window, described in Chapter 11.

Figure 16-5 illustrates a common forwarding setup, with internal name servers forwarding queries to a name server running on a bastion host.

Figure 16-5. Using forwarders

At Movie U., we put in a firewall to protect ourselves from the Big Bad Internet several years ago. Ours is a packet-filtering firewall, and we negotiated with our firewall administrator to allow DNS traffic between Internet name servers and two of our name servers, terminator.movie.edu and wormhole.movie.edu. (These negotiations involved the exchange of Krispy Kreme doughnuts.) Figure 16-6 shows how we configured the other internal name servers at the university.

Figure 16-6. Internal name server forwarding configuration

When configuring different internal name servers, we vary the order in which the forwarders appear to help spread the load among them.

When an internal name server receives a query for a name it can't resolve locally, such as an Internet domain name, it forwards that query to one of our forwarders, which can resolve the name using name servers on the Internet. Simple!

16.4.3.1 The trouble with forwarding

Unfortunately, it's a little too simple. Forwarding starts to get in the way once you delegate subdomains or build an extensive network. To explain what we mean, consider an internal caching-only name server, darkcity.movie.edu. darkcity.movie.edu is configured to use our two forwarders to resolve domain names. What happens when darkcity.movie.edu receives a query for a name in fx.movie.edu? Naturally, it'll forward the query to one of the forwarders. The response it gets may include NS records for fx.movie.edu, but darkcity.movie.edu will never use those NS records (unless they're looked up explicitly). It'll keep sending fx.movie.edu queries to the forwarders, even though it's perfectly capable of querying the fx.movie.edu name servers directly.

Now imagine the scale of the network is much larger: a corporate network that spans continents, with tens of thousands of hosts and hundreds or thousands of name servers. All of the internal name servers that don't have direct Internet connectivity the vast majority of them use a small set of forwarders. There are several things wrong with this picture:

Single point of failure

If the forwarders fail, your name servers lose the ability to resolve both Internet domain names and internal domain names that they don't have cached or authoritative data.

Concentration of load

The forwarders will have an enormous query load placed on them. This is both because of the large number of internal name servers that use them and because the queries are recursive and may require a good deal of work to answer.

Inefficient resolution

Imagine two internal name servers authoritative for west.acmebw.com and east.acmebw.com, respectively, both on the same network segment in Boulder, Colorado. Both are configured to use the company's forwarder in Bethesda, Maryland. To resolve a name in east.acmebw.com, the west.acmebw.com name server sends a query to the forwarder in Bethesda. The forwarder in Bethesda then sends a query back to Boulder to the east.acmebw.com name server, the original querier's neighbor. The east.acmebw.com name server replies by sending a response back to Bethesda, which the forwarder sends back to Boulder.

In a traditional configuration using iterative queries, the west.acmebw.com name server would quickly have learned that an east.acmebw.com name server was next door and would favor it (because of its low roundtrip time). Using forwarders "short-circuits" the normally efficient resolution process.

The upshot is that forwarding is fine for small networks and simple namespaces but usually inadequate for large networks and complex namespaces. We found this out the hard way at Movie U. as our network grew and we were forced to find an alternative.

16.4.3.2 Using stub zones

We can solve this problem by using stub zones, which we introduced in Chapter 10. In that chapter, we used stub zones to track delegation information. However, we can also use them to load certain NS records into our name server's cache and thereby disable forwarding for a domain.

We add movie.edu as a stub zone on our caching-only name server, as shown in Figure 16-7. With the stub zone configured, darkcity.movie.edu retrieves movie.edu's NS records and any necessary glue A records from the name server we designate. More importantly, when it has queries in the movie.edu domain, it sends them directly to the name servers designated in those NS records rather than forwarding the queries.

Figure 16-7. Adding movie.edu as a stub zone

We also need to set this up for any internal reverse-mapping zones to avoid having those sent to the forwarders.

If we set this up on all internal name servers that aren't authoritative for movie.edu and all of our reverse-mapping zones (they don't need it), we end up with a fairly robust resolution architecture that minimizes our exposure to the Internet: it uses efficient, resilient iterative name resolution to resolve internal domain names, and forwarders only when necessary to resolve Internet domain names. If our forwarders fail or we lose our connection to the Internet, we lose only our ability to resolve Internet domain names.

16.4.4 Internal Roots

If you want to avoid the scalability problems of forwarding and don't want to deal with stub zones, you can set up your own root name servers. These internal roots serve only the name servers in your organization. They'll know about only the portions of the namespace relevant to your organization.

What good are they? By using an architecture based on root name servers, you gain the scalability of the Internet namespace (which should be good enough for most companies), plus redundancy, distributed load, and efficient resolution. You can have as many internal roots as the Internet has roots 13 or so whereas having that many forwarders may be an undue security exposure and a configuration burden. Most of all, the internal roots don't get used frivolously. Name servers need to consult an internal root only when they time out the NS records for your top-level zones. Using forwarders, name servers may have to query a forwarder once per resolution.

The moral of our story is that if you have, or intend to have, a large namespace and lots of internal name servers, internal root name servers scale better than any other solution.

16.4.4.1 Where to put internal root name servers

Since name servers "lock on" to the closest root name server by favoring the one with the lowest roundtrip time, it pays to pepper your network with internal root name servers. If your organization's network spans the U.S., Europe, and the Pacific Rim, consider locating at least one internal root name server on each continent. If you have three major sites in Europe, give each of them an internal root.

16.4.4.2 Forward-mapping delegation

Here's how an internal root name server is configured. An internal root delegates directly to any zones you administer. For example, on the movie.edu network, the root zone's datafile would contain:

; ;  Delegated sub-zone: movie.edu. ; movie.edu                NS  terminator.movie.edu. terminator.movie.edu     A  192.249.249.3 movie.edu                NS  wormhole.movie.edu. wormhole.movie.edu       A  192.249.249.1 wormhole.movie.edu       A  192.253.253.1 movie.edu                NS  zardoz.movie.edu. zardoz.movie.edu         A  192.249.249.9 zardoz.movie.edu         A  192.253.253.9 ;  End delegation

On the Internet, this information would appear in the edu name servers' zone datafiles. On the movie.edu network, of course, there aren't any edu name servers, so you delegate directly to movie.edu from the root.

Notice that this example doesn't contain delegation to fx.movie.edu or any other subdomain of movie.edu. The movie.edu name servers know which name servers are authoritative for all movie.edu subdomains, and all queries for information in those subdomains pass through the movie.edu name servers, so there's no need to delegate them here.

16.4.4.3 in-addr.arpa delegation

We also need to delegate from the internal roots to the in-addr.arpa zones that correspond to the networks at the university:

; ;  Delegated sub-zone: 249.249.192.in-addr.arpa. ; 249.249.192.in-addr.arpa  NS  terminator.movie.edu. terminator.movie.edu      A   192.249.249.3 249.249.192.in-addr.arpa  NS  wormhole.movie.edu. wormhole.movie.edu        A   192.249.249.1 wormhole.movie.edu        A   192.253.253.1 249.249.192.in-addr.arpa  NS  zardoz.movie.edu. zardoz.movie.edu          A   192.249.249.9 zardoz.movie.edu          A   192.253.253.9 ;  End delegation ; ;  Delegated sub-zone: 253.253.192.in-addr.arpa. ; 253.253.192.in-addr.arpa  NS  terminator.movie.edu. terminator.movie.edu      A   192.249.249.3 253.253.192.in-addr.arpa  NS  wormhole.movie.edu. wormhole.movie.edu        A   192.249.249.1 wormhole.movie.edu        A   192.253.253.1 253.253.192.in-addr.arpa  NS  zardoz.movie.edu. zardoz.movie.edu          A   192.249.249.9 zardoz.movie.edu          A   192.253.253.9 ;  End delegation ; ;  Delegated sub-zone: 254.253.192.in-addr.arpa. ; 254.253.192.in-addr.arpa  NS  bladerunner.fx.movie.edu. bladerunner.fx.movie.edu  A   192.253.254.2 254.253.192.in-addr.arpa  NS  outland.fx.movie.edu. outland.fx.movie.edu      A   192.253.254.3 254.253.192.in-addr.arpa  NS  alien.fx.movie.edu. alien.fx.movie.edu        A   192.253.254.86 ;  End delegation ; ;  Delegated sub-zone: 20.254.192.in-addr.arpa. ; 20.254.192.in-addr.arpa   NS  bladerunner.fx.movie.edu. bladerunner.fx.movie.edu  A   192.253.254.2 20.254.192.in-addr.arpa   NS  outland.fx.movie.edu. outland.fx.movie.edu      A   192.253.254.3 20.254.192.in-addr.arpa   NS  alien.fx.movie.edu. alien.fx.movie.edu        A   192.253.254.86 ;  End delegation

Notice that we did include delegation for the 254.253.192.in-addr.arpa and 20.254.192.in-addr.arpa zones, even though they both correspond to the fx.movie.edu zone. We didn't need to delegate to fx.movie.edu because we'd already delegated to its parent, movie.edu. The movie.edu name servers delegate to fx.movie.edu, so by transitivity the roots delegate to fx.movie.edu. Since neither of the other in-addr.arpa zones is a parent of 254.253.192.in-addr.arpa or 20.254.192.in-addr.arpa, we needed to delegate both zones from the root.

As we've explained earlier, we don't need to add address records for the three Special Effects name servers, bladerunner.fx.movie.edu, outland.fx.movie.edu, and alien.fx.movie.edu, because a remote name server can already find their addresses by following delegation from movie.edu. However, the New Delegation Wizard adds their addresses anyway. Oh, well.

16.4.4.4 The root.dns file

All that's left is to add a root zone with an SOA record and NS records for this internal root name server and any others:

; ;  Database file root.dns for . zone. ;      Zone version:  1 ; @           IN  SOA  rainman.movie.edu.  hostmaster.movie.edu.  (             1            ; serial number             900          ; refresh             600          ; retry             86400        ; expire             3600  ) ; default TTL ; ;  Zone NS records ; @                 NS  rainman.movie.edu. rainman.movie.edu A  192.249.249.254 @                 NS  awakenings.movie.edu awakenings.movie.edu       A  192.253.253.254

rainman.movie.edu and awakenings.movie.edu are the hosts running internal root name servers. We shouldn't run an internal root on a bastion host because if a name server on the Internet accidentally queries it for data it's not authoritative for, the internal root will respond with its list of roots all internal!

So the whole root.dns file (by convention, we call the root zone's datafile root.dns) looks like this:

; ;  Database file root.dns for . zone. ;      Zone version:  4 ; @             IN  SOA  rainman.movie.edu.  hostmaster.movie.edu.  (               1        ; serial number               900      ; refresh               600      ; retry               86400    ; expire               3600  )  ; default TTL ; ;  Zone NS records ; @                  NS  rainman.movie.edu. rainman.movie.edu  A  192.249.249.254 @                  NS  awakenings.movie.edu.awakenings.movie.edu                    A  192.253.253.254 ; ;  Zone records ; ; ;  Delegated sub-zone:  movie.edu. ; movie.edu                 NS  terminator.movie.edu. terminator.movie.edu      A   192.249.249.3 movie.edu                 NS  wormhole.movie.edu. wormhole.movie.edu        A   192.249.249.1 wormhole.movie.edu        A   192.253.253.1 movie.edu                 NS  zardoz.movie.edu. zardoz.movie.edu          A   192.249.249.9 zardoz.movie.edu          A   192.253.253.9 ;  End delegation ; ;  Delegated sub-zone:  249.249.192.in-addr.arpa. ; 249.249.192.in-addr.arpa  NS  terminator.movie.edu. terminator.movie.edu      A   192.249.249.3 249.249.192.in-addr.arpa  NS  wormhole.movie.edu. wormhole.movie.edu        A   192.249.249.1 wormhole.movie.edu        A   192.253.253.1 249.249.192.in-addr.arpa  NS  zardoz.movie.edu. zardoz.movie.edu          A   192.249.249.9 zardoz.movie.edu          A   192.253.253.9 ;  End delegation ; ;  Delegated sub-zone:  253.253.192.in-addr.arpa. ; 253.253.192.in-addr.arpa  NS  terminator.movie.edu. terminator.movie.edu      A   192.249.249.3 253.253.192.in-addr.arpa  NS  wormhole.movie.edu. wormhole.movie.edu        A   192.249.249.1 wormhole.movie.edu        A   192.253.253.1 253.253.192.in-addr.arpa  NS  zardoz.movie.edu. zardoz.movie.edu          A   192.249.249.9 zardoz.movie.edu          A   192.253.253.9 ;  End delegation ; ;  Delegated sub-zone:  254.253.192.in-addr.arpa. ; 254.253.192.in-addr.arpa  NS  bladerunner.fx.movie.edu. bladerunner.fx.movie.edu  A   192.253.254.2 254.253.192.in-addr.arpa  NS  outland.fx.movie.edu. outland.fx.movie.edu      A   192.253.254.3 254.253.192.in-addr.arpa  NS  alien.fx.movie.edu. alien.fx.movie.edu        A   192.253.254.86 ;  End delegation ; ;  Delegated sub-zone:  20.254.192.in-addr.arpa. ; 20.254.192.in-addr.arpa   NS  bladerunner.fx.movie.edu. bladerunner.fx.movie.edu  A   192.253.254.2 20.254.192.in-addr.arpa   NS  outland.fx.movie.edu. outland.fx.movie.edu      A   192.253.254.3 20.254.192.in-addr.arpa   NS  alien.fx.movie.edu. alien.fx.movie.edu        A   192.253.254.86 ;  End delegation

Creating the root zone with the DNS console on both of the internal root name servers, rainman and awakenings, is just like creating any primary zone: right-click on the server's name in the left pane, then choose New Zone. For the zone's domain name, choose "." (a single dot). The DNS console helpfully uses root.dns as the default filename for this zone.

If you don't have a lot of idle hosts sitting around that you can turn into internal roots, don't despair! Any internal name server (i.e., one that's not running on a bastion host or outside your firewall) can serve double duty as an internal root and as an authoritative name server for whatever other zones you need it to load. Remember, a single name server can be authoritative for many, many zones, including the root zone.

16.4.4.5 Configuring other internal name servers

Once you've set up internal root name servers, configure all the name servers on hosts anywhere on your internal network to use them. Any name server running on a host without direct Internet connectivity (i.e., behind the firewall) should list the internal roots in its root hints file:

; ;  Root Name Server Hints File: ; ;       These entries enable the DNS server to locate the root name servers ;       (the DNS servers authoritative for the root zone). ;       For historical reasons this is often referred to as the ;       "Cache File" ; @                     NS  rainman.movie.edu. @                     NS  awakenings.movie.edu rainman.movie.edu     A   192.249.249.254 awakenings.movie.edu  A   192.253.253.254

To edit the root hints, you can open a name server's properties window and choose the Root Hints tab, shown in Figure 16-8. From here, you can delete the old root name servers and add the two new ones.

Figure 16-8. Editing the root hints

Once you've got one name server running with the new root hints, you can use the Copy from Server button to tell other name servers to import its list of root name servers.

Name servers running on hosts using this root hints file can resolve domain names in movie.edu and in Movie U.'s in-addr.arpa domains but not names outside of those domains.

16.4.4.6 How internal name servers use internal roots

To tie together how this whole scheme works, let's go through an example of name resolution on an internal caching-only name server using these internal root name servers. First, the internal name server receives a query for a domain name in movie.edu, say the address of gump.fx.movie.edu. If the internal name server doesn't have any "better" information cached, it starts by querying an internal root name server. If it has communicated with the internal roots before, it has a roundtrip time associated with each, which tells it which of the internal roots is responding to it most quickly. It sends a nonrecursive query to that internal root for gump.fx.movie.edu's address. The internal root answers with a referral to the movie.edu name servers on terminator.movie.edu, wormhole.movie.edu, and zardoz.movie.edu. The caching-only name server follows up by sending another nonrecursive query to one of the movie.edu name servers for gump.fx.movie.edu's address. The movie.edu name server responds with a referral to the fx.movie.edu name servers. The caching-only name server sends the same nonrecursive query for gump.fx.movie.edu's address to one of the fx.movie.edu name servers and finally receives a response.

Contrast this with the way a forwarding setup would have worked. Let's imagine that instead of using internal root name servers, our caching-only name server were configured to forward queries first to terminator.movie.edu and then to wormhole.movie.edu. In that case, the caching-only name server would have checked its cache for the address of gump.fx.movie.edu and, not finding it, would have forwarded the query to terminator.movie.edu. terminator.movie.edu would have queried an fx.movie.edu name server on the caching-only name server's behalf and returned the answer. Should the caching-only name server need to look up another name in fx.movie.edu, it would still ask the forwarder, even though the forwarder's response to the query for gump.fx.movie.edu's address probably contained the names and addresses of the fx.movie.edu name servers.

16.4.4.7 The trouble with internal roots

Unfortunately, just as forwarding has its problems, internal root architectures have their limitations. Chief among these is the fact that your internal hosts can't see the Internet namespace. On some networks this isn't an issue, because most internal hosts don't have direct Internet connectivity. The few that do can have their resolvers configured to use a name server on the bastion host. Some of these hosts probably need to run proxy servers to allow other internal hosts access to services on the Internet.

On other networks, however, the Internet firewall or other software may require that all internal hosts have the ability to resolve names in the Internet namespace. For these networks, an internal root architecture won't work.

16.4.5 A Split Namespace

Many organizations would like to advertise different zone data to the Internet than they do internally. In most cases, much of the internal zone data is irrelevant to the Internet because of the organization's Internet firewall. The firewall may not allow direct access to most internal hosts and may also translate internal, unregistered IP addresses into a range of IP addresses registered to the organization. Therefore, the organization may need to trim out irrelevant information from the external view of the zone or change internal addresses to their external equivalents.

Unfortunately, the Microsoft DNS Server doesn't support automatic filtering and translation of zone data. Consequently, many organizations manually create what have become known as "split namespaces." In a split namespace, the real namespace is available only internally, while a pared-down, translated version of it, called the shadow namespace, is visible to the Internet.

The shadow namespace contains the name-to-address and address-to-name mappings of only those hosts that are accessible from the Internet through the firewall. The addresses advertised may be the translated equivalents of internal addresses. The shadow namespace may also contain one or more MX records to direct mail from the Internet through the firewall to a mail server.

Since Movie U. has an Internet firewall that greatly limits access from the Internet to the internal network, we elected to create a shadow namespace. For the movie.edu zone, we need to give out information about only the domain name movie.edu (an SOA record and a few NS records), the bastion host (postmanrings2x.movie.edu), and our new external name server, ns.movie.edu, which also functions as an external web server, www.movie.edu. The address of the external interface on the bastion host is 200.1.4.2, while the address of the name/web server is 200.1.4.3. The shadow movie.edu zone datafile looks like this:

; ;  Database file movie.edu.dns for movie.edu zone. ;      Zone version 1 ; @                 IN    SOA    ns.movie.edu.    hostmaster.movie.edu. (                          1        ; serial number                          900      ; refresh                          600      ; retry                          86400    ; expire                          3600  )  ; default TTL ; ;  Zone NS records ; @                 NS    ns.movie.edu. ns                A     200.1.4.3 @                 NS    ns1.isp.net ns1.isp.net.      A     200.1.0.2 ; ;  Zone records ; @                 A     200.1.4.3 @                 MX    10 postmanrings2x.movie.edu. @                 MX    100 mail.isp.net. *                 MX    10 postmanrings2x.movie.edu.                   MX    100 mail.isp.net. ns                A     200.1.4.3                   MX    10 postmanrings2x.movie.edu.                   MX    100 mail.isp.net. postmanrings2x    A     200.1.4.2                   MX    10 postmanrings2x.movie.edu.                   MX    100 mail.isp.net. www               CNAME movie.edu.

Note that there's no mention of any of the subdomains of movie.edu, including any delegation to the name servers for those subdomains. That information isn't necessary, since there's nothing in any of the subdomains you can get to from the Internet and inbound mail addressed to hosts in the subdomains is caught by the wildcard.

The 4.1.200.in-addr.arpa.dns file, which we need to reverse map the two Movie U. IP addresses that hosts on the Internet might see, looks like this:

; ;  Database file 4.1.200.in-addr.arpa.dns for 4.1.200.in-addr.arpa zone ; @                 SOA    ns.movie.edu.    hostmaster.movie.edu. (                            1        ; serial number                            900      ; refresh                            600      ; retry                            86400    ; expire                            3600   ) ; default TTL ; ;  Zone NS records ; @             NS    ns.movie.edu. ns.movie.edu. A     200.1.4.3 @             NS    ns1.isp.net. ns1.isp.net.  A     200.1.0.2 ; ;  Zone records ; 2             PTR    postmanrings2x.movie.edu. 3             PTR    ns.movie.edu.

As a precaution, we need to make sure that the resolver on our bastion host isn't configured to use the server on ns.movie.edu. Since that server can't see the real, internal movie.edu, using it would render postmanrings2x.movie.edu unable to map internal names to addresses or internal addresses to names.

16.4.5.1 Configuring the bastion host

The bastion host is a special case in a split-namespace configuration. The bastion host has a foot in each environment: one network interface connects it to the Internet and another connects it to the internal network. Now that we have split our namespace in two, how can our bastion host see both the Internet namespace and our internal namespace? If we configure it with the Internet's root name servers in its root hints file, it will follow delegation from the Internet's edu name servers to an external movie.edu name server with shadow zone data. It would be blind to our internal namespace, which it needs to see to log connections, deliver inbound mail, and more. On the other hand, if we configure it with our internal roots it won't see the Internet namespace, which it clearly needs to do in order to function as a bastion host. What to do?

If we have internal name servers that can resolve both internal and Internet domain names using the forwarding configuration earlier in this chapter, for example we can simply configure the bastion host's resolver to query those name servers. But if we use forwarding internally, depending on the type of firewall we're running, we may also need to run a forwarder on the bastion host itself. If the firewall won't pass DNS traffic, we'll need to run at least a caching-only name server, configured with the Internet roots, on the bastion host so that our internal name servers will have somewhere to forward their unresolved queries.

If our internal name servers don't support per-zone forwarding, the name server on our bastion host must be configured as a secondary for movie.edu and any in-addr.arpa zones in which it needs to resolve addresses. This way, if it receives a query for a domain name in movie.edu, it'll use its local authoritative data to resolve the name. (If our internal name servers support conditional forwarding and are configured correctly, the name server on our bastion host will never receive queries for names in movie.edu.) If the domain name is in a subdomain of movie.edu, it'll follow NS records in the zone data to query an internal name server for the name. Therefore, it doesn't need to be configured as a secondary for any movie.edu subdomains, such as fx.movie.edu, just the "topmost" zone (see Figure 16-9).

Figure 16-9. A split DNS solution