لطفا منتظر باشید ...
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
connectivitythe vast majority of themuse 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 roots13 or sowhereas
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
rootsall 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 namesusing the forwarding configuration
earlier in this chapter, for examplewe 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
