11.3 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 and of its BIND implementation that you can
configure DNS to work with, or even through, an Internet firewall.
That said, configuring BIND to work in a firewalled environment,
although not difficult, takes a good, complete understanding of DNS
and a few of BIND's more obscure features. Describing it also
requires a large portion of this chapter, so here's a roadmap.
We'll 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 BIND to work through the firewall. Next, we'll
detail the two most common DNS architectures used with firewalls,
forwarders and internal roots, and describe the advantages and
disadvantages of each. We'll then introduce a solution using a
new feature, forward zones, which combines the best of internal roots
and forwarders. Finally, we'll discuss split namespaces and the
configuration of the bastion host, the host at the core of your
firewall system.
11.3.1 Types of Firewall Software
Before
you start configuring BIND to work with your firewall, it's
important to understand what your firewall is capable of. Your
firewall's capabilities will influence your choice of DNS
architecture and 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 D.
Zwicky, Simon Cooper, and D. Brent Chapman's
Building
Internet Firewalls (O'Reilly).
11.3.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 on packet-level criteria like the transport protocol
(e.g., whether it's TCP or UDP), the source and destination IP
address, and the source and destination port (see Figure 11-1).
What's most important to us about packet-filtering firewalls is
that you can typically configure them to allow DNS traffic
selectively 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. Checkpoint's FireWall-1,
Cisco's PIX, and Sun's SunScreen are popular commercial
packet-filtering firewalls.
|
BIND 4 name servers always send queries from port 53, the well-known
port for DNS servers, to port 53. Resolvers, on the other hand,
usually send queries from high-numbered ports (above 1023) to port
53. Though name servers clearly have to send their queries
to the DNS port on a remote host, there's
no reason they have to send the queries from the
DNS port. And, wouldn't you know it, BIND 8 and 9 name servers
don't send queries from port 53 by default. Instead, they send
queries from high-numbered ports, the same as resolvers do.
This can cause problems with packet-filtering firewalls that are
configured to allow name server-to-name server traffic but not
resolver-to-name server traffic, because they typically expect name
server-to-name server traffic to originate from port 53 and terminate
at port 53.
There are two solutions to this problem:
query-source takes as arguments an address
specification and an optional port number. For example, the
statement:
options { query-source address * port 53; };
tells BIND to use port 53 as the source port for queries sent from
all local network interfaces. You can use a nonwildcard address
specification to limit the addresses that BIND will send queries
from. For example, on wormhole.movie.edu, the statement:
options { query-source address 192.249.249.1 port *; };
tells BIND to send all queries from the 192.249.249.1 address (i.e.,
not from 192.253.253.1) and to use dynamic, high-numbered ports.
The use of query-source with a wildcard address
is broken in BIND 9 before 9.1.0, though you can tell an early BIND 9
name server to send all queries from a particular address's
port 53.
|
11.3.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 11-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, such as a
RETR (a get) or a
STOR (a put).
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 popular Firewall Toolkit from
Trusted Information Systems (TIS, now
part of Network Associates) is a suite of application gateways for
common Internet protocols such as Telnet, FTP, and HTTP. Network
Associates' Gauntlet product is also based on application
gateways, as is Axent's Eagle Firewall.
Note that these two categories of firewall 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.
11.3.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 really bad idea, for a number of reasons:
- Version control
The developers
of BIND are constantly finding and fixing security-related bugs in
the BIND code. Consequently, it's important to run a recent
version of BIND, especially on name servers 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 any of the name servers on your network can
communicate directly with name servers on the Internet, upgrading all
of them is vastly 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 your allowing DNS traffic
through your firewall and attack that host. For example, a
co-conspirator 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.
11.3.3 Internet Forwarders
Given the dangers of allowing
bidirectional DNS traffic through the firewall unrestricted, most
organizations limit the internal hosts that can "talk
DNS" to the Internet. In 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 11-3).
In 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, this is a small set of
hosts that run name servers under the direct control of the network
administrator (see Figure 11-4).
Internal name servers that can directly query name servers on the
Internet 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 directive or substatement, introduced
in Chapter 10.
Figure 11-5 illustrates a common forwarding setup,
with internal name servers forwarding queries to a name server
running on a bastion host.
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.
Here's how we configured the other internal name servers at the
university. For our BIND 8 and 9 name servers, we used the following:
options {
forwarders { 192.249.249.1; 192.249.249.3; };
forward only;
};
and for our BIND 4 name servers, we used:
forwarders 192.249.249.3 192.249.249.1
options forward-only
We vary the order in which the forwarders appear to help spread the
load between them, though that's not necessary with BIND 8.2.3
name servers, which choose which forwarder to query according to
roundtrip time.
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!
11.3.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, take a look at part of the
configuration file on zardoz.movie.edu:
options {
directory "/var/named";
forwarders { 192.249.249.1; 192.253.253.3; };
};
zone "movie.edu" {
type slave;
masters { 192.249.249.3; };
file "bak.movie.edu";
};
zardoz.movie.edu is a slave
for movie.edu and uses our
two forwarders. What happens when zardoz.movie.edu receives a query for a
name in fx.movie.edu ? As an
authoritative movie.edu name
server, zardoz.movie.edu has the NS records that
delegate fx.movie.edu to its
authoritative name servers. But it's also been configured to
forward queries it can't resolve locally to terminator.movie.edu and wormhole.movie.edu. Which will it do?
It turns out that zardoz.movie.edu ignores the delegation
information and forwards the query to terminator.movie.edu. That works since
terminator.movie.edureceives the recursive query and asks an fx.movie.edu name server on zardoz.movie.edu's behalf. But
it's not particularly efficient since zardoz.movie.edu could easily have sent
the query directly.
Now imagine that 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 the internal name servers
that don't have direct Internet connectivity—the vast
majority of them—use a small set of forwarders. What's
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 stored as authoritative data.
- Concentration of load
The forwarders 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 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. For the
west.acmebw.com name server
to resolve a name in east.acmebw.com, it sends a query to the
forwarder in Bethesda. The forwarder in Bethesda then sends a query
back to Boulder to the east.acmebw.comname 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 with root name servers, the
west.acmebw.com name server
would have learned quickly 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 probably 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.
11.3.3.2 Using forward zones
We can solve this problem by using the forward zones
introduced in BIND 8.2. We change zardoz.movie.edu's configuration
to this:
options {
directory "/var/named";
forwarders { 192.249.249.1; 192.253.253.3; };
};
zone "movie.edu" {
type slave;
masters { 192.249.249.3; };
file "bak.movie.edu";
forwarders {};
};
Now, if zardoz.movie.edu
receives a query for a domain name ending in movie.edu but outside the movie.edu zone (e.g., in fx.movie.edu), it ignores the forwarders
and sends iterative queries.
With this configuration, zardoz.movie.edu still sends queries for
domain names in our reverse-mapping zones to our forwarders. To
relieve that load, we can add a few zone
statements to named.conf:
zone "249.249.192.in-addr.arpa" {
type stub;
masters { 192.249.249.3; };
file "stub.192.249.249";
forwarders {};
};
zone "253.253.192.in-addr.arpa" {
type stub;
masters { 192.249.249.3; };
file "stub.192.253.253";
forwarders {};
};
zone "254.253.192.in-addr.arpa" {
type stub;
masters { 192.253.254.2; };
file "stub.192.253.254";
forwarders {};
};
zone "20.254.192.in-addr.arpa" {
type stub;
masters { 192.253.254.2; };
file "stub.192.254.20";
forwarders {};
};
These new zone statements bear some explaining:
first of all, they configure Movie U.'s reverse-mapping zones
as stubs. That makes our name server track the NS records for those
zones by periodically querying the master name servers for those
zones. The forwarders substatement then turns
off forwarding for domain names in the reverse-mapping domains. Now,
instead of querying the forwarders for, say, the PTR record for
2.254.253.192.in-addr.arpa,
zardoz.movie.edu will query one of the
254.253.192.in-addr.arpaname servers directly.
We'll need zone statements like these on
all of our internal name servers, which also implies that we'll
need all of our name servers to run some version of BIND 8 after
8.2.
This gives us a fairly robust resolution architecture that minimizes
our exposure to the Internet: it uses efficient, robust 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.
11.3.4 Internal Roots
If you want to avoid the scalability
problems of forwarding, you can set up your own root name servers.
These internal roots will 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's 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 will scale better than any other solution.
11.3.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.
11.3.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.edunetwork, the root zone's data file would contain:
movie.edu. 86400 IN NS terminator.movie.edu.
86400 IN NS wormhole.movie.edu.
86400 IN NS zardoz.movie.edu.
terminator.movie.edu. 86400 IN A 192.249.249.3
wormhole.movie.edu. 86400 IN A 192.249.249.1
86400 IN A 192.253.253.1
zardoz.movie.edu. 86400 IN A 192.249.249.9
86400 IN A 192.253.253.9
On the Internet, this information would appear in the edu name servers' zone data files.
On the movie.edu network, of
course, there aren't any eduname servers, so you delegate directly to movie.edu from the root.
Notice that this doesn't contain delegation to fx.movie.edu or to 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.
11.3.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:
249.249.192.in-addr.arpa. 86400 IN NS terminator.movie.edu.
86400 IN NS wormhole.movie.edu.
86400 IN NS zardoz.movie.edu.
253.253.192.in-addr.arpa. 86400 IN NS terminator.movie.edu.
86400 IN NS wormhole.movie.edu.
86400 IN NS zardoz.movie.edu.
254.253.192.in-addr.arpa. 86400 IN NS bladerunner.fx.movie.edu.
86400 IN NS outland.fx.movie.edu.
86400 IN NS alien.fx.movie.edu.
20.254.192.in-addr.arpa. 86400 IN NS bladerunner.fx.movie.edu.
86400 IN NS outland.fx.movie.edu.
86400 IN NS alien.fx.movie.edu.
Notice that we did include delegation for the
254.253.192.in-addr.arpa and
the 20.254.192.in-addr.arpazones, even though they correspond to the fx.movie.edu zone. We don'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.arpaor 20.254.192.in-addr.arpa, we need to
delegate both zones from the root. As we 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.
11.3.4.4 The db.root file
All that's left is to add an SOA
record for the root zone and NS records for this internal root name
server and any others:
$TTL 1d
. IN SOA rainman.movie.edu. hostmaster.movie.edu. (
1 ; serial
3h ; refresh
1h ; retry
1w ; expire
1h ) ; negative caching TTL
IN NS rainman.movie.edu.
IN NS awakenings.movie.edu.
rainman.movie.edu. IN A 192.249.249.254
awakenings.movie.edu. IN A 192.253.253.254
rainman.movie.edu and
awakenings.movie.edu are the
hosts running the 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 db.root file (by convention, we
call the root zone's data file db.root)
looks like this:
$TTL 1d
. IN SOA rainman.movie.edu. hostmaster.movie.edu. (
1 ; serial
3h ; refresh
1h ; retry
1w ; expire
1h ) ; negative caching TTL
IN NS rainman.movie.edu.
IN NS awakenings.movie.edu.
rainman.movie.edu. IN A 192.249.249.254
awakenings.movie.edu. IN A 192.253.253.254
movie.edu. IN NS terminator.movie.edu.
IN NS wormhole.movie.edu.
IN NS zardoz.movie.edu.
terminator.movie.edu. IN A 192.249.249.3
wormhole.movie.edu. IN A 192.249.249.1
IN A 192.253.253.1
zardoz.movie.edu. IN A 192.249.249.9
IN A 192.253.253.9
249.249.192.in-addr.arpa. IN NS terminator.movie.edu.
IN NS wormhole.movie.edu.
IN NS zardoz.movie.edu.
253.253.192.in-addr.arpa. IN NS terminator.movie.edu.
IN NS wormhole.movie.edu.
IN NS zardoz.movie.edu.
254.253.192.in-addr.arpa. IN NS bladerunner.fx.movie.edu.
IN NS outland.fx.movie.edu.
IN NS alien.fx.movie.edu.
20.254.192.in-addr.arpa. IN NS bladerunner.fx.movie.edu.
IN NS outland.fx.movie.edu.
IN NS alien.fx.movie.edu.
The named.conf file on both the internal root
name servers, rainman.movie.eduand awakenings.movie.edu, contains the
lines:
zone "." {
type master;
file "db.root";
};
Or, for a BIND 4 server's named.boot file:
primary . db.root
This replaces a zone statement of type
hint or a cache
directive—a root name server doesn't need a
root hints file to tell it where the other roots are; it can find
that in db.root. Did we really mean that
eachroot name server is a primary master for
the root zone? Not unless you're running an ancient version of
BIND. All BIND versions after 4.9 let you declare a server as a slave
for the root zone, but BIND 4.8.3 and earlier insist that all root
name servers load the root zone as primaries.
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.
11.3.4.5 Configuring other internal name servers
Once you've set up internal root name servers, configure all
your 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:
; Internal root hints file, for Movie U. hosts without direct
; Internet connectivity
;
; Don't use this file on a host with Internet connectivity!
;
. 99999999 IN NS rainman.movie.edu.
99999999 IN NS awakenings.movie.edu.
rainman.movie.edu. 99999999 IN A 192.249.249.254
awakenings.movie.edu. 99999999 IN A 192.253.253.254
Name servers running on hosts using this root hints file will be able
to resolve domain names in movie.edu and in Movie U.'s
in-addr.arpa domains, but
not outside those domains.
11.3.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, telling it which of the
internal roots is responding to it most quickly. It then 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.eduname servers and finally receives a response.
Contrast this with the way a forwarding setup would work. 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 check its cache for
the address of gump.fx.movie.eduand, not finding it, would forward the query to
terminator.movie.edu. Then,
terminator.movie.edu would
query an fx.movie.edu name
server on the caching-only name server's behalf and return 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 contains the names and addresses of the fx.movie.edu name servers.
11.3.4.7 Mail from internal hosts to the Internet
But wait! That's not all internal
roots will do for you. We talked about getting mail to the Internet
without changing sendmail 's configuration
all over the network.
Wildcard records are the key to getting mail to
work—specifically, wildcard MX records. Let's say that we want
mail to the Internet to be forwarded through postmanrings2x.movie.edu, the Movie U.
bastion host, which has direct Internet connectivity. Adding the
following records to db.root will get the job
done:
* IN MX 5 postmanrings2x.movie.edu.
*.edu. IN MX 10 postmanrings2x.movie.edu.
We need the *.edu MX record
in addition to the * record
because of wildcard production rules, which you can read more about
in Section 16.2 of Chapter 16. Basically, since there is explicit data for
movie.edu in the zone, the
first wildcard won't match movie.edu or any other subdomains of
edu. We need another,
explicit wildcard record for eduto match subdomains of edubesides movie.edu.
Now mailers on our internal movie.eduhosts will send mail addressed to Internet domain names
to postmanrings2x.movie.edufor forwarding. For example, mail addressed to
nic.ddn.mil will match the
first wildcard MX record:
% nslookup -type=mx nic.ddn.mil. —Matches the MX record for *
Server: rainman.movie.edu
Address: 192.249.249.19
nic.ddn.mil
preference = 5, mail exchanger = postmanrings2x.movie.edu
postmanrings2x.movie.edu internet address = 192.249.249.20
Mail addressed to vangogh.cs.berkeley.eduwill match the second MX record:
% nslookup -type=mx vangogh.cs.berkeley.edu. —Matches the MX record for *.edu
Server: rainman.movie.edu
Address: 192.249.249.19
vangogh.cs.berkeley.edu
preference = 10, mail exchanger = postmanrings2x.movie.edu
postmanrings2x.movie.edu internet address = 192.249.249.20
Once the mail has reached postmanrings2x.movie.edu, our bastion
host, postmanrings2x.movie.edu's mailer
will look up the MX records for these addresses itself. Since
postmanrings2x.movie.edu
will resolve the destination's domain name using the
Internet's namespace instead of the internal namespace, it will
find the real MX records for the domain name and deliver the mail. No
changes to sendmail 's configuration are
necessary.
11.3.4.8 Mail to specific Internet domain names
Another nice perk of this internal
root scheme is that it gives you the ability to forward mail
addressed to certain Internet domain names through particular bastion
hosts, if you have more than one. We can choose, for example, to send
all mail addressed to recipients in the uk domain to our bastion host in London
first and then out onto the Internet. This can be very useful if we
want our mail to travel across our own network as far as possible or
if we're billed for our usage of some network in the U.K.
Movie U. has a private network connection to our sister university in
London near Pinewood Studios. For security reasons, we'd like
to send mail addressed to correspondents in the U.K. across our
private link and then through the Pinewood host. So we add the
following wildcard records to db.root:
; holygrail.movie.ac.uk is at the other end of our U.K. Internet link
*.uk. IN MX 10 holygrail.movie.ac.uk.
holygrail.movie.ac.uk. IN A 192.168.76.4
Now, mail addressed to users in subdomains of uk will be forwarded to the host
holygrail.movie.ac.uk at our
sister university, which presumably has facilities to forward that
mail to other points in the U.K.
11.3.4.9 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 any 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 will 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's namespace. For these networks, an internal
root architecture won't work.
11.3.5 A Split Namespace
Many
organizations would like to advertise different zone data to the
Internet than they advertise 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 might
need to trim out irrelevant information from the external view of the
zone or change internal addresses to their external equivalents.
Unfortunately, BIND 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 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 zone movie.edu, the only information we need
to give out is about 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, and the address
of the name/web server is 200.1.4.3. The shadow movie.edu zone data file looks like
this:
$TTL 1d
@ IN SOA ns.movie.edu. hostmaster.movie.edu. (
1 ; Serial
3h ; Refresh
1h ; Retry
1w ; Expire
1h ) ; Negative caching TTL
IN NS ns.movie.edu.
IN NS ns1.isp.net. ; our ISP's name server is a movie.edu slave
IN A 200.1.4.3
IN MX 10 postmanrings2x.movie.edu.
IN MX 100 mail.isp.net.
www IN CNAME movie.edu.
postmanrings2x IN A 200.1.4.2
IN MX 10 postmanrings2x.movie.edu.
IN MX 100 mail.isp.net.
;postmanrings2x.movie.edu handles mail addressed to ns.movie.edu
ns IN A 200.1.4.3
IN MX 10 postmanrings2x.movie.edu.
IN MX 100 mail.isp.net.
* IN MX 10 postmanrings2x.movie.edu.
IN MX 100 mail.isp.net.
Note that there's no mention of any of the subdomains of
movie.edu, including any
delegation to the name servers for those subdomains. The information
simply isn't necessary since there's nothing in any of
the subdomains that you can get to from the Internet, and inbound
mail addressed to hosts in the subdomains is caught by the wildcard.
The db.200.1.4 file, which we need in order to
reverse map the two Movie U. IP addresses that hosts on the Internet
might see, looks like this:
$TTL 1d
@ IN SOA ns.movie.edu. hostmaster.movie.edu. (
1 ; Serial
3h ; Refresh
1h ; Retry
1w ; Expire
1h ) ; Negative caching TTL
IN NS ns.movie.edu.
IN NS ns.isp.net.
2 IN PTR postmanrings2x.movie.edu.
3 IN PTR ns1.movie.edu.
One precaution we have to take is 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 domain names to addresses or internal
addresses to names.
11.3.5.1 Configuring the bastion host
The
bastion host is a special case in a split namespace configuration. It
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 real 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, then it won't see the Internet's
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 forward zones per the 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 forward zones, the
name server on our bastion host must be configured as a slave 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
uses its local authoritative data to resolve the name. (If our
internal name servers support forward zones 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
delegated subdomain of movie.edu, it follows 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 slave for any movie.edu subdomains, such as
fx.movie.edu, just the
"topmost" zone (see Figure 11-6).
The named.conf file
on our bastion host looks like this:
options {
directory "/var/named";
};
zone "movie.edu" {
type slave;
masters { 192.249.249.3; };
file "bak.movie.edu";
};
zone "249.249.192.in-addr.arpa" {
type slave;
masters { 192.249.249.3; };
file "bak.192.249.249";
};
zone "253.253.192.in-addr.arpa" {
type slave;
masters { 192.249.249.3; };
file "bak.192.253.253";
};
zone "254.253.192.in-addr.arpa" {
type slave;
masters { 192.253.254.2; };
file "bak.192.253.254";
};
zone "20.254.192.in-addr.arpa" {
type slave;
masters { 192.253.254.2; };
file "bak.192.254.20";
};
zone "." {
type hint;
file "db.cache";
};
An equivalent named.boot file would look like
this:
directory /var/named
secondary movie.edu 192.249.249.3 bak.movie.edu
secondary 249.249.192.in-addr.arpa 192.249.249.3 bak.192.249.249
secondary 253.253.192.in-addr.arpa 192.249.249.3 bak.192.253.253
secondary 254.253.192.in-addr.arpa 192.253.254.2 bak.192.253.254
secondary 20.254.192.in-addr.arpa 192.253.254.2 bak.192.254.20
cache . db.cache ; lists Internet roots
11.3.5.2 Protecting zone data on the bastion host
Unfortunately, loading these zones
on the bastion host also exposes them to the possibility of
disclosure on the Internet, which we were trying to avoid by
splitting the namespace in the first place. But as long as
we're running BIND 4.9 or better, we can protect the zone data
using the secure_zone TXT
record or the allow-query substatement, both
discussed earlier in the chapter. With
allow-query, we can place a global access list
on our zone data. Here's the new options
statement from our named.conf file:
options {
directory "/var/named";
allow-query { 127/8; 192.249.249/24; 192.253.253/24;
192.253.254/24; 192.254.20/24; };
};
With BIND 4.9's secure_zone feature, we can turn off all
external access to our zone data by including these TXT records in
each zone data file:
secure_zone IN TXT "192.249.249.0:255.255.255.0"
IN TXT "192.253.253.0:255.255.255.0"
IN TXT "192.253.254.0:255.255.255.0"
IN TXT "192.254.20.0:255.255.255.0"
IN TXT "127.0.0.1:H"
Don't forget to include the loopback address in the list, or
the bastion host's resolver may not get answers from its own
name server!
11.3.5.3 The final configuration
Finally, we need to apply the other security precautions we discussed
earlier to our bastion host's name server. In particular, we
should:
In the end, our named.conf file ends up looking
like this:
acl "internal" {
127/8; 192.249.249/24; 192.253.253/24;
192.253.254/24; 192.254.20/24;
};
options {
directory "/var/named";
allow-query { "internal"; };
allow-transfer { none; };
use-id-pool yes;
};
zone "movie.edu" {
type slave;
masters { 192.249.249.3; };
file "bak.movie.edu";
};
zone "249.249.192.in-addr.arpa" {
type slave;
masters { 192.249.249.3; };
file "bak.192.249.249";
};
zone "253.253.192.in-addr.arpa" {
type slave;
masters { 192.249.249.3; };
file "bak.192.253.253";
};
zone "254.253.192.in-addr.arpa" {
type slave;
masters { 192.253.254.2; };
file "bak.192.253.254";
};
zone "20.254.192.in-addr.arpa" {
type slave;
masters { 192.253.254.2; };
file "bak.192.254.20";
};
zone "." {
type hint;
file "db.cache";
};
11.3.5.4 Using views on the bastion host
If we're running BIND 9 on our
bastion host, we can use views to safely present the shadow
movie.edu to the outside
world on the same name server that resolves Internet domain names.
That may obviate the need to run an external name server on the same
host as our web server, www.movie.edu. If not, it'll give
us two name servers to advertise the external movie.edu.
This configuration is very similar to one shown in Section 10.6:
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 slave;
masters { 192.249.249.3; };
file "bak.movie.edu";
};
zone "249.249.192.in-addr.arpa" {
type slave;
masters { 192.249.249.3; };
file "bak.192.249.249";
};
zone "253.253.192.in-addr.arpa" {
type slave;
masters { 192.249.249.3; };
file "bak.192.253.253";
};
zone "254.253.192.in-addr.arpa" {
type slave;
masters { 192.253.254.2; };
file "bak.192.253.254";
};
zone "20.254.192.in-addr.arpa" {
type slave;
masters { 192.253.254.2; };
file "bak.192.254.20";
};
zone "." {
type hint;
file "db.cache";
};
};
view "external" {
match-clients { any; };
recursion no;
acl "ns1.isp.net" { 199.11.28.12; };
zone "movie.edu" {
type master;
file "db.movie.edu.external";
allow-transfer { "ns1.isp.net"; };
};
zone "4.1.200.in-addr.arpa" {
type master;
file "db.200.1.4";
allow-transfer { "ns1.isp.net"; };
};
zone "." {
type hint;
file "db.cache";
};
};
Notice that the internal and external views present different
versions of movie.edu: one loaded from the zone
data file db.movie.edu, and one loaded from
db.movie.edu.external. If there were more than a
few zones in our external view, we probably would have used a
different subdirectory for our external zone data files than we used
for the internal zone data files.
|
