mirror of
https://gitlab.isc.org/isc-projects/bind9
synced 2025-08-27 20:49:04 +00:00
1810 lines
41 KiB
HTML
1810 lines
41 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Advanced DNS Features</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.61
|
|
"><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
|
|
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"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="Bv9ARM.ch05.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="chapter"
|
|
><H1
|
|
><A
|
|
NAME="ch04"
|
|
>Chapter 4. Advanced DNS Features</A
|
|
></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
|
|
HREF="Bv9ARM.ch04.html#AEN734"
|
|
>Split DNS</A
|
|
></DT
|
|
><DT
|
|
>4.5. <A
|
|
HREF="Bv9ARM.ch04.html#tsig"
|
|
>TSIG</A
|
|
></DT
|
|
><DT
|
|
>4.6. <A
|
|
HREF="Bv9ARM.ch04.html#AEN894"
|
|
>TKEY</A
|
|
></DT
|
|
><DT
|
|
>4.7. <A
|
|
HREF="Bv9ARM.ch04.html#AEN909"
|
|
>SIG(0)</A
|
|
></DT
|
|
><DT
|
|
>4.8. <A
|
|
HREF="Bv9ARM.ch04.html#DNSSEC"
|
|
>DNSSEC</A
|
|
></DT
|
|
><DT
|
|
>4.9. <A
|
|
HREF="Bv9ARM.ch04.html#AEN994"
|
|
>IPv6 Support in <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9</A
|
|
></DT
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="notify"
|
|
>4.1. Notify</A
|
|
></H1
|
|
><P
|
|
><SPAN
|
|
CLASS="acronym"
|
|
>DNS</SPAN
|
|
> 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
|
|
><SPAN
|
|
CLASS="acronym"
|
|
>DNS</SPAN
|
|
>
|
|
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.14.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.14.6</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: SIG and NXT 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: Shut down
|
|
the server using <B
|
|
CLASS="command"
|
|
>rndc stop</B
|
|
> (sending a signal
|
|
or using <B
|
|
CLASS="command"
|
|
>rndc halt</B
|
|
> is <I
|
|
CLASS="emphasis"
|
|
>not</I
|
|
>
|
|
sufficient). Wait for the server to exit,
|
|
then <I
|
|
CLASS="emphasis"
|
|
>remove</I
|
|
> the zone's
|
|
<TT
|
|
CLASS="filename"
|
|
>.jnl</TT
|
|
> file, edit the zone file,
|
|
and restart the server. Removing the <TT
|
|
CLASS="filename"
|
|
>.jnl</TT
|
|
>
|
|
file is necessary because the manual edits will not be
|
|
present in the journal, rendering it inconsistent with the
|
|
contents of the zone file.</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, <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 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 <TT
|
|
CLASS="userinput"
|
|
><B
|
|
>yes</B
|
|
></TT
|
|
>.
|
|
</P
|
|
><P
|
|
>When acting as a slave, <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 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
|
|
NAME="AEN734"
|
|
>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 <I
|
|
CLASS="emphasis"
|
|
>Split
|
|
DNS</I
|
|
> 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 <I
|
|
CLASS="emphasis"
|
|
>Example, Inc.</I
|
|
>
|
|
(<TT
|
|
CLASS="literal"
|
|
>example.com</TT
|
|
>)
|
|
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
|
|
><I
|
|
CLASS="emphasis"
|
|
>Example, Inc.</I
|
|
> 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
|
|
>,<I
|
|
CLASS="emphasis"
|
|
> </I
|
|
><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"
|
|
><TT
|
|
CLASS="literal"
|
|
>* IN MX 10 external1.example.com.</TT
|
|
></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 <I
|
|
CLASS="emphasis"
|
|
>only</I
|
|
> 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, <I
|
|
CLASS="emphasis"
|
|
>Example, Inc.</I
|
|
>'s
|
|
internal clients will now be able to:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Look up any hostnames in the <TT
|
|
CLASS="literal"
|
|
>site1</TT
|
|
> and
|
|
<TT
|
|
CLASS="literal"
|
|
>site2.example.com</TT
|
|
> zones.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Look up any hostnames in the <TT
|
|
CLASS="literal"
|
|
>site1.internal</TT
|
|
> and
|
|
<TT
|
|
CLASS="literal"
|
|
>site2.internal</TT
|
|
> 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 <TT
|
|
CLASS="literal"
|
|
>site1</TT
|
|
> and
|
|
<TT
|
|
CLASS="literal"
|
|
>site2.example.com</TT
|
|
> zones.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Exchange mail with anyone in the <TT
|
|
CLASS="literal"
|
|
>site1</TT
|
|
> and
|
|
<TT
|
|
CLASS="literal"
|
|
>site2.example.com</TT
|
|
> 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 { <TT
|
|
CLASS="varname"
|
|
>bastion-ips-go-here</TT
|
|
>; };
|
|
|
|
options {
|
|
...
|
|
...
|
|
forward only;
|
|
forwarders { // forward to external servers
|
|
<TT
|
|
CLASS="varname"
|
|
>bastion-ips-go-here</TT
|
|
>;
|
|
};
|
|
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 <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
>. 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 <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
>.</P
|
|
><P
|
|
><SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> primarily supports TSIG for server to server communication.
|
|
This includes zone transfer, notify, and recursive query messages.
|
|
Resolvers based on newer versions of <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 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 <TT
|
|
CLASS="option"
|
|
>-k</TT
|
|
> and
|
|
<TT
|
|
CLASS="option"
|
|
>-y</TT
|
|
> command line options.</P
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN825"
|
|
>4.5.1. Generate Shared Keys for Each Pair of Hosts</A
|
|
></H2
|
|
><P
|
|
>A shared secret is generated to be shared between <I
|
|
CLASS="emphasis"
|
|
>host1</I
|
|
> and <I
|
|
CLASS="emphasis"
|
|
>host2</I
|
|
>.
|
|
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
|
|
NAME="AEN830"
|
|
>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
|
|
><TT
|
|
CLASS="userinput"
|
|
><B
|
|
>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</B
|
|
></TT
|
|
></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 "<TT
|
|
CLASS="literal"
|
|
>Key:</TT
|
|
>"
|
|
can be extracted from the file and used as a shared secret:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>Key: La/E5CjG9O+os1jq0a2jdA==</PRE
|
|
><P
|
|
>The string "<TT
|
|
CLASS="literal"
|
|
>La/E5CjG9O+os1jq0a2jdA==</TT
|
|
>" can
|
|
be used as the shared secret.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect3"
|
|
><H3
|
|
CLASS="sect3"
|
|
><A
|
|
NAME="AEN841"
|
|
>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
|
|
NAME="AEN846"
|
|
>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
|
|
NAME="AEN849"
|
|
>4.5.3. Informing the Servers of the Key's Existence</A
|
|
></H2
|
|
><P
|
|
>Imagine <I
|
|
CLASS="emphasis"
|
|
>host1</I
|
|
> and <I
|
|
CLASS="emphasis"
|
|
>host 2</I
|
|
> 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 <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
>.
|
|
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
|
|
NAME="AEN861"
|
|
>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 <I
|
|
CLASS="emphasis"
|
|
>host1</I
|
|
>, if the IP address of <I
|
|
CLASS="emphasis"
|
|
>host2</I
|
|
> 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 <I
|
|
CLASS="emphasis"
|
|
>host1</I
|
|
> sends a message that is a request
|
|
to that address, the message will be signed with the specified key. <I
|
|
CLASS="emphasis"
|
|
>host1</I
|
|
> will
|
|
expect any responses to signed messages to be signed with the same
|
|
key.</P
|
|
><P
|
|
>A similar statement must be present in <I
|
|
CLASS="emphasis"
|
|
>host2</I
|
|
>'s
|
|
configuration file (with <I
|
|
CLASS="emphasis"
|
|
>host1</I
|
|
>'s address) for <I
|
|
CLASS="emphasis"
|
|
>host2</I
|
|
> to
|
|
sign request messages to <I
|
|
CLASS="emphasis"
|
|
>host1</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN877"
|
|
>4.5.5. TSIG Key Based Access Control</A
|
|
></H2
|
|
><P
|
|
><SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 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.22.4</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN890"
|
|
>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
|
|
NAME="AEN894"
|
|
>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. <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 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
|
|
NAME="AEN909"
|
|
>4.7. SIG(0)</A
|
|
></H1
|
|
><P
|
|
><SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9 partially supports DNSSEC SIG(0) transaction
|
|
signatures as specified in RFC 2535. 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
|
|
><SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9 does not ship with any tools that generate SIG(0)
|
|
signed messages.</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 (<I
|
|
CLASS="emphasis"
|
|
>DNSSEC</I
|
|
>) extensions,
|
|
defined in RFC 2535. 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. <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9 ships
|
|
with several tools
|
|
that are used in this process, which are explained in more detail
|
|
below. In all cases, the "<TT
|
|
CLASS="option"
|
|
>-h</TT
|
|
>" option prints a
|
|
full list of parameters. Note that the DNSSEC tools require the
|
|
keyset and signedkey files to be in the working directory, and
|
|
that the tools shipped with BIND 9.0.x are not fully 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 and signatures. A
|
|
zone's security status must be indicated by the parent zone for a
|
|
DNSSEC capable resolver to trust its data.</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
|
|
NAME="AEN926"
|
|
>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
|
|
these are RSASHA1 and DSA.</P
|
|
><P
|
|
>The following command will generate a 768 bit DSA key for
|
|
the <TT
|
|
CLASS="filename"
|
|
>child.example</TT
|
|
> zone:</P
|
|
><P
|
|
><TT
|
|
CLASS="userinput"
|
|
><B
|
|
>dnssec-keygen -a DSA -b 768 -n ZONE child.example.</B
|
|
></TT
|
|
></P
|
|
><P
|
|
>Two output files will be produced:
|
|
<TT
|
|
CLASS="filename"
|
|
>Kchild.example.+003+12345.key</TT
|
|
> and
|
|
<TT
|
|
CLASS="filename"
|
|
>Kchild.example.+003+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
|
|
NAME="AEN946"
|
|
>4.8.2. Creating a Keyset</A
|
|
></H2
|
|
><P
|
|
>The <B
|
|
CLASS="command"
|
|
>dnssec-makekeyset</B
|
|
> program is used
|
|
to create a key set from one or more keys.</P
|
|
><P
|
|
>Once the zone keys have been generated, a key set must be
|
|
built for transmission to the administrator of the parent zone,
|
|
so that the parent zone can sign the keys with its own zone key
|
|
and correctly indicate the security status of this zone. When
|
|
building a key set, the list of keys to be included and the TTL
|
|
of the set must be specified, and the desired signature validity
|
|
period of the parent's signature may also be specified.</P
|
|
><P
|
|
>The list of keys to be inserted into the key set may also
|
|
included non-zone keys present at the top of the zone.
|
|
<B
|
|
CLASS="command"
|
|
>dnssec-makekeyset</B
|
|
> may also be used at other
|
|
names in the zone.</P
|
|
><P
|
|
>The following command generates a key set containing the
|
|
above key and another key similarly generated, with a TTL of
|
|
3600 and a signature validity period of 10 days starting from
|
|
now.</P
|
|
><P
|
|
><TT
|
|
CLASS="userinput"
|
|
><B
|
|
>dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</B
|
|
></TT
|
|
></P
|
|
><P
|
|
>One output file is produced:
|
|
<TT
|
|
CLASS="filename"
|
|
>keyset-child.example.</TT
|
|
>. This file should be
|
|
transmitted to the parent to be signed. It includes the keys,
|
|
as well as signatures over the key set generated by the zone
|
|
keys themselves, which are used to prove ownership of the
|
|
private keys and encode the desired validity period.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN958"
|
|
>4.8.3. Signing the Child's Keyset</A
|
|
></H2
|
|
><P
|
|
>The <B
|
|
CLASS="command"
|
|
>dnssec-signkey</B
|
|
> program is used to
|
|
sign one child's keyset.</P
|
|
><P
|
|
>If the <TT
|
|
CLASS="filename"
|
|
>child.example</TT
|
|
> zone has any
|
|
delegations which are secure, for example,
|
|
<TT
|
|
CLASS="filename"
|
|
>grand.child.example</TT
|
|
>, the
|
|
<TT
|
|
CLASS="filename"
|
|
>child.example</TT
|
|
> administrator should receive
|
|
keyset files for each secure subzone. These keys must be signed
|
|
by this zone's zone keys.</P
|
|
><P
|
|
>The following command signs the child's key set with the
|
|
zone keys:</P
|
|
><P
|
|
><TT
|
|
CLASS="userinput"
|
|
><B
|
|
>dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</B
|
|
></TT
|
|
></P
|
|
><P
|
|
>One output file is produced:
|
|
<TT
|
|
CLASS="filename"
|
|
>signedkey-grand.child.example.</TT
|
|
>. This file
|
|
should be both transmitted back to the child and retained. It
|
|
includes all keys (the child's keys) from the keyset file and
|
|
signatures generated by this zone's zone keys.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN971"
|
|
>4.8.4. 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"
|
|
>signedkey</TT
|
|
> files corresponding to
|
|
secure subzones should be present, as well as a
|
|
<TT
|
|
CLASS="filename"
|
|
>signedkey</TT
|
|
> file for this zone generated by
|
|
the parent (if there is one). The zone signer will generate
|
|
<TT
|
|
CLASS="literal"
|
|
>NXT</TT
|
|
> and <TT
|
|
CLASS="literal"
|
|
>SIG</TT
|
|
> records for
|
|
the zone, as well as incorporate the zone key signature from the
|
|
parent and indicate the security status at all delegation
|
|
points.</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
|
|
><TT
|
|
CLASS="userinput"
|
|
><B
|
|
>dnssec-signzone -o child.example zone.child.example</B
|
|
></TT
|
|
></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
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN987"
|
|
>4.8.5. Configuring Servers</A
|
|
></H2
|
|
><P
|
|
>Unlike <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 8,
|
|
<SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 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
|
|
NAME="AEN994"
|
|
>4.9. IPv6 Support in <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9</A
|
|
></H1
|
|
><P
|
|
><SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 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, <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9 supports both A6 and AAAA
|
|
records. The use of AAAA records is deprecated, but it is still
|
|
useful for hosts to have both AAAA and A6 records to maintain
|
|
backward compatibility with installations where AAAA records are
|
|
still used. In fact, the stub resolvers currently shipped with
|
|
most operating system support only AAAA lookups, because following
|
|
A6 chains is much harder than doing A or AAAA lookups.</P
|
|
><P
|
|
>For IPv6 reverse lookups, <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9 supports the new
|
|
"binary label" (also known as "bitstring")
|
|
format used in the <I
|
|
CLASS="emphasis"
|
|
>ip6.arpa</I
|
|
>
|
|
domain, as well as the older, deprecated "nibble" format used in
|
|
the <I
|
|
CLASS="emphasis"
|
|
>ip6.int</I
|
|
> domain.</P
|
|
><P
|
|
><SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9 includes a new lightweight resolver library and
|
|
resolver daemon which new applications may choose to use to avoid
|
|
the complexities of A6 chain following and binary labels, see <A
|
|
HREF="Bv9ARM.ch05.html"
|
|
>Chapter 5</A
|
|
>. Alternatively, applications can link with a stub
|
|
resolver that supports A and AAAA records only and rely on the server to
|
|
synthesize AAAA recorsd from A6 chains (<A
|
|
HREF="Bv9ARM.ch06.html#synthesis"
|
|
>Section 6.2.14.13</A
|
|
>).
|
|
</P
|
|
><P
|
|
>For an overview of the format and structure of IPv6 addresses,
|
|
see <A
|
|
HREF="Bv9ARM.ch09.html#ipv6addresses"
|
|
>Section A.3.1</A
|
|
>.</P
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN1011"
|
|
>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 3ffe:8050:201:1860:42::1
|
|
</PRE
|
|
><P
|
|
>While their use is deprecated, they are useful to support
|
|
older IPv6 applications. They should not be added where they
|
|
are not absolutely necessary.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN1016"
|
|
>4.9.2. Address Lookups Using A6 Records</A
|
|
></H2
|
|
><P
|
|
>The A6 record is more flexible than the AAAA record, and
|
|
is therefore more complicated. The A6 record can be used to
|
|
form a chain of A6 records, each specifying part of the IPv6
|
|
address. It can also be used to specify the entire record as
|
|
well. For example, this record supplies the same data as the
|
|
AAAA record in the previous example:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN example.com.
|
|
host 3600 IN A6 0 3ffe:8050:201:1860:42::1
|
|
</PRE
|
|
><DIV
|
|
CLASS="sect3"
|
|
><H3
|
|
CLASS="sect3"
|
|
><A
|
|
NAME="AEN1020"
|
|
>4.9.2.1. A6 Chains</A
|
|
></H3
|
|
><P
|
|
>A6 records are designed to allow network
|
|
renumbering. This works when an A6 record only specifies the
|
|
part of the address space the domain owner controls. For
|
|
example, a host may be at a company named "company." It has
|
|
two ISPs which provide IPv6 address space for it. These two
|
|
ISPs fully specify the IPv6 prefix they supply.</P
|
|
><P
|
|
>In the company's address space:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN example.com.
|
|
host 3600 IN A6 64 0:0:0:0:42::1 company.example1.net.
|
|
host 3600 IN A6 64 0:0:0:0:42::1 company.example2.net.
|
|
</PRE
|
|
><P
|
|
>ISP1 will use:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN example1.net.
|
|
company 3600 IN A6 0 3ffe:8050:201:1860::
|
|
</PRE
|
|
><P
|
|
>ISP2 will use:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN example2.net.
|
|
company 3600 IN A6 0 1234:5678:90ab:fffa::
|
|
</PRE
|
|
><P
|
|
>When <TT
|
|
CLASS="literal"
|
|
>host.example.com</TT
|
|
> is looked up,
|
|
the resolver (in the resolver daemon or caching name server)
|
|
will find two partial A6 records, and will use the additional
|
|
name to find the remainder of the data.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect3"
|
|
><H3
|
|
CLASS="sect3"
|
|
><A
|
|
NAME="AEN1031"
|
|
>4.9.2.2. A6 Records for DNS Servers</A
|
|
></H3
|
|
><P
|
|
>When an A6 record specifies the address of a name
|
|
server, it should use the full address rather than specifying
|
|
a partial address. For example:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN example.com.
|
|
@ 14400 IN NS ns0
|
|
14400 IN NS ns1
|
|
ns0 14400 IN A6 0 3ffe:8050:201:1860:42::1
|
|
ns1 14400 IN A 192.168.42.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
|
|
an A6, with <TT
|
|
CLASS="literal"
|
|
>::ffff:192.168.42.1</TT
|
|
> as the
|
|
address.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN1037"
|
|
>4.9.3. Address to Name Lookups Using Nibble Format</A
|
|
></H2
|
|
><P
|
|
>While the use of nibble format to look up names is
|
|
deprecated, it is supported for backwards compatibility with
|
|
existing IPv6 applications.</P
|
|
><P
|
|
>When looking up an address in nibble format, the address
|
|
components are simply reversed, just as in IPv4, and
|
|
<TT
|
|
CLASS="literal"
|
|
>ip6.int.</TT
|
|
> is appended to the resulting name.
|
|
For example, the following would provide reverse name lookup for
|
|
a host with address
|
|
<TT
|
|
CLASS="literal"
|
|
>3ffe:8050:201:1860:42::1</TT
|
|
>.</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.int.
|
|
1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN PTR host.example.com.
|
|
</PRE
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN1044"
|
|
>4.9.4. Address to Name Lookups Using Binary Label Format</A
|
|
></H2
|
|
><P
|
|
>Binary labels can start and end on any bit boundary,
|
|
rather than on a multiple of 4 bits as in the nibble
|
|
format. They also use <I
|
|
CLASS="emphasis"
|
|
>ip6.arpa</I
|
|
> rather than
|
|
<I
|
|
CLASS="emphasis"
|
|
>ip6.int</I
|
|
>.</P
|
|
><P
|
|
>To replicate the previous example using binary labels:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN \[x3ffe805002011860/64].ip6.arpa.
|
|
\[x0042000000000001/64] 14400 IN PTR host.example.com.
|
|
</PRE
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN1051"
|
|
>4.9.5. Using DNAME for Delegation of IPv6 Reverse Addresses</A
|
|
></H2
|
|
><P
|
|
>In IPv6, the same host may have many addresses from many
|
|
network providers. Since the trailing portion of the address
|
|
usually remains constant, <B
|
|
CLASS="command"
|
|
>DNAME</B
|
|
> can help
|
|
reduce the number of zone files used for reverse mapping that
|
|
need to be maintained.</P
|
|
><P
|
|
>For example, consider a host which has two providers
|
|
(<TT
|
|
CLASS="literal"
|
|
>example.net</TT
|
|
> and
|
|
<TT
|
|
CLASS="literal"
|
|
>example2.net</TT
|
|
>) and
|
|
therefore two IPv6 addresses. Since the host chooses its own 64
|
|
bit host address portion, the provider address is the only part
|
|
that changes:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN example.com.
|
|
host IN A6 64 ::1234:5678:1212:5675 cust1.example.net.
|
|
IN A6 64 ::1234:5678:1212:5675 subnet5.example2.net.
|
|
$ORIGIN example.net.
|
|
cust1 IN A6 48 0:0:0:dddd:: ipv6net.example.net.
|
|
ipv6net IN A6 0 aa:bb:cccc::
|
|
$ORIGIN example2.net.
|
|
subnet5 IN A6 48 0:0:0:1:: ipv6net2.example2.net.
|
|
ipv6net2 IN A6 0 6666:5555:4::
|
|
</PRE
|
|
><P
|
|
>This sets up forward lookups. To handle the reverse lookups,
|
|
the provider <TT
|
|
CLASS="literal"
|
|
>example.net</TT
|
|
>
|
|
would have:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN \[x00aa00bbcccc/48].ip6.arpa.
|
|
\[xdddd/16] IN DNAME ipv6-rev.example.com.
|
|
</PRE
|
|
><P
|
|
>and <TT
|
|
CLASS="literal"
|
|
>example2.net</TT
|
|
> would have:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN \[x666655550004/48].ip6.arpa.
|
|
\[x0001/16] IN DNAME ipv6-rev.example.com.
|
|
</PRE
|
|
><P
|
|
><TT
|
|
CLASS="literal"
|
|
>example.com</TT
|
|
>
|
|
needs only one zone file to handle both of these reverse
|
|
mappings:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN ipv6-rev.example.com.
|
|
\[x1234567812125675/64] IN PTR host.example.com.
|
|
</PRE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="Bv9ARM.ch03.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="Bv9ARM.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="Bv9ARM.ch05.html"
|
|
>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 <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9 Lightweight Resolver</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |