2004-09-19 01:30:24 +00:00
|
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
|
|
|
<HTML
|
|
|
|
|
><HEAD
|
|
|
|
|
><TITLE
|
|
|
|
|
>Advanced DNS Features</TITLE
|
|
|
|
|
><META
|
|
|
|
|
NAME="GENERATOR"
|
|
|
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
|
|
|
REL="HOME"
|
|
|
|
|
TITLE="BIND 9 Administrator Reference Manual"
|
|
|
|
|
HREF="Bv9ARM.html"><LINK
|
|
|
|
|
REL="PREVIOUS"
|
|
|
|
|
TITLE="Name Server Configuration"
|
|
|
|
|
HREF="Bv9ARM.ch03.html"><LINK
|
|
|
|
|
REL="NEXT"
|
|
|
|
|
TITLE="The BIND 9 Lightweight Resolver"
|
|
|
|
|
HREF="Bv9ARM.ch05.html"></HEAD
|
|
|
|
|
><BODY
|
|
|
|
|
CLASS="chapter"
|
|
|
|
|
BGCOLOR="#FFFFFF"
|
|
|
|
|
TEXT="#000000"
|
|
|
|
|
LINK="#0000FF"
|
|
|
|
|
VLINK="#840084"
|
|
|
|
|
ALINK="#0000FF"
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="NAVHEADER"
|
|
|
|
|
><TABLE
|
|
|
|
|
SUMMARY="Header navigation table"
|
|
|
|
|
WIDTH="100%"
|
|
|
|
|
BORDER="0"
|
|
|
|
|
CELLPADDING="0"
|
|
|
|
|
CELLSPACING="0"
|
|
|
|
|
><TR
|
|
|
|
|
><TH
|
|
|
|
|
COLSPAN="3"
|
|
|
|
|
ALIGN="center"
|
|
|
|
|
>BIND 9 Administrator Reference Manual</TH
|
|
|
|
|
></TR
|
|
|
|
|
><TR
|
|
|
|
|
><TD
|
|
|
|
|
WIDTH="10%"
|
|
|
|
|
ALIGN="left"
|
|
|
|
|
VALIGN="bottom"
|
|
|
|
|
><A
|
|
|
|
|
HREF="Bv9ARM.ch03.html"
|
|
|
|
|
ACCESSKEY="P"
|
|
|
|
|
>Prev</A
|
|
|
|
|
></TD
|
|
|
|
|
><TD
|
|
|
|
|
WIDTH="80%"
|
|
|
|
|
ALIGN="center"
|
|
|
|
|
VALIGN="bottom"
|
|
|
|
|
></TD
|
|
|
|
|
><TD
|
|
|
|
|
WIDTH="10%"
|
|
|
|
|
ALIGN="right"
|
|
|
|
|
VALIGN="bottom"
|
|
|
|
|
><A
|
|
|
|
|
HREF="Bv9ARM.ch05.html"
|
|
|
|
|
ACCESSKEY="N"
|
|
|
|
|
>Next</A
|
|
|
|
|
></TD
|
|
|
|
|
></TR
|
|
|
|
|
></TABLE
|
|
|
|
|
><HR
|
|
|
|
|
ALIGN="LEFT"
|
|
|
|
|
WIDTH="100%"></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="chapter"
|
|
|
|
|
><H1
|
|
|
|
|
><A
|
|
|
|
|
NAME="ch04"
|
|
|
|
|
></A
|
|
|
|
|
>Chapter 4. Advanced DNS Features</H1
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="TOC"
|
|
|
|
|
><DL
|
|
|
|
|
><DT
|
|
|
|
|
><B
|
|
|
|
|
>Table of Contents</B
|
|
|
|
|
></DT
|
|
|
|
|
><DT
|
|
|
|
|
>4.1. <A
|
|
|
|
|
HREF="Bv9ARM.ch04.html#notify"
|
|
|
|
|
>Notify</A
|
|
|
|
|
></DT
|
|
|
|
|
><DT
|
|
|
|
|
>4.2. <A
|
|
|
|
|
HREF="Bv9ARM.ch04.html#dynamic_update"
|
|
|
|
|
>Dynamic Update</A
|
|
|
|
|
></DT
|
|
|
|
|
><DT
|
|
|
|
|
>4.3. <A
|
|
|
|
|
HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
|
|
|
|
|
>Incremental Zone Transfers (IXFR)</A
|
|
|
|
|
></DT
|
|
|
|
|
><DT
|
|
|
|
|
>4.4. <A
|
2005-03-17 08:04:02 +00:00
|
|
|
HREF="Bv9ARM.ch04.html#AEN767"
|
2004-09-19 01:30:24 +00:00
|
|
|
>Split DNS</A
|
|
|
|
|
></DT
|
|
|
|
|
><DT
|
|
|
|
|
>4.5. <A
|
|
|
|
|
HREF="Bv9ARM.ch04.html#tsig"
|
|
|
|
|
>TSIG</A
|
|
|
|
|
></DT
|
|
|
|
|
><DT
|
|
|
|
|
>4.6. <A
|
2005-03-17 08:04:02 +00:00
|
|
|
HREF="Bv9ARM.ch04.html#AEN927"
|
2004-09-19 01:30:24 +00:00
|
|
|
>TKEY</A
|
|
|
|
|
></DT
|
|
|
|
|
><DT
|
|
|
|
|
>4.7. <A
|
2005-03-17 08:04:02 +00:00
|
|
|
HREF="Bv9ARM.ch04.html#AEN942"
|
2004-09-19 01:30:24 +00:00
|
|
|
>SIG(0)</A
|
|
|
|
|
></DT
|
|
|
|
|
><DT
|
|
|
|
|
>4.8. <A
|
|
|
|
|
HREF="Bv9ARM.ch04.html#DNSSEC"
|
|
|
|
|
>DNSSEC</A
|
|
|
|
|
></DT
|
|
|
|
|
><DT
|
|
|
|
|
>4.9. <A
|
2005-03-17 08:04:02 +00:00
|
|
|
HREF="Bv9ARM.ch04.html#AEN1011"
|
2004-09-19 01:30:24 +00:00
|
|
|
>IPv6 Support in <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9</A
|
|
|
|
|
></DT
|
|
|
|
|
></DL
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><H1
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><A
|
|
|
|
|
NAME="notify"
|
|
|
|
|
>4.1. Notify</A
|
|
|
|
|
></H1
|
|
|
|
|
><P
|
|
|
|
|
><ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>DNS</ACRONYM
|
|
|
|
|
> NOTIFY is a mechanism that allows master
|
|
|
|
|
servers to notify their slave servers of changes to a zone's data. In
|
|
|
|
|
response to a <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>NOTIFY</B
|
|
|
|
|
> from a master server, the
|
|
|
|
|
slave will check to see that its version of the zone is the
|
|
|
|
|
current version and, if not, initiate a zone transfer.</P
|
|
|
|
|
><P
|
|
|
|
|
><ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>DNS</ACRONYM
|
|
|
|
|
>
|
|
|
|
|
For more information about
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>NOTIFY</B
|
|
|
|
|
>, see the description of the
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>notify</B
|
|
|
|
|
> option in <A
|
|
|
|
|
HREF="Bv9ARM.ch06.html#boolean_options"
|
|
|
|
|
>Section 6.2.16.1</A
|
|
|
|
|
> and
|
|
|
|
|
the description of the zone option <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>also-notify</B
|
|
|
|
|
> in
|
|
|
|
|
<A
|
|
|
|
|
HREF="Bv9ARM.ch06.html#zone_transfers"
|
|
|
|
|
>Section 6.2.16.7</A
|
|
|
|
|
>. The <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>NOTIFY</B
|
|
|
|
|
>
|
|
|
|
|
protocol is specified in RFC 1996.
|
|
|
|
|
</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><H1
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><A
|
|
|
|
|
NAME="dynamic_update"
|
|
|
|
|
>4.2. Dynamic Update</A
|
|
|
|
|
></H1
|
|
|
|
|
><P
|
|
|
|
|
>Dynamic Update is a method for adding, replacing or deleting
|
|
|
|
|
records in a master server by sending it a special form of DNS
|
|
|
|
|
messages. The format and meaning of these messages is specified
|
|
|
|
|
in RFC 2136.</P
|
|
|
|
|
><P
|
|
|
|
|
>Dynamic update is enabled on a zone-by-zone basis, by
|
|
|
|
|
including an <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>allow-update</B
|
|
|
|
|
> or
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>update-policy</B
|
|
|
|
|
> clause in the
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>zone</B
|
|
|
|
|
> statement.</P
|
|
|
|
|
><P
|
|
|
|
|
>Updating of secure zones (zones using DNSSEC) follows
|
|
|
|
|
RFC 3007: RRSIG and NSEC records affected by updates are automatically
|
|
|
|
|
regenerated by the server using an online zone key.
|
|
|
|
|
Update authorization is based
|
|
|
|
|
on transaction signatures and an explicit server policy.</P
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
|
|
|
|
NAME="journal"
|
|
|
|
|
>4.2.1. The journal file</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>All changes made to a zone using dynamic update are stored in the
|
|
|
|
|
zone's journal file. This file is automatically created by the
|
|
|
|
|
server when when the first dynamic update takes place. The name of
|
|
|
|
|
the journal file is formed by appending the
|
|
|
|
|
extension <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>.jnl</TT
|
|
|
|
|
> to the
|
|
|
|
|
name of the corresponding zone file. The journal file is in a
|
|
|
|
|
binary format and should not be edited manually.</P
|
|
|
|
|
><P
|
|
|
|
|
>The server will also occasionally write ("dump")
|
|
|
|
|
the complete contents of the updated zone to its zone file.
|
|
|
|
|
This is not done immediately after
|
|
|
|
|
each dynamic update, because that would be too slow when a large
|
|
|
|
|
zone is updated frequently. Instead, the dump is delayed by
|
|
|
|
|
up to 15 minutes, allowing additional updates to take place.</P
|
|
|
|
|
><P
|
|
|
|
|
>When a server is restarted after a shutdown or crash, it will replay
|
|
|
|
|
the journal file to incorporate into the zone any updates that took
|
|
|
|
|
place after the last zone dump.</P
|
|
|
|
|
><P
|
|
|
|
|
>Changes that result from incoming incremental zone transfers are also
|
|
|
|
|
journalled in a similar way.</P
|
|
|
|
|
><P
|
|
|
|
|
>The zone files of dynamic zones cannot normally be edited by
|
|
|
|
|
hand because they are not guaranteed to contain the most recent
|
|
|
|
|
dynamic changes - those are only in the journal file.
|
|
|
|
|
The only way to ensure that the zone file of a dynamic zone
|
|
|
|
|
is up to date is to run <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>rndc stop</B
|
|
|
|
|
>.</P
|
|
|
|
|
><P
|
|
|
|
|
>If you have to make changes to a dynamic zone
|
|
|
|
|
manually, the following procedure will work: Disable dynamic updates
|
|
|
|
|
to the zone using
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>rndc freeze <VAR
|
|
|
|
|
CLASS="replaceable"
|
|
|
|
|
>zone</VAR
|
|
|
|
|
></B
|
|
|
|
|
>.
|
|
|
|
|
This will also remove the zone's <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>.jnl</TT
|
|
|
|
|
> file
|
|
|
|
|
and update the master file. Edit the zone file. Run
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>rndc unfreeze <VAR
|
|
|
|
|
CLASS="replaceable"
|
|
|
|
|
>zone</VAR
|
|
|
|
|
></B
|
|
|
|
|
>
|
|
|
|
|
to reload the changed zone and re-enable dynamic updates.</P
|
|
|
|
|
></DIV
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><H1
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><A
|
|
|
|
|
NAME="incremental_zone_transfers"
|
|
|
|
|
>4.3. Incremental Zone Transfers (IXFR)</A
|
|
|
|
|
></H1
|
|
|
|
|
><P
|
|
|
|
|
>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 specified in RFC
|
|
|
|
|
1995. See <A
|
|
|
|
|
HREF="Bv9ARM.ch09.html#proposed_standards"
|
|
|
|
|
>Proposed Standards</A
|
|
|
|
|
>.</P
|
|
|
|
|
><P
|
|
|
|
|
>When acting as a master, <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 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. For manually maintained master
|
|
|
|
|
zones, and for slave zones obtained by performing a full zone
|
|
|
|
|
transfer (AXFR), IXFR is supported only if the option
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>ixfr-from-differences</B
|
|
|
|
|
> is set
|
|
|
|
|
to <KBD
|
|
|
|
|
CLASS="userinput"
|
|
|
|
|
>yes</KBD
|
|
|
|
|
>.
|
|
|
|
|
</P
|
|
|
|
|
><P
|
|
|
|
|
>When acting as a slave, <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 will
|
|
|
|
|
attempt to use IXFR unless
|
|
|
|
|
it is explicitly disabled. For more information about disabling
|
|
|
|
|
IXFR, see the description of the <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>request-ixfr</B
|
|
|
|
|
> clause
|
|
|
|
|
of the <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>server</B
|
|
|
|
|
> statement.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><H1
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN767"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.4. Split DNS</A
|
|
|
|
|
></H1
|
|
|
|
|
><P
|
|
|
|
|
>Setting up different views, or visibility, of the DNS space to
|
|
|
|
|
internal and external resolvers is usually referred to as a <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>Split
|
|
|
|
|
DNS</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> setup. There are several reasons an organization
|
|
|
|
|
would want to set up its DNS this way.</P
|
|
|
|
|
><P
|
|
|
|
|
>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 find the information
|
|
|
|
|
they need using other means.</P
|
|
|
|
|
><P
|
|
|
|
|
>Another common reason for setting up a Split DNS system is
|
|
|
|
|
to allow internal networks that are behind filters 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.</P
|
|
|
|
|
><P
|
|
|
|
|
>Here is an example of a split DNS setup:</P
|
|
|
|
|
><P
|
|
|
|
|
>Let's say a company named <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>Example, Inc.</I
|
|
|
|
|
></SPAN
|
|
|
|
|
>
|
|
|
|
|
(<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>example.com</VAR
|
|
|
|
|
>)
|
|
|
|
|
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.</P
|
|
|
|
|
><P
|
|
|
|
|
><SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>Example, Inc.</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> 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.</P
|
|
|
|
|
><P
|
|
|
|
|
>In order to accomplish this, the company will set up two sets
|
|
|
|
|
of name servers. 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.</P
|
|
|
|
|
><P
|
|
|
|
|
>The internal servers will be configured to forward all queries,
|
|
|
|
|
except queries for <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site1.internal</TT
|
|
|
|
|
>, <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site2.internal</TT
|
|
|
|
|
>, <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site1.example.com</TT
|
|
|
|
|
>,
|
|
|
|
|
and <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site2.example.com</TT
|
|
|
|
|
>, to the servers in the
|
|
|
|
|
DMZ. These internal servers will have complete sets of information
|
|
|
|
|
for <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site1.example.com</TT
|
|
|
|
|
>, <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site2.example.com</TT
|
|
|
|
|
>,<SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
> </I
|
|
|
|
|
></SPAN
|
|
|
|
|
><TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site1.internal</TT
|
|
|
|
|
>,
|
|
|
|
|
and <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site2.internal</TT
|
|
|
|
|
>.</P
|
|
|
|
|
><P
|
|
|
|
|
>To protect the <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site1.internal</TT
|
|
|
|
|
> and <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site2.internal</TT
|
|
|
|
|
> domains,
|
|
|
|
|
the internal name servers must be configured to disallow all queries
|
|
|
|
|
to these domains from any external hosts, including the bastion
|
|
|
|
|
hosts.</P
|
|
|
|
|
><P
|
|
|
|
|
>The external servers, which are on the bastion hosts, will
|
|
|
|
|
be configured to serve the "public" version of the <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site1</TT
|
|
|
|
|
> and <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site2.example.com</TT
|
|
|
|
|
> zones.
|
|
|
|
|
This could include things such as the host records for public servers
|
|
|
|
|
(<TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>www.example.com</TT
|
|
|
|
|
> and <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>ftp.example.com</TT
|
|
|
|
|
>),
|
|
|
|
|
and mail exchange (MX) records (<TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>a.mx.example.com</TT
|
|
|
|
|
> and <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>b.mx.example.com</TT
|
|
|
|
|
>).</P
|
|
|
|
|
><P
|
|
|
|
|
>In addition, the public <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site1</TT
|
|
|
|
|
> and <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>site2.example.com</TT
|
|
|
|
|
> zones
|
|
|
|
|
should have special MX records that contain wildcard (`*') records
|
|
|
|
|
pointing to the bastion hosts. This is needed because external mail
|
|
|
|
|
servers do not have any other way of looking up how to deliver mail
|
|
|
|
|
to those internal hosts. With the wildcard records, the mail will
|
|
|
|
|
be delivered to the bastion host, which can then forward it on to
|
|
|
|
|
internal hosts.</P
|
|
|
|
|
><P
|
|
|
|
|
>Here's an example of a wildcard MX record:</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
><VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>* IN MX 10 external1.example.com.</VAR
|
|
|
|
|
></PRE
|
|
|
|
|
><P
|
|
|
|
|
>Now that they accept mail on behalf of anything in the internal
|
|
|
|
|
network, the bastion hosts will need to know how to deliver mail
|
|
|
|
|
to internal hosts. In order for this to work properly, the resolvers on
|
|
|
|
|
the bastion hosts will need to be configured to point to the internal
|
|
|
|
|
name servers for DNS resolution.</P
|
|
|
|
|
><P
|
|
|
|
|
>Queries for internal hostnames will be answered by the internal
|
|
|
|
|
servers, and queries for external hostnames will be forwarded back
|
|
|
|
|
out to the DNS servers on the bastion hosts.</P
|
|
|
|
|
><P
|
|
|
|
|
>In order for all this to work properly, internal clients will
|
|
|
|
|
need to be configured to query <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>only</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> the internal
|
|
|
|
|
name servers for DNS queries. This could also be enforced via selective
|
|
|
|
|
filtering on the network.</P
|
|
|
|
|
><P
|
|
|
|
|
>If everything has been set properly, <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>Example, Inc.</I
|
|
|
|
|
></SPAN
|
|
|
|
|
>'s
|
|
|
|
|
internal clients will now be able to:</P
|
|
|
|
|
><P
|
|
|
|
|
></P
|
|
|
|
|
><UL
|
|
|
|
|
><LI
|
|
|
|
|
><P
|
|
|
|
|
>Look up any hostnames in the <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>site1</VAR
|
|
|
|
|
> and
|
|
|
|
|
<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>site2.example.com</VAR
|
|
|
|
|
> zones.</P
|
|
|
|
|
></LI
|
|
|
|
|
><LI
|
|
|
|
|
><P
|
|
|
|
|
>Look up any hostnames in the <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>site1.internal</VAR
|
|
|
|
|
> and
|
|
|
|
|
<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>site2.internal</VAR
|
|
|
|
|
> domains.</P
|
|
|
|
|
></LI
|
|
|
|
|
><LI
|
|
|
|
|
><P
|
|
|
|
|
>Look up any hostnames on the Internet.</P
|
|
|
|
|
></LI
|
|
|
|
|
><LI
|
|
|
|
|
><P
|
|
|
|
|
>Exchange mail with internal AND external people.</P
|
|
|
|
|
></LI
|
|
|
|
|
></UL
|
|
|
|
|
><P
|
|
|
|
|
>Hosts on the Internet will be able to:</P
|
|
|
|
|
><P
|
|
|
|
|
></P
|
|
|
|
|
><UL
|
|
|
|
|
><LI
|
|
|
|
|
><P
|
|
|
|
|
>Look up any hostnames in the <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>site1</VAR
|
|
|
|
|
> and
|
|
|
|
|
<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>site2.example.com</VAR
|
|
|
|
|
> zones.</P
|
|
|
|
|
></LI
|
|
|
|
|
><LI
|
|
|
|
|
><P
|
|
|
|
|
>Exchange mail with anyone in the <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>site1</VAR
|
|
|
|
|
> and
|
|
|
|
|
<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>site2.example.com</VAR
|
|
|
|
|
> zones.</P
|
|
|
|
|
></LI
|
|
|
|
|
></UL
|
|
|
|
|
><P
|
|
|
|
|
>Here is an example configuration for the setup we just
|
|
|
|
|
described above. Note that this is only configuration information;
|
|
|
|
|
for information on how to configure your zone files, see <A
|
|
|
|
|
HREF="Bv9ARM.ch03.html#sample_configuration"
|
|
|
|
|
>Section 3.1</A
|
|
|
|
|
></P
|
|
|
|
|
><P
|
|
|
|
|
>Internal DNS server config:</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
>
|
|
|
|
|
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
|
|
|
|
|
|
|
|
|
|
acl externals { <VAR
|
|
|
|
|
CLASS="varname"
|
|
|
|
|
>bastion-ips-go-here</VAR
|
|
|
|
|
>; };
|
|
|
|
|
|
|
|
|
|
options {
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
forward only;
|
|
|
|
|
forwarders { // forward to external servers
|
|
|
|
|
<VAR
|
|
|
|
|
CLASS="varname"
|
|
|
|
|
>bastion-ips-go-here</VAR
|
|
|
|
|
>;
|
|
|
|
|
};
|
|
|
|
|
allow-transfer { none; }; // sample allow-transfer (no one)
|
|
|
|
|
allow-query { internals; externals; }; // restrict query access
|
|
|
|
|
allow-recursion { internals; }; // restrict recursion
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
zone "site1.example.com" { // sample master zone
|
|
|
|
|
type master;
|
|
|
|
|
file "m/site1.example.com";
|
|
|
|
|
forwarders { }; // do normal iterative
|
|
|
|
|
// resolution (do not forward)
|
|
|
|
|
allow-query { internals; externals; };
|
|
|
|
|
allow-transfer { internals; };
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
zone "site2.example.com" { // sample slave zone
|
|
|
|
|
type slave;
|
|
|
|
|
file "s/site2.example.com";
|
|
|
|
|
masters { 172.16.72.3; };
|
|
|
|
|
forwarders { };
|
|
|
|
|
allow-query { internals; externals; };
|
|
|
|
|
allow-transfer { internals; };
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
zone "site1.internal" {
|
|
|
|
|
type master;
|
|
|
|
|
file "m/site1.internal";
|
|
|
|
|
forwarders { };
|
|
|
|
|
allow-query { internals; };
|
|
|
|
|
allow-transfer { internals; }
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
zone "site2.internal" {
|
|
|
|
|
type slave;
|
|
|
|
|
file "s/site2.internal";
|
|
|
|
|
masters { 172.16.72.3; };
|
|
|
|
|
forwarders { };
|
|
|
|
|
allow-query { internals };
|
|
|
|
|
allow-transfer { internals; }
|
|
|
|
|
};
|
|
|
|
|
</PRE
|
|
|
|
|
><P
|
|
|
|
|
>External (bastion host) DNS server config:</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
> acl internals { 172.16.72.0/24; 192.168.1.0/24; };
|
|
|
|
|
|
|
|
|
|
acl externals { bastion-ips-go-here; };
|
|
|
|
|
|
|
|
|
|
options {
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
allow-transfer { none; }; // sample allow-transfer (no one)
|
|
|
|
|
allow-query { internals; externals; }; // restrict query access
|
|
|
|
|
allow-recursion { internals; externals; }; // restrict recursion
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
zone "site1.example.com" { // sample slave zone
|
|
|
|
|
type master;
|
|
|
|
|
file "m/site1.foo.com";
|
|
|
|
|
allow-query { any; };
|
|
|
|
|
allow-transfer { internals; externals; };
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
zone "site2.example.com" {
|
|
|
|
|
type slave;
|
|
|
|
|
file "s/site2.foo.com";
|
|
|
|
|
masters { another_bastion_host_maybe; };
|
|
|
|
|
allow-query { any; };
|
|
|
|
|
allow-transfer { internals; externals; }
|
|
|
|
|
};
|
|
|
|
|
</PRE
|
|
|
|
|
><P
|
|
|
|
|
>In the <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>resolv.conf</TT
|
|
|
|
|
> (or equivalent) on
|
|
|
|
|
the bastion host(s):</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
> search ...
|
|
|
|
|
nameserver 172.16.72.2
|
|
|
|
|
nameserver 172.16.72.3
|
|
|
|
|
nameserver 172.16.72.4
|
|
|
|
|
</PRE
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><H1
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><A
|
|
|
|
|
NAME="tsig"
|
|
|
|
|
>4.5. TSIG</A
|
|
|
|
|
></H1
|
|
|
|
|
><P
|
|
|
|
|
>This is a short guide to setting up Transaction SIGnatures
|
|
|
|
|
(TSIG) based transaction security in <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
>. It describes changes
|
|
|
|
|
to the configuration file as well as what changes are required for
|
|
|
|
|
different features, including the process of creating transaction
|
|
|
|
|
keys and using transaction signatures with <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
>.</P
|
|
|
|
|
><P
|
|
|
|
|
><ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> primarily supports TSIG for server to server communication.
|
|
|
|
|
This includes zone transfer, notify, and recursive query messages.
|
|
|
|
|
Resolvers based on newer versions of <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 8 have limited support
|
|
|
|
|
for TSIG.</P
|
|
|
|
|
><P
|
|
|
|
|
>TSIG might be most useful for dynamic update. A primary
|
|
|
|
|
server for a dynamic zone should use access control to control
|
|
|
|
|
updates, but IP-based access control is insufficient.
|
|
|
|
|
The cryptographic access control provided by TSIG
|
|
|
|
|
is far superior. The <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>nsupdate</B
|
|
|
|
|
>
|
|
|
|
|
program supports TSIG via the <VAR
|
|
|
|
|
CLASS="option"
|
|
|
|
|
>-k</VAR
|
|
|
|
|
> and
|
|
|
|
|
<VAR
|
|
|
|
|
CLASS="option"
|
|
|
|
|
>-y</VAR
|
|
|
|
|
> command line options.</P
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN858"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.5.1. Generate Shared Keys for Each Pair of Hosts</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>A shared secret is generated to be shared between <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host1</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> and <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host2</I
|
|
|
|
|
></SPAN
|
|
|
|
|
>.
|
|
|
|
|
An arbitrary key name is chosen: "host1-host2.". The key name must
|
|
|
|
|
be the same on both hosts.</P
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect3"
|
|
|
|
|
><H3
|
|
|
|
|
CLASS="sect3"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN863"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.5.1.1. Automatic Generation</A
|
|
|
|
|
></H3
|
|
|
|
|
><P
|
|
|
|
|
>The following command will generate a 128 bit (16 byte) HMAC-MD5
|
|
|
|
|
key as described above. Longer keys are better, but shorter keys
|
|
|
|
|
are easier to read. Note that the maximum key length is 512 bits;
|
|
|
|
|
keys longer than that will be digested with MD5 to produce a 128
|
|
|
|
|
bit key.</P
|
|
|
|
|
><P
|
|
|
|
|
><KBD
|
|
|
|
|
CLASS="userinput"
|
|
|
|
|
>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</KBD
|
|
|
|
|
></P
|
|
|
|
|
><P
|
|
|
|
|
>The key is in the file <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>Khost1-host2.+157+00000.private</TT
|
|
|
|
|
>.
|
|
|
|
|
Nothing directly uses this file, but the base-64 encoded string
|
|
|
|
|
following "<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>Key:</VAR
|
|
|
|
|
>"
|
|
|
|
|
can be extracted from the file and used as a shared secret:</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
>Key: La/E5CjG9O+os1jq0a2jdA==</PRE
|
|
|
|
|
><P
|
|
|
|
|
>The string "<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>La/E5CjG9O+os1jq0a2jdA==</VAR
|
|
|
|
|
>" can
|
|
|
|
|
be used as the shared secret.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect3"
|
|
|
|
|
><H3
|
|
|
|
|
CLASS="sect3"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN874"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.5.1.2. Manual Generation</A
|
|
|
|
|
></H3
|
|
|
|
|
><P
|
|
|
|
|
>The shared secret is simply a random sequence of bits, encoded
|
|
|
|
|
in base-64. Most ASCII strings are valid base-64 strings (assuming
|
|
|
|
|
the length is a multiple of 4 and only valid characters are used),
|
|
|
|
|
so the shared secret can be manually generated.</P
|
|
|
|
|
><P
|
|
|
|
|
>Also, a known string can be run through <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>mmencode</B
|
|
|
|
|
> or
|
|
|
|
|
a similar program to generate base-64 encoded data.</P
|
|
|
|
|
></DIV
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN879"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.5.2. Copying the Shared Secret to Both Machines</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>This is beyond the scope of DNS. A secure transport mechanism
|
|
|
|
|
should be used. This could be secure FTP, ssh, telephone, etc.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN882"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.5.3. Informing the Servers of the Key's Existence</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>Imagine <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host1</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> and <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host 2</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> are
|
|
|
|
|
both servers. The following is added to each server's <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>named.conf</TT
|
|
|
|
|
> file:</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
> key host1-host2. {
|
|
|
|
|
algorithm hmac-md5;
|
|
|
|
|
secret "La/E5CjG9O+os1jq0a2jdA==";
|
|
|
|
|
};
|
|
|
|
|
</PRE
|
|
|
|
|
><P
|
|
|
|
|
>The algorithm, hmac-md5, is the only one supported by <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
>.
|
|
|
|
|
The secret is the one generated above. Since this is a secret, it
|
|
|
|
|
is recommended that either <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>named.conf</TT
|
|
|
|
|
> be non-world
|
|
|
|
|
readable, or the key directive be added to a non-world readable
|
|
|
|
|
file that is included by <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>named.conf</TT
|
|
|
|
|
>.</P
|
|
|
|
|
><P
|
|
|
|
|
>At this point, the key is recognized. This means that if the
|
|
|
|
|
server receives a message signed by this key, it can verify the
|
|
|
|
|
signature. If the signature is successfully verified, the
|
|
|
|
|
response is signed by the same key.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN894"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.5.4. Instructing the Server to Use the Key</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>Since keys are shared between two hosts only, the server must
|
|
|
|
|
be told when keys are to be used. The following is added to the <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>named.conf</TT
|
|
|
|
|
> file
|
|
|
|
|
for <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host1</I
|
|
|
|
|
></SPAN
|
|
|
|
|
>, if the IP address of <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host2</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> is
|
|
|
|
|
10.1.2.3:</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
> server 10.1.2.3 {
|
|
|
|
|
keys { host1-host2. ;};
|
|
|
|
|
};
|
|
|
|
|
</PRE
|
|
|
|
|
><P
|
|
|
|
|
>Multiple keys may be present, but only the first is used.
|
|
|
|
|
This directive does not contain any secrets, so it may be in a world-readable
|
|
|
|
|
file.</P
|
|
|
|
|
><P
|
|
|
|
|
>If <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host1</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> sends a message that is a request
|
|
|
|
|
to that address, the message will be signed with the specified key. <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host1</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> will
|
|
|
|
|
expect any responses to signed messages to be signed with the same
|
|
|
|
|
key.</P
|
|
|
|
|
><P
|
|
|
|
|
>A similar statement must be present in <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host2</I
|
|
|
|
|
></SPAN
|
|
|
|
|
>'s
|
|
|
|
|
configuration file (with <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host1</I
|
|
|
|
|
></SPAN
|
|
|
|
|
>'s address) for <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host2</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> to
|
|
|
|
|
sign request messages to <SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>host1</I
|
|
|
|
|
></SPAN
|
|
|
|
|
>.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN910"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.5.5. TSIG Key Based Access Control</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
><ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> allows IP addresses and ranges to be specified in ACL
|
|
|
|
|
definitions and
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>allow-{ query | transfer | update }</B
|
|
|
|
|
> directives.
|
|
|
|
|
This has been extended to allow TSIG keys also. The above key would
|
|
|
|
|
be denoted <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>key host1-host2.</B
|
|
|
|
|
></P
|
|
|
|
|
><P
|
|
|
|
|
>An example of an allow-update directive would be:</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
> allow-update { key host1-host2. ;};
|
|
|
|
|
</PRE
|
|
|
|
|
><P
|
|
|
|
|
>This allows dynamic updates to succeed only if the request
|
|
|
|
|
was signed by a key named
|
|
|
|
|
"<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>host1-host2.</B
|
|
|
|
|
>".</P
|
|
|
|
|
><P
|
|
|
|
|
>You may want to read about the more
|
|
|
|
|
powerful <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>update-policy</B
|
|
|
|
|
> statement in <A
|
|
|
|
|
HREF="Bv9ARM.ch06.html#dynamic_update_policies"
|
|
|
|
|
>Section 6.2.24.4</A
|
|
|
|
|
>.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN923"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.5.6. Errors</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>The processing of TSIG signed messages can result in
|
|
|
|
|
several errors. If a signed message is sent to a non-TSIG aware
|
|
|
|
|
server, a FORMERR will be returned, since the server will not
|
|
|
|
|
understand the record. This is a result of misconfiguration,
|
|
|
|
|
since the server must be explicitly configured to send a TSIG
|
|
|
|
|
signed message to a specific server.</P
|
|
|
|
|
><P
|
|
|
|
|
>If a TSIG aware server receives a message signed by an
|
|
|
|
|
unknown key, the response will be unsigned with the TSIG
|
|
|
|
|
extended error code set to BADKEY. If a TSIG aware server
|
|
|
|
|
receives a message with a signature that does not validate, the
|
|
|
|
|
response will be unsigned with the TSIG extended error code set
|
|
|
|
|
to BADSIG. If a TSIG aware server receives a message with a time
|
|
|
|
|
outside of the allowed range, the response will be signed with
|
|
|
|
|
the TSIG extended error code set to BADTIME, and the time values
|
|
|
|
|
will be adjusted so that the response can be successfully
|
|
|
|
|
verified. In any of these cases, the message's rcode is set to
|
|
|
|
|
NOTAUTH.</P
|
|
|
|
|
></DIV
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><H1
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN927"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.6. TKEY</A
|
|
|
|
|
></H1
|
|
|
|
|
><P
|
|
|
|
|
><B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> is a mechanism for automatically
|
|
|
|
|
generating a shared secret between two hosts. There are several
|
|
|
|
|
"modes" of <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> that specify how the key is
|
|
|
|
|
generated or assigned. <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9
|
|
|
|
|
implements only one of these modes,
|
|
|
|
|
the Diffie-Hellman key exchange. Both hosts are required to have
|
|
|
|
|
a Diffie-Hellman KEY record (although this record is not required
|
|
|
|
|
to be present in a zone). The <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> process
|
|
|
|
|
must use signed messages, signed either by TSIG or SIG(0). The
|
|
|
|
|
result of <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> is a shared secret that can be
|
|
|
|
|
used to sign messages with TSIG. <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> can also
|
|
|
|
|
be used to delete shared secrets that it had previously
|
|
|
|
|
generated.</P
|
|
|
|
|
><P
|
|
|
|
|
>The <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> process is initiated by a client
|
|
|
|
|
or server by sending a signed <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> query
|
|
|
|
|
(including any appropriate KEYs) to a TKEY-aware server. The
|
|
|
|
|
server response, if it indicates success, will contain a
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> record and any appropriate keys. After
|
|
|
|
|
this exchange, both participants have enough information to
|
|
|
|
|
determine the shared secret; the exact process depends on the
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> mode. When using the Diffie-Hellman
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>TKEY</B
|
|
|
|
|
> mode, Diffie-Hellman keys are exchanged,
|
|
|
|
|
and the shared secret is derived by both participants.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><H1
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN942"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.7. SIG(0)</A
|
|
|
|
|
></H1
|
|
|
|
|
><P
|
|
|
|
|
><ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 partially supports DNSSEC SIG(0)
|
|
|
|
|
transaction signatures as specified in RFC 2535 and RFC2931. SIG(0)
|
|
|
|
|
uses public/private keys to authenticate messages. Access control
|
|
|
|
|
is performed in the same manner as TSIG keys; privileges can be
|
|
|
|
|
granted or denied based on the key name.</P
|
|
|
|
|
><P
|
|
|
|
|
>When a SIG(0) signed message is received, it will only be
|
|
|
|
|
verified if the key is known and trusted by the server; the server
|
|
|
|
|
will not attempt to locate and/or validate the key.</P
|
|
|
|
|
><P
|
|
|
|
|
>SIG(0) signing of multiple-message TCP streams is not
|
|
|
|
|
supported.</P
|
|
|
|
|
><P
|
|
|
|
|
>The only tool shipped with <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 that
|
|
|
|
|
generates SIG(0) signed messages is <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>nsupdate</B
|
|
|
|
|
>.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><H1
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><A
|
|
|
|
|
NAME="DNSSEC"
|
|
|
|
|
>4.8. DNSSEC</A
|
|
|
|
|
></H1
|
|
|
|
|
><P
|
|
|
|
|
>Cryptographic authentication of DNS information is possible
|
|
|
|
|
through the DNS Security (<SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>DNSSEC-bis</I
|
|
|
|
|
></SPAN
|
|
|
|
|
>) extensions,
|
|
|
|
|
defined in RFC <TBA>. This section describes the creation and use
|
|
|
|
|
of DNSSEC signed zones.</P
|
|
|
|
|
><P
|
|
|
|
|
>In order to set up a DNSSEC secure zone, there are a series
|
|
|
|
|
of steps which must be followed. <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 ships
|
|
|
|
|
with several tools
|
|
|
|
|
that are used in this process, which are explained in more detail
|
|
|
|
|
below. In all cases, the <VAR
|
|
|
|
|
CLASS="option"
|
|
|
|
|
>-h</VAR
|
|
|
|
|
> option prints a
|
|
|
|
|
full list of parameters. Note that the DNSSEC tools require the
|
|
|
|
|
keyset files to be in the working directory or the
|
|
|
|
|
directory specified by the <VAR
|
|
|
|
|
CLASS="option"
|
|
|
|
|
>-h</VAR
|
|
|
|
|
> option, and
|
|
|
|
|
that the tools shipped with BIND 9.2.x and earlier are not compatible
|
|
|
|
|
with the current ones.</P
|
|
|
|
|
><P
|
|
|
|
|
>There must also be communication with the administrators of
|
|
|
|
|
the parent and/or child zone to transmit keys. A zone's security
|
|
|
|
|
status must be indicated by the parent zone for a DNSSEC capable
|
|
|
|
|
resolver to trust its data. This is done through the presense
|
|
|
|
|
or absence of a <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>DS</VAR
|
|
|
|
|
> record at the delegation
|
|
|
|
|
point.</P
|
|
|
|
|
><P
|
|
|
|
|
>For other servers to trust data in this zone, they must
|
|
|
|
|
either be statically configured with this zone's zone key or the
|
|
|
|
|
zone key of another zone above this one in the DNS tree.</P
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN962"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.8.1. Generating Keys</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>The <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>dnssec-keygen</B
|
|
|
|
|
> program is used to
|
|
|
|
|
generate keys.</P
|
|
|
|
|
><P
|
|
|
|
|
>A secure zone must contain one or more zone keys. The
|
|
|
|
|
zone keys will sign all other records in the zone, as well as
|
|
|
|
|
the zone keys of any secure delegated zones. Zone keys must
|
|
|
|
|
have the same name as the zone, a name type of
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>ZONE</B
|
|
|
|
|
>, and must be usable for authentication.
|
|
|
|
|
It is recommended that zone keys use a cryptographic algorithm
|
|
|
|
|
designated as "mandatory to implement" by the IETF; currently
|
|
|
|
|
the only one is RSASHA1.</P
|
|
|
|
|
><P
|
|
|
|
|
>The following command will generate a 768 bit RSASHA1 key for
|
|
|
|
|
the <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>child.example</TT
|
|
|
|
|
> zone:</P
|
|
|
|
|
><P
|
|
|
|
|
><KBD
|
|
|
|
|
CLASS="userinput"
|
|
|
|
|
>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</KBD
|
|
|
|
|
></P
|
|
|
|
|
><P
|
|
|
|
|
>Two output files will be produced:
|
|
|
|
|
<TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>Kchild.example.+005+12345.key</TT
|
|
|
|
|
> and
|
|
|
|
|
<TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>Kchild.example.+005+12345.private</TT
|
|
|
|
|
> (where
|
|
|
|
|
12345 is an example of a key tag). The key file names contain
|
|
|
|
|
the key name (<TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>child.example.</TT
|
|
|
|
|
>), algorithm (3
|
|
|
|
|
is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in this case).
|
|
|
|
|
The private key (in the <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>.private</TT
|
|
|
|
|
> file) is
|
|
|
|
|
used to generate signatures, and the public key (in the
|
|
|
|
|
<TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>.key</TT
|
|
|
|
|
> file) is used for signature
|
|
|
|
|
verification.</P
|
|
|
|
|
><P
|
|
|
|
|
>To generate another key with the same properties (but with
|
|
|
|
|
a different key tag), repeat the above command.</P
|
|
|
|
|
><P
|
|
|
|
|
>The public keys should be inserted into the zone file by
|
|
|
|
|
including the <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>.key</TT
|
|
|
|
|
> files using
|
|
|
|
|
<B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>$INCLUDE</B
|
|
|
|
|
> statements.
|
|
|
|
|
</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN982"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.8.2. Signing the Zone</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>The <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>dnssec-signzone</B
|
|
|
|
|
> program is used to
|
|
|
|
|
sign a zone.</P
|
|
|
|
|
><P
|
|
|
|
|
>Any <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>keyset</TT
|
|
|
|
|
> files corresponding
|
|
|
|
|
to secure subzones should be present. The zone signer will
|
|
|
|
|
generate <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>NSEC</VAR
|
|
|
|
|
> and <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>RRSIG</VAR
|
|
|
|
|
>
|
|
|
|
|
records for the zone, as well as <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>DS</VAR
|
|
|
|
|
> for
|
|
|
|
|
the child zones if <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>'-d'</VAR
|
|
|
|
|
> is specified.
|
|
|
|
|
If <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>'-d'</VAR
|
|
|
|
|
> is not specified then DS RRsets for
|
|
|
|
|
the secure child zones need to be added manually.</P
|
|
|
|
|
><P
|
|
|
|
|
>The following command signs the zone, assuming it is in a
|
|
|
|
|
file called <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>zone.child.example</TT
|
|
|
|
|
>. By
|
|
|
|
|
default, all zone keys which have an available private key are
|
|
|
|
|
used to generate signatures.</P
|
|
|
|
|
><P
|
|
|
|
|
><KBD
|
|
|
|
|
CLASS="userinput"
|
|
|
|
|
>dnssec-signzone -o child.example zone.child.example</KBD
|
|
|
|
|
></P
|
|
|
|
|
><P
|
|
|
|
|
>One output file is produced:
|
|
|
|
|
<TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>zone.child.example.signed</TT
|
|
|
|
|
>. This file
|
|
|
|
|
should be referenced by <TT
|
|
|
|
|
CLASS="filename"
|
|
|
|
|
>named.conf</TT
|
|
|
|
|
> as the
|
|
|
|
|
input file for the zone.</P
|
|
|
|
|
><P
|
|
|
|
|
><B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>dnssec-signzone</B
|
|
|
|
|
> will also produce a
|
|
|
|
|
keyset and dsset files and optionally a dlvset file. These
|
|
|
|
|
are used to provide the parent zone administators with the
|
|
|
|
|
<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>DNSKEYs</VAR
|
|
|
|
|
> (or their corresponding <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>DS</VAR
|
|
|
|
|
>
|
|
|
|
|
records) that are the secure entry point to the zone.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN1004"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.8.3. Configuring Servers</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>Unlike <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 8,
|
|
|
|
|
<ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 does not verify signatures on load,
|
|
|
|
|
so zone keys for authoritative zones do not need to be specified
|
|
|
|
|
in the configuration file.</P
|
|
|
|
|
><P
|
|
|
|
|
>The public key for any security root must be present in
|
|
|
|
|
the configuration file's <B
|
|
|
|
|
CLASS="command"
|
|
|
|
|
>trusted-keys</B
|
|
|
|
|
>
|
|
|
|
|
statement, as described later in this document. </P
|
|
|
|
|
></DIV
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><H1
|
|
|
|
|
CLASS="sect1"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN1011"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.9. IPv6 Support in <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9</A
|
|
|
|
|
></H1
|
|
|
|
|
><P
|
|
|
|
|
><ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 fully supports all currently defined forms of IPv6
|
|
|
|
|
name to address and address to name lookups. It will also use
|
|
|
|
|
IPv6 addresses to make queries when running on an IPv6 capable
|
|
|
|
|
system.</P
|
|
|
|
|
><P
|
|
|
|
|
>For forward lookups, <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 supports only AAAA
|
|
|
|
|
records. The use of A6 records is deprecated by RFC 3363, and the
|
|
|
|
|
support for forward lookups in <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 is
|
|
|
|
|
removed accordingly.
|
|
|
|
|
However, authoritative <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 name servers still
|
|
|
|
|
load zone files containing A6 records correctly, answer queries
|
|
|
|
|
for A6 records, and accept zone transfer for a zone containing A6
|
|
|
|
|
records.</P
|
|
|
|
|
><P
|
|
|
|
|
>For IPv6 reverse lookups, <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 supports
|
|
|
|
|
the traditional "nibble" format used in the
|
|
|
|
|
<SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>ip6.arpa</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> domain, as well as the older, deprecated
|
|
|
|
|
<SPAN
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
><I
|
|
|
|
|
CLASS="emphasis"
|
|
|
|
|
>ip6.int</I
|
|
|
|
|
></SPAN
|
|
|
|
|
> domain.
|
|
|
|
|
<ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 formerly
|
|
|
|
|
supported the "binary label" (also known as "bitstring") format.
|
|
|
|
|
The support of binary labels, however, is now completely removed
|
|
|
|
|
according to the changes in RFC 3363.
|
|
|
|
|
Any applications in <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 do not understand
|
|
|
|
|
the format any more, and will return an error if given.
|
|
|
|
|
In particular, an authoritative <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 name
|
|
|
|
|
server rejects to load a zone file containing binary labels.</P
|
|
|
|
|
><P
|
|
|
|
|
>For an overview of the format and structure of IPv6 addresses,
|
|
|
|
|
see <A
|
|
|
|
|
HREF="Bv9ARM.ch09.html#ipv6addresses"
|
|
|
|
|
>Section A.2.1</A
|
|
|
|
|
>.</P
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN1029"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.9.1. Address Lookups Using AAAA Records</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>The AAAA record is a parallel to the IPv4 A record. It
|
|
|
|
|
specifies the entire address in a single record. For
|
|
|
|
|
example,</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
> $ORIGIN example.com.
|
|
|
|
|
host 3600 IN AAAA 2001:db8::1
|
|
|
|
|
</PRE
|
|
|
|
|
><P
|
|
|
|
|
>It is recommended that IPv4-in-IPv6 mapped addresses not
|
|
|
|
|
be used. If a host has an IPv4 address, use an A record, not
|
|
|
|
|
a AAAA, with <VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>::ffff:192.168.42.1</VAR
|
|
|
|
|
> as the
|
|
|
|
|
address.</P
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><H2
|
|
|
|
|
CLASS="sect2"
|
|
|
|
|
><A
|
2005-03-17 08:04:02 +00:00
|
|
|
NAME="AEN1035"
|
2004-09-19 01:30:24 +00:00
|
|
|
>4.9.2. Address to Name Lookups Using Nibble Format</A
|
|
|
|
|
></H2
|
|
|
|
|
><P
|
|
|
|
|
>When looking up an address in nibble format, the address
|
|
|
|
|
components are simply reversed, just as in IPv4, and
|
|
|
|
|
<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>ip6.arpa.</VAR
|
|
|
|
|
> is appended to the resulting name.
|
|
|
|
|
For example, the following would provide reverse name lookup for
|
|
|
|
|
a host with address
|
|
|
|
|
<VAR
|
|
|
|
|
CLASS="literal"
|
|
|
|
|
>2001:db8::1</VAR
|
|
|
|
|
>.</P
|
|
|
|
|
><PRE
|
|
|
|
|
CLASS="programlisting"
|
|
|
|
|
> $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
|
|
|
|
|
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR host.example.com.
|
|
|
|
|
</PRE
|
|
|
|
|
></DIV
|
|
|
|
|
></DIV
|
|
|
|
|
></DIV
|
|
|
|
|
><DIV
|
|
|
|
|
CLASS="NAVFOOTER"
|
|
|
|
|
><HR
|
|
|
|
|
ALIGN="LEFT"
|
|
|
|
|
WIDTH="100%"><TABLE
|
|
|
|
|
SUMMARY="Footer navigation table"
|
|
|
|
|
WIDTH="100%"
|
|
|
|
|
BORDER="0"
|
|
|
|
|
CELLPADDING="0"
|
|
|
|
|
CELLSPACING="0"
|
|
|
|
|
><TR
|
|
|
|
|
><TD
|
|
|
|
|
WIDTH="33%"
|
|
|
|
|
ALIGN="left"
|
|
|
|
|
VALIGN="top"
|
|
|
|
|
><A
|
|
|
|
|
HREF="Bv9ARM.ch03.html"
|
|
|
|
|
ACCESSKEY="P"
|
|
|
|
|
>Prev</A
|
|
|
|
|
></TD
|
|
|
|
|
><TD
|
|
|
|
|
WIDTH="34%"
|
|
|
|
|
ALIGN="center"
|
|
|
|
|
VALIGN="top"
|
|
|
|
|
><A
|
|
|
|
|
HREF="Bv9ARM.html"
|
|
|
|
|
ACCESSKEY="H"
|
|
|
|
|
>Home</A
|
|
|
|
|
></TD
|
|
|
|
|
><TD
|
|
|
|
|
WIDTH="33%"
|
|
|
|
|
ALIGN="right"
|
|
|
|
|
VALIGN="top"
|
|
|
|
|
><A
|
|
|
|
|
HREF="Bv9ARM.ch05.html"
|
|
|
|
|
ACCESSKEY="N"
|
|
|
|
|
>Next</A
|
|
|
|
|
></TD
|
|
|
|
|
></TR
|
|
|
|
|
><TR
|
|
|
|
|
><TD
|
|
|
|
|
WIDTH="33%"
|
|
|
|
|
ALIGN="left"
|
|
|
|
|
VALIGN="top"
|
|
|
|
|
>Name Server Configuration</TD
|
|
|
|
|
><TD
|
|
|
|
|
WIDTH="34%"
|
|
|
|
|
ALIGN="center"
|
|
|
|
|
VALIGN="top"
|
|
|
|
|
> </TD
|
|
|
|
|
><TD
|
|
|
|
|
WIDTH="33%"
|
|
|
|
|
ALIGN="right"
|
|
|
|
|
VALIGN="top"
|
|
|
|
|
>The <ACRONYM
|
|
|
|
|
CLASS="acronym"
|
|
|
|
|
>BIND</ACRONYM
|
|
|
|
|
> 9 Lightweight Resolver</TD
|
|
|
|
|
></TR
|
|
|
|
|
></TABLE
|
|
|
|
|
></DIV
|
|
|
|
|
></BODY
|
|
|
|
|
></HTML
|
|
|
|
|
>
|
