mirror of
https://github.com/isc-projects/bind9.git
synced 2026-02-26 11:32:01 -05:00
1676 lines
No EOL
37 KiB
HTML
1676 lines
No EOL
37 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Advanced Concepts</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
|
|
REL="HOME"
|
|
HREF="Bv9ARM.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Nameserver 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"
|
|
></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 Concepts</A
|
|
></H1
|
|
><DIV
|
|
CLASS="TOC"
|
|
><DL
|
|
><DT
|
|
><B
|
|
>Table of Contents</B
|
|
></DT
|
|
><DT
|
|
>4.1. <A
|
|
HREF="Bv9ARM.ch04.html#dynamic_update"
|
|
>Dynamic Update</A
|
|
></DT
|
|
><DT
|
|
>4.2. <A
|
|
HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
|
|
>Incremental Zone Transfers (IXFR)</A
|
|
></DT
|
|
><DT
|
|
>4.3. <A
|
|
HREF="Bv9ARM.ch04.html#AEN654"
|
|
>Split DNS</A
|
|
></DT
|
|
><DT
|
|
>4.4. <A
|
|
HREF="Bv9ARM.ch04.html#tsig"
|
|
>TSIG</A
|
|
></DT
|
|
><DT
|
|
>4.5. <A
|
|
HREF="Bv9ARM.ch04.html#AEN816"
|
|
>TKEY</A
|
|
></DT
|
|
><DT
|
|
>4.6. <A
|
|
HREF="Bv9ARM.ch04.html#AEN831"
|
|
>SIG(0)</A
|
|
></DT
|
|
><DT
|
|
>4.7. <A
|
|
HREF="Bv9ARM.ch04.html#DNSSEC"
|
|
>DNSSEC</A
|
|
></DT
|
|
><DT
|
|
>4.8. <A
|
|
HREF="Bv9ARM.ch04.html#AEN915"
|
|
>IPv6 Support in <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9</A
|
|
></DT
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="dynamic_update"
|
|
>4.1. Dynamic Update</A
|
|
></H1
|
|
><P
|
|
>Dynamic update is the term used for the ability under
|
|
certain specified conditions to add, modify or delete records or
|
|
RRsets in the master zone files. Dynamic update is fully described
|
|
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) is modelled
|
|
after the <I
|
|
CLASS="emphasis"
|
|
>simple-secure-update</I
|
|
> proposal, a
|
|
work in progress in the DNS Extensions working group of the IETF.
|
|
(See <A
|
|
HREF="http://www.ietf.org/html.charters/dnsext-charter.html"
|
|
TARGET="_top"
|
|
>http://www.ietf.org/html.charters/dnsext-charter.html</A
|
|
>
|
|
for information about the DNS Extensions working group.) 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
|
|
><P
|
|
>The zone files of dynamic zones must not be edited by hand.
|
|
The zone file on disk at any given time may not contain the latest
|
|
changes performed by dynamic update. The zone file is written to
|
|
disk only periodically, and changes that have occurred since the
|
|
zone file was last written to disk are stored only in the zone's
|
|
journal (<TT
|
|
CLASS="filename"
|
|
>.jnl</TT
|
|
>) file. <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9 currently does
|
|
not update the zone file when it exits as <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 8 does, so editing
|
|
the zone file manually is unsafe even when the server has been
|
|
shut down. </P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="incremental_zone_transfers"
|
|
>4.2. 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 documented 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, but not manually maintained master
|
|
zones nor slave zones obtained by performing a full zone transfer
|
|
(AXFR).</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="AEN654"
|
|
>4.3. Split DNS</A
|
|
></H1
|
|
><P
|
|
>Setting up different views, or visibility, of 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
|
|
> (example.com)
|
|
has several corporate sites that have an internal network with reserved
|
|
Internet Protocol (IP) space and an external demilitarized zone (DMZ),
|
|
or "outside" section of a network, that is available to the public.</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 nameservers. One set will be on the inside network (in the reserved
|
|
IP space) and the other set will be on bastion hosts, which are "proxy"
|
|
hosts that can talk to both sides of its network, in the DMZ.</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.interna</TT
|
|
><I
|
|
CLASS="emphasis"
|
|
>l</I
|
|
> and<I
|
|
CLASS="emphasis"
|
|
> </I
|
|
><TT
|
|
CLASS="filename"
|
|
>site2.internal</TT
|
|
> domains,
|
|
the internal nameservers 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
|
|
nameservers 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
|
|
nameservers 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 <SPAN
|
|
CLASS="systemitem"
|
|
>site1</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="systemitem"
|
|
>site2.example.com</SPAN
|
|
> zones.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Look up any hostnames in the <SPAN
|
|
CLASS="systemitem"
|
|
>site1.internal</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="systemitem"
|
|
>site2.internal</SPAN
|
|
> 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 <SPAN
|
|
CLASS="systemitem"
|
|
>site1</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="systemitem"
|
|
>site2.example.com </SPAN
|
|
>zones.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Exchange mail with anyone in the <SPAN
|
|
CLASS="systemitem"
|
|
>site1</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="systemitem"
|
|
>site2.example.com</SPAN
|
|
> 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 slave 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" {
|
|
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.4. 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. Key-based
|
|
access control is far superior, see <A
|
|
HREF="Bv9ARM.ch09.html#proposed_standards"
|
|
>Proposed Standards</A
|
|
>. 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="AEN747"
|
|
>4.4.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="AEN752"
|
|
>4.4.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="AEN763"
|
|
>4.4.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="AEN768"
|
|
>4.4.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="AEN771"
|
|
>4.4.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 succeeds, the response is signed by
|
|
the same key.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN783"
|
|
>4.4.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 response
|
|
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 non-response messages to <I
|
|
CLASS="emphasis"
|
|
>host1</I
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN799"
|
|
>4.4.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.20.4</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN812"
|
|
>4.4.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="AEN816"
|
|
>4.5. 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
|
|
> 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="AEN831"
|
|
>4.6. 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
|
|
><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.7. 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.</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="AEN847"
|
|
>4.7.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 be mandatory to implement a
|
|
cryptographic algorithm; currently the only key mandatory to
|
|
implement an algorithm is 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 RSA, 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 with
|
|
<B
|
|
CLASS="command"
|
|
>$INCLUDE</B
|
|
> statements, including the
|
|
<TT
|
|
CLASS="filename"
|
|
>.key </TT
|
|
>files.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN867"
|
|
>4.7.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 +86400 Kchild.example.+003+12345 Kchild.example.+003+23456</B
|
|
></TT
|
|
></P
|
|
><P
|
|
>One output file is produced:
|
|
<TT
|
|
CLASS="filename"
|
|
>child.example.keyset</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="AEN879"
|
|
>4.7.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 grand.child.example.keyset Kchild.example.+003+12345 Kchild.example.+003+23456</B
|
|
></TT
|
|
></P
|
|
><P
|
|
>One output file is produced:
|
|
<TT
|
|
CLASS="filename"
|
|
>grand.child.example.signedkey</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="AEN892"
|
|
>4.7.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="AEN908"
|
|
>4.7.5. Configuring Servers</A
|
|
></H2
|
|
><P
|
|
>Unlike in <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 8, data is not verified on load in <SPAN
|
|
CLASS="acronym"
|
|
>BIND</SPAN
|
|
> 9,
|
|
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="AEN915"
|
|
>4.8. 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
|
|
"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 bitstring labels, see <A
|
|
HREF="Bv9ARM.ch05.html"
|
|
>Chapter 5</A
|
|
>.</P
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN929"
|
|
>4.8.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="AEN934"
|
|
>4.8.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="AEN938"
|
|
>4.8.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 <SPAN
|
|
CLASS="systemitem"
|
|
>host.example.com</SPAN
|
|
> 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="AEN949"
|
|
>4.8.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="AEN955"
|
|
>4.8.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 compatiblity 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="AEN962"
|
|
>4.8.4. Address to Name Lookups Using Bitstring Format</A
|
|
></H2
|
|
><P
|
|
>Bitstring 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 bitstrings:</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="AEN969"
|
|
>4.8.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
|
|
(<SPAN
|
|
CLASS="systemitem"
|
|
>example.net</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="systemitem"
|
|
>example2.net</SPAN
|
|
>) 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 A6 64 ::1234:5678:1212:5675 cust1.example.net.
|
|
A6 64 ::1234:5678:1212:5675 subnet5.example2.net.
|
|
$ORIGIN example.net.
|
|
cust1 A6 48 0:0:0:dddd:: ipv6net.example.net.
|
|
ipv6net A6 0 aa:bb:cccc::
|
|
$ORIGIN example2.net.
|
|
subnet5 A6 48 0:0:0:1:: ipv6net2.example2.net.
|
|
ipv6net2 A6 0 6666:5555:4::
|
|
</PRE
|
|
><P
|
|
>This sets up forward lookups. To handle the reverse lookups,
|
|
the provider <SPAN
|
|
CLASS="systemitem"
|
|
>example.net</SPAN
|
|
>
|
|
would have:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN \[x00aa00bbcccc/48].ip6.arpa.
|
|
\[xdddd/16] DNAME ipv6-rev.example.com.
|
|
</PRE
|
|
><P
|
|
>and <SPAN
|
|
CLASS="systemitem"
|
|
>example2.net</SPAN
|
|
> would have:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN \[x666655550004/48].ip6.arpa.
|
|
\[x0001/16] DNAME ipv6-rev.example.com.
|
|
</PRE
|
|
><P
|
|
><SPAN
|
|
CLASS="systemitem"
|
|
>example.com</SPAN
|
|
>
|
|
needs only one zone file to handle both of these reverse
|
|
mappings:</P
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> $ORIGIN ipv6-rev.example.com.
|
|
\[x1234567812125675/64] 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"
|
|
>Nameserver 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
|
|
> |