Bind 9 Administrator Reference Manual

Chapter 4. Advanced Concepts

4.2. Incremental Zone Transfers (IXFR)

The incremental zone transfer (IXFR) protocol is a way for slave servers to transfer only changed data,

instead of having to transfer the entire zone. The IXFR protocol is documented in RFC 1995. See

Proposed Standards.

When acting as a master, BIND 9 supports IXFR for those zones where the necessary change history

information is available. These include master zones maintained by dynamic update and slave zones

whose data was obtained by IXFR, but not manually maintained master zones nor slave zones obtained

by performing a full zone transfer (AXFR).

When acting as a slave, BIND 9 will attempt to use IXFR unless it is explicitly disabled. For more

information about disabling IXFR, see the description of the request-ixfr clause of the server statement.

4.3. Split DNS

Setting up different views, or visibility, of DNS space to internal and external resolvers is usually referred

to as a Split DNS setup. There are several reasons an organization would want to set up its DNS this way.

One common reason for setting up a DNS system this way is to hide "internal" DNS information from

"external" clients on the Internet. There is some debate as to whether or not this is actually useful.

Internal DNS information leaks out in many ways (via email headers, for example) and most savvy

"attackers" can ﬁnd the information they need using other means.

Another common reason for setting up a Split DNS system is to allow internal networks that are behind

ﬁlters or in RFC 1918 space (reserved IP space, as documented in RFC 1918) to resolve DNS on the

Internet. Split DNS can also be used to allow mail from outside back in to the internal network.

Here is an example of a split DNS setup:

Let’s say a company named Example, Inc. (example.com) has several corporate sites that have an internal

network with reserved Internet Protocol (IP) space and an external demilitarized zone (DMZ), or

"outside" section of a network, that is available to the public.

Example, Inc. wants its internal clients to be able to resolve external hostnames and to exchange mail

with people on the outside. The company also wants its internal resolvers to have access to certain

internal-only zones that are not available at all outside of the internal network.

In order to accomplish this, the company will set up two sets of nameservers. One set will be on the

inside network (in the reserved IP space) and the other set will be on bastion hosts, which are "proxy"

hosts that can talk to both sides of its network, in the DMZ.

The internal servers will be conﬁgured to forward all queries, except queries for site1.internal,

site2.internal, site1.example.com, and site2.example.com, to the servers in the DMZ.