ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 23. The Domain Name System</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.reference.services.html" title="Part V. Services"><link rel="prev" href="cha.slp.html" title="Chapter 22. SLP Services in the Network"><link rel="next" href="cha.dhcp.html" title="Chapter 24. DHCP"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.opensuse.reference.html">Reference</a><span class="breadcrumbs-sep"> > </span><a href="part.reference.services.html">Services</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 22. SLP Services in the Network" href="cha.slp.html"><span>◀</span></a> <a accesskey="n" title="Chapter 24. DHCP" href="cha.dhcp.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 23. The Domain Name System"><div class="titlepage"><div><div><h2 class="title"><a name="cha.dns"></a>Chapter 23. The Domain Name System<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.dns">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.dns.html#sec.dns.basic">23.1. DNS Terminology</a></span></dt><dt><span class="sect1"><a href="cha.dns.html#sec.dns.install">23.2. Installation</a></span></dt><dt><span class="sect1"><a href="cha.dns.html#sec.dns.yast">23.3. Configuration with YaST</a></span></dt><dt><span class="sect1"><a href="cha.dns.html#sec.dns.bind">23.4. Starting the BIND Name Server</a></span></dt><dt><span class="sect1"><a href="cha.dns.html#sec.dns.named">23.5. The /etc/named.conf Configuration File</a></span></dt><dt><span class="sect1"><a href="cha.dns.html#sec.dns.zonefile">23.6. Zone Files</a></span></dt><dt><span class="sect1"><a href="cha.dns.html#sec.dns.dynupdate">23.7. Dynamic Update of Zone Data</a></span></dt><dt><span class="sect1"><a href="cha.dns.html#sec.dns.tsig">23.8. Secure Transactions</a></span></dt><dt><span class="sect1"><a href="cha.dns.html#sec.dns.dnssec">23.9. DNS Security</a></span></dt><dt><span class="sect1"><a href="cha.dns.html#sec.dns.info">23.10. For More Information</a></span></dt></dl></div><a class="indexterm" name="id484782"></a><a class="indexterm" name="id484791"></a><a class="indexterm" name="id484799"></a><a class="indexterm" name="id484808"></a><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>
DNS (domain name system) is needed to resolve the domain names and
hostnames into IP addresses. In this way, the IP address 192.168.2.100 is
assigned to the hostname <code class="literal">jupiter</code>, for example. Before
setting up your own name server, read the general information about DNS
in <a class="xref" href="cha.basicnet.html#sec.basicnet.nameres" title="21.3. Name Resolution">Section 21.3, “Name Resolution”</a>. The following configuration
examples refer to BIND.
</p></div><div class="sect1" title="23.1. DNS Terminology"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.basic"></a>23.1. DNS Terminology<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.basic">¶</a></span></h2></div></div></div><a class="indexterm" name="id484844"></a><div class="variablelist"><dl><dt><span class="term">Zone</span></dt><dd><p>
The domain namespace is divided into regions called zones. For
instance, if you have <code class="literal">example.com</code>, you have the
<code class="literal">example</code> section (or zone) of the
<code class="literal">com</code> domain.
</p></dd><dt><span class="term">DNS server</span></dt><dd><p>
The DNS server is a server that maintains the name and IP information
for a domain. You can have a primary DNS server for master zone, a
secondary server for slave zone, or a slave server without any zones
for caching.
</p><div class="variablelist"><dl><dt><span class="term">Master zone DNS server</span></dt><dd><p>
The master zone includes all hosts from your network and a DNS
server master zone stores up-to-date records for all the hosts in
your domain.
</p></dd><dt><span class="term">Slave zone DNS server</span></dt><dd><p>
A slave zone is a copy of the master zone. The slave zone DNS
server obtains its zone data with zone transfer operations from its
master server. The slave zone DNS server responds authoritatively
for the zone as long as it has valid (not expired) zone data. If
the slave cannot obtain a new copy of the zone data, it stops
responding for the zone.
</p></dd></dl></div></dd><dt><span class="term">Forwarder</span></dt><dd><p>
Forwarders are DNS servers to which your DNS server should send
queries it cannot answer. To enable different configuration sources in
one configuration, <code class="literal">netconfig</code> is used (see also
<span class="command"><strong>man 8 netconfig</strong></span>).
</p></dd><dt><span class="term">Record</span></dt><dd><p>
The record is information about name and IP address. Supported records
and their syntax are described in BIND documentation. Some special
records are:
</p><div class="variablelist"><dl><dt><span class="term">NS record</span></dt><dd><p>
An NS record tells name servers which machines are in charge of a
given domain zone.
</p></dd><dt><span class="term">MX record</span></dt><dd><p>
The MX (mail exchange) records describe the machines to contact for
directing mail across the Internet.
</p></dd><dt><span class="term">SOA record</span></dt><dd><p>
SOA (Start of Authority) record is the first record in a zone file.
The SOA record is used when using DNS to synchronize data between
multiple computers.
</p></dd></dl></div></dd></dl></div></div><div class="sect1" title="23.2. Installation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.install"></a>23.2. Installation<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.install">¶</a></span></h2></div></div></div><p>
To install a DNS server, start YaST and select
<span class="guimenu">Software</span>+<span class="guimenu">Software
Management</span>. Choose
<span class="guimenu">Filter</span>+<span class="guimenu">Patterns</span> and select <span class="guimenu">DHCP and DNS
Server</span>. Confirm the installation of the dependent packages to
finish the installation process.
</p></div><div class="sect1" title="23.3. Configuration with YaST"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.yast"></a>23.3. Configuration with YaST<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.yast">¶</a></span></h2></div></div></div><p>
Use the YaST DNS module to configure a DNS server for the local
network. When starting the module for the first time, a wizard starts,
prompting you to make a few decisions concerning administration of the
server. Completing this initial setup produces a basic server
configuration. Use the expert mode to deal with more advanced
configuration tasks, such as setting up ACLs, logging, TSIG keys, and
other options.
</p><div class="sect2" title="23.3.1. Wizard Configuration"><div class="titlepage"><div><div><h3 class="title"><a name="sec.dns.yast.wizard"></a>23.3.1. Wizard Configuration<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.yast.wizard">¶</a></span></h3></div></div></div><p>
The wizard consists of three steps or dialogs. At the appropriate places
in the dialogs, you are given the opportunity to enter the expert
configuration mode.
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
When starting the module for the first time, the <span class="guimenu">Forwarder
Settings</span> dialog, shown in
<a class="xref" href="cha.dns.html#fig.yast2.dnsinst.forwarders" title="Figure 23.1. DNS Server Installation: Forwarder Settings">Figure 23.1, “DNS Server Installation: Forwarder Settings”</a>, opens. The
<span class="guimenu">Netconfig DNS Policy</span> decides which devices should
provide forwarders or whether you want to supply your own
<span class="guimenu">Forwarder List</span>. For more information about
netconfig, see <span class="command"><strong>man 8 netconfig</strong></span>.
</p><div class="figure"><a name="fig.yast2.dnsinst.forwarders"></a><p class="title"><b>Figure 23.1. DNS Server Installation: Forwarder Settings</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.dnsinst.forwarders">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_dns_wiz_forw.png" width="100%" alt="DNS Server Installation: Forwarder Settings"></td></tr></table></div></div></div><br class="figure-break"><p>
Forwarders are DNS servers to which your DNS server sends queries it
cannot answer itself. Enter their IP address and click
<span class="guimenu">Add</span>.
</p></li><li><p>
The <span class="guimenu">DNS Zones</span> dialog consists of several parts and
is responsible for the management of zone files, described in
<a class="xref" href="cha.dns.html#sec.dns.zonefile" title="23.6. Zone Files">Section 23.6, “Zone Files”</a>. For a new zone, provide a name for
it in <span class="guimenu">Name</span>. To add a reverse zone, the name must
end in <code class="literal">.in-addr.arpa</code>. Finally, select the
<span class="guimenu">Type</span> (master, slave, or forward). See
<a class="xref" href="cha.dns.html#fig.yast2.dnsinst.zones" title="Figure 23.2. DNS Server Installation: DNS Zones">Figure 23.2, “DNS Server Installation: DNS Zones”</a>. Click <span class="guimenu">Edit
</span> to configure other settings of an existing zone. To remove
a zone, click <span class="guimenu">Delete</span>.
</p><div class="figure"><a name="fig.yast2.dnsinst.zones"></a><p class="title"><b>Figure 23.2. DNS Server Installation: DNS Zones</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.dnsinst.zones">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_dns_wiz_zone.png" width="100%" alt="DNS Server Installation: DNS Zones"></td></tr></table></div></div></div><br class="figure-break"></li><li><p>
In the final dialog, you can open the DNS port in the firewall by
clicking <span class="guimenu">Open Port in Firewall</span>. Then decide whether
to start the DNS server when booting (<span class="guimenu">On</span> or
<span class="guimenu">Off</span>). You can also activate LDAP support. See
<a class="xref" href="cha.dns.html#fig.yast2.dnsinst.finish" title="Figure 23.3. DNS Server Installation: Finish Wizard">Figure 23.3, “DNS Server Installation: Finish Wizard”</a>.
</p><div class="figure"><a name="fig.yast2.dnsinst.finish"></a><p class="title"><b>Figure 23.3. DNS Server Installation: Finish Wizard</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.dnsinst.finish">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_dns_wiz_finish.png" width="100%" alt="DNS Server Installation: Finish Wizard"></td></tr></table></div></div></div><br class="figure-break"></li></ol></div></div><div class="sect2" title="23.3.2. Expert Configuration"><div class="titlepage"><div><div><h3 class="title"><a name="id485353"></a>23.3.2. Expert Configuration<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485353">¶</a></span></h3></div></div></div><p>
After starting the module, YaST opens a window displaying several
configuration options. Completing it results in a DNS server
configuration with the basic functions in place:
</p><div class="sect3" title="23.3.2.1. Start-Up"><div class="titlepage"><div><div><h4 class="title"><a name="id485364"></a>23.3.2.1. Start-Up<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485364">¶</a></span></h4></div></div></div><p>
Under <span class="guimenu">Start-Up</span>, define whether the DNS server should
be started when the booting the system or manually. To start the DNS
server immediately, click <span class="guimenu">Start DNS Server Now</span>. To
stop the DNS server, click <span class="guimenu">Stop DNS Server Now</span>. To
save the current settings, select <span class="guimenu">Save Settings and Reload DNS
Server Now</span>.
You can open the DNS port in the firewall with <span class="guimenu">Open Port in
Firewall</span> and modify the firewall settings with
<span class="guimenu">Firewall Details</span>.
</p><p>
By selecting <span class="guimenu">LDAP Support Active</span>, the zone files are
managed by an LDAP database. Any changes to zone data written to the
LDAP database are picked up by the DNS server as soon as it is
restarted or prompted to reload its configuration.
</p></div><div class="sect3" title="23.3.2.2. Forwarders"><div class="titlepage"><div><div><h4 class="title"><a name="id485409"></a>23.3.2.2. Forwarders<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485409">¶</a></span></h4></div></div></div><p>
If your local DNS server cannot answer a request, it tries to forward
the request to a <span class="guimenu">Forwarder</span>, if configured so. This
forwarder may be added manually to the <span class="guimenu">Forwarder
List</span>. If the forwarder is not static like in dial-up
connections, <span class="guimenu">netconfig</span> handles the configuration.
For more information about netconfig, see <span class="command"><strong>man 8
netconfig</strong></span>.
</p></div><div class="sect3" title="23.3.2.3. Basic Options"><div class="titlepage"><div><div><h4 class="title"><a name="id485437"></a>23.3.2.3. Basic Options<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485437">¶</a></span></h4></div></div></div><p>
In this section, set basic server options. From the
<span class="guimenu">Option</span> menu, select the desired item then specify
the value in the corresponding entry field. Include the new entry by
selecting <span class="guimenu">Add</span>.
</p></div><div class="sect3" title="23.3.2.4. Logging"><div class="titlepage"><div><div><h4 class="title"><a name="id485457"></a>23.3.2.4. Logging<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485457">¶</a></span></h4></div></div></div><p>
To set what the DNS server should log and how, select
<span class="guimenu">Logging</span>. Under <span class="guimenu">Log Type</span>, specify
where the DNS server should write the log data. Use the systemwide log
file <code class="filename">/var/log/messages</code> by selecting
<span class="guimenu">System Log</span> or specify a different file by selecting
<span class="guimenu">File</span>. In the latter case, additionally specify a
name, the maximum file size in megabytes and the number of logfile
versions to store.
</p><p>
Further options are available under <span class="guimenu">Additional
Logging</span>. Enabling <span class="guimenu">Log All DNS Queries</span>
causes <span class="emphasis"><em>every</em></span> query to be logged, in which case the
log file could grow extremely large. For this reason, it is not a good
idea to enable this option for other than debugging purposes. To log
the data traffic during zone updates between DHCP and DNS server,
enable <span class="guimenu">Log Zone Updates</span>. To log the data traffic
during a zone transfer from master to slave, enable <span class="guimenu">Log Zone
Transfer</span>. See <a class="xref" href="cha.dns.html#fig.yast2.dns.logging" title="Figure 23.4. DNS Server: Logging">Figure 23.4, “DNS Server: Logging”</a>.
</p><div class="figure"><a name="fig.yast2.dns.logging"></a><p class="title"><b>Figure 23.4. DNS Server: Logging</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.dns.logging">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_dns_def_logging.png" width="100%" alt="DNS Server: Logging"></td></tr></table></div></div></div><br class="figure-break"></div><div class="sect3" title="23.3.2.5. ACLs"><div class="titlepage"><div><div><h4 class="title"><a name="id485565"></a>23.3.2.5. ACLs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485565">¶</a></span></h4></div></div></div><p>
Use this dialog to define ACLs (access control lists) to enforce access
restrictions. After providing a distinct name under
<span class="guimenu">Name</span>, specify an IP address (with or without
netmask) under <span class="guimenu">Value</span> in the following fashion:
</p><pre class="screen">{ 192.168.1/24; }</pre><p>
The syntax of the configuration file requires that the address ends
with a semicolon and is put into curly braces.
</p></div><div class="sect3" title="23.3.2.6. TSIG Keys"><div class="titlepage"><div><div><h4 class="title"><a name="id485594"></a>23.3.2.6. TSIG Keys<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485594">¶</a></span></h4></div></div></div><p>
The main purpose of TSIGs (transaction signatures) is to secure
communications between DHCP and DNS servers. They are described in
<a class="xref" href="cha.dns.html#sec.dns.tsig" title="23.8. Secure Transactions">Section 23.8, “Secure Transactions”</a>.
</p><p>
To generate a TSIG key, enter a distinctive name in the field labeled
<span class="guimenu">Key ID</span> and specify the file where the key should be
stored (<span class="guimenu">Filename</span>). Confirm your choices with
<span class="guimenu">Generate</span>.
</p><p>
To use a previously created key, leave the <span class="guimenu">Key ID</span>
field blank and select the file where it is stored under
<span class="guimenu">Filename</span>. After that, confirm with
<span class="guimenu">Add</span>.
</p></div><div class="sect3" title="23.3.2.7. DNS Zones (Adding a Slave Zone)"><div class="titlepage"><div><div><h4 class="title"><a name="id485642"></a>23.3.2.7. DNS Zones (Adding a Slave Zone)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485642">¶</a></span></h4></div></div></div><p>
To add a slave zone, select <span class="guimenu">DNS Zones</span>, choose the
zone type <span class="guimenu">Slave</span>, write the name of the new zone, and
click <span class="guimenu">Add</span>.
</p><p>
In the <span class="guimenu">Zone Editor</span> sub-dialog under <span class="guimenu">Master
DNS Server IP</span>, specify the master from which the slave should
pull its data. To limit access to the server, select one of the ACLs
from the list.
</p></div><div class="sect3" title="23.3.2.8. DNS Zones (Adding a Master Zone)"><div class="titlepage"><div><div><h4 class="title"><a name="id485678"></a>23.3.2.8. DNS Zones (Adding a Master Zone)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485678">¶</a></span></h4></div></div></div><p>
To add a master zone, select <span class="guimenu">DNS Zones</span>, choose the
zone type <span class="guimenu">Master</span>, write the name of the new zone,
and click <span class="guimenu">Add</span>. When adding a master zone, a reverse
zone is also needed. For example, when adding the zone
<code class="systemitem">example.com</code> that points to hosts in a subnet
<code class="literal">192.168.1.0/24</code>, you should also add a reverse zone
for the IP-address range covered. By definition, this should be named
<code class="literal">1.168.192.in-addr.arpa</code>.
</p></div><div class="sect3" title="23.3.2.9. DNS Zones (Editing a Master Zone)"><div class="titlepage"><div><div><h4 class="title"><a name="id485714"></a>23.3.2.9. DNS Zones (Editing a Master Zone)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id485714">¶</a></span></h4></div></div></div><p>
To edit a master zone, select <span class="guimenu">DNS Zones</span>, select the
master zone from the table, and click <span class="guimenu">Edit</span>. The
dialog consists of several pages: <span class="guimenu">Basics</span> (the one
opened first), <span class="guimenu">NS Records</span>, <span class="guimenu">MX
Records</span>, <span class="guimenu">SOA</span>, and
<span class="guimenu">Records</span>.
</p><p>
The basic dialog, shown in <a class="xref" href="cha.dns.html#fig.yast2.dns.ddns" title="Figure 23.5. DNS Server: Zone Editor (Basics)">Figure 23.5, “DNS Server: Zone Editor (Basics)”</a>, lets
you define settings for dynamic DNS and access options for zone
transfers to clients and slave name servers. To permit the dynamic
updating of zones, select <span class="guimenu">Allow Dynamic Updates</span> as
well as the corresponding TSIG key. The key must have been defined
before the update action starts. To enable zone transfers, select the
corresponding ACLs. ACLs must have been defined already.
</p><p>
In the <span class="guimenu">Basics</span> dialog, select whether to enable
zone transfers. Use the listed ACLs to define who can download
zones.
</p><div class="figure"><a name="fig.yast2.dns.ddns"></a><p class="title"><b>Figure 23.5. DNS Server: Zone Editor (Basics)</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.dns.ddns">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_dns_def_ddns.png" width="100%" alt="DNS Server: Zone Editor (Basics)"></td></tr></table></div></div></div><br class="figure-break"><div class="variablelist"><dl><dt><span class="term">Zone Editor (NS Records)</span></dt><dd><p>
The <span class="guimenu">NS Records</span> dialog allows you to define
alternative name servers for the zones specified. Make sure that
your own name server is included in the list. To add a record,
enter its name under <span class="guimenu">Name Server to Add</span> then
confirm with <span class="guimenu">Add</span>. See <a class="xref" href="cha.dns.html#fig.yast2.dns.nsrec" title="Figure 23.6. DNS Server: Zone Editor (NS Records)">Figure 23.6, “DNS Server: Zone Editor (NS Records)”</a>.
</p><div class="figure"><a name="fig.yast2.dns.nsrec"></a><p class="title"><b>Figure 23.6. DNS Server: Zone Editor (NS Records)</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.dns.nsrec">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_dns_def_nsrec.png" width="100%" alt="DNS Server: Zone Editor (NS Records)"></td></tr></table></div></div></div><br class="figure-break"></dd><dt><span class="term">Zone Editor (MX Records)</span></dt><dd><p>
To add a mail server for the current zone to the existing list,
enter the corresponding address and priority value. After doing so,
confirm by selecting <span class="guimenu">Add</span>. See
<a class="xref" href="cha.dns.html#fig.yast2.dns.mxrec" title="Figure 23.7. DNS Server: Zone Editor (MX Records)">Figure 23.7, “DNS Server: Zone Editor (MX Records)”</a>.
</p><div class="figure"><a name="fig.yast2.dns.mxrec"></a><p class="title"><b>Figure 23.7. DNS Server: Zone Editor (MX Records)</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.dns.mxrec">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_dns_def_mxrec.png" width="100%" alt="DNS Server: Zone Editor (MX Records)"></td></tr></table></div></div></div><br class="figure-break"></dd><dt><span class="term">Zone Editor (SOA)</span></dt><dd><p>
This page allows you to create SOA (start of authority) records. For
an explanation of the individual options, refer to
<a class="xref" href="cha.dns.html#ex.welt.zone" title="Example 23.6. The /var/lib/named/example.com.zone File">Example 23.6, “The /var/lib/named/example.com.zone File”</a>.
</p><div class="figure"><a name="fig.yast2.dns.soa"></a><p class="title"><b>Figure 23.8. DNS Server: Zone Editor (SOA)</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.dns.soa">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_dns_def_soa.png" width="100%" alt="DNS Server: Zone Editor (SOA)"></td></tr></table></div></div></div><br class="figure-break"></dd><dt><span class="term">Zone Editor (Records)</span></dt><dd><p>
This dialog manages name resolution. In <span class="guimenu">Record
Key</span>, enter the hostname then select its type.
<span class="guimenu">A-Record</span> represents the main entry. The value for
this should be an IP address. <span class="guimenu">CNAME</span> is an alias.
Use the types <span class="guimenu">NS</span> and <span class="guimenu">MX</span> for
detailed or partial records that expand on the information provided
in the <span class="guimenu">NS Records</span> and <span class="guimenu">MX
Records</span> tabs. These three types resolve to an existing A
record. <span class="guimenu">PTR</span> is for reverse zones. It is the
opposite of an <code class="literal">A</code> record, for example:
</p><pre class="screen">hostname.example.com. IN A 192.168.0.1
1.0.168.192.in-addr.arpa IN PTR hostname.example.com.</pre></dd></dl></div><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note: Editing the Reverse Zone"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left">Editing the Reverse Zone</th></tr><tr><td colspan="2" align="left" valign="top"><p>
After adding a forward zone, go back to the main menu and select the
reverse zone for editing. There in the tab <span class="guimenu">Basics</span>
activate the checkbox <span class="guimenu">Automatically Generate Records
From</span> and select your forward zone. That way, all changes to
the forward zone are automatically updated in the reverse zone.
</p></td></tr></table></div></div></div></div><div class="sect1" title="23.4. Starting the BIND Name Server"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.bind"></a>23.4. Starting the BIND Name Server<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.bind">¶</a></span></h2></div></div></div><a class="indexterm" name="idx.DNS_BIND"></a><a class="indexterm" name="idx.BIND"></a><p>
On a openSUSE® system, the name server BIND (<span class="emphasis"><em>Berkeley
Internet Name Domain</em></span>) comes preconfigured so it can be started
right after installation without any problem. If you already have a
functioning Internet connection and have entered
<code class="systemitem">127.0.0.1</code> as the name
server address for <code class="systemitem">localhost</code>
in <code class="filename">/etc/resolv.conf</code>, you normally already have a
working name resolution without needing to know the DNS of the provider.
BIND carries out name resolution via the root name server, a notably
slower process. Normally, the DNS of the provider should be entered with
its IP address in the configuration file
<code class="filename">/etc/named.conf</code> under
<code class="systemitem">forwarders</code> to ensure effective and secure name
resolution. If this works so far, the name server runs as a pure
<span class="emphasis"><em>caching-only</em></span> name server. Only when you configure
its own zones it becomes a proper DNS. Find a simple example documented
in <code class="filename">/usr/share/doc/packages/bind/config</code>.
</p><a class="indexterm" name="id486203"></a><a class="indexterm" name="id486212"></a><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Automatic Adaptation of the Name Server Information"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Automatic Adaptation of the Name Server Information</th></tr><tr><td colspan="2" align="left" valign="top"><p>
Depending on the type of Internet connection or the network connection,
the name server information can automatically be adapted to the current
conditions. To do this, set the
<code class="systemitem">NETCONFIG_DNS_POLICY</code> variable in the
<code class="filename">/etc/sysconfig/network/config</code> file to
<code class="literal">auto</code>.
</p></td></tr></table></div><p>
However, do not set up an official domain until one is assigned to you by
the responsible institution. Even if you have your own domain and it is
managed by the provider, you are better off not using it, because BIND
would otherwise not forward requests for this domain. The Web server at
the provider, for example, would not be accessible for this domain.
</p><p>
To start the name server, enter the command
<span class="command"><strong>rcnamed</strong></span> <code class="option">start</code> as
<code class="systemitem">root</code>. If <span class="quote">“<span class="quote">done</span>”</span>
appears to the right in green then named (as the name server process is
called) has been started successfully. Test the name server immediately
on the local system with the <span class="command"><strong>host</strong></span> or
<span class="command"><strong>dig</strong></span> programs, which should return
<code class="systemitem">localhost</code> as the default
server with the address
<code class="systemitem">127.0.0.1</code>. If this is not the
case, <code class="filename">/etc/resolv.conf</code> probably contains an
incorrect name server entry or the file does not exist at all. For the
first test, enter
<span class="command"><strong>host</strong></span> <code class="option">127.0.0.1</code>, which should
always work. If you get an error message, use
<span class="command"><strong>rcnamed</strong></span> <code class="option">status</code> to see whether
the server is actually running. If the name server does not start or
behaves unexpectedly, you can usually find the cause in the log file
<code class="filename">/var/log/messages</code>.
</p><a class="indexterm" name="id486319"></a><a class="indexterm" name="id486327"></a><a class="indexterm" name="id486336"></a><p>
To use the name server of the provider (or one already running on your
network) as the forwarder, enter the corresponding IP address or
addresses in the <code class="systemitem">options</code> section under
<code class="systemitem">forwarders</code>. The addresses included in
<a class="xref" href="cha.dns.html#ex.forward" title="Example 23.1. Forwarding Options in named.conf">Example 23.1, “Forwarding Options in named.conf”</a> are just examples. Adjust these entries to
your own setup. <a class="indexterm" name="id486362"></a>
</p><div class="example"><a name="ex.forward"></a><p class="title"><b>Example 23.1. Forwarding Options in named.conf</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#ex.forward">¶</a></span></p><div class="example-contents"><pre class="screen">options {
directory "/var/lib/named";
forwarders { 10.11.12.13; 10.11.12.14; };
listen-on { 127.0.0.1; 192.168.1.116; };
allow-query { 127/8; 192.168/16 };
notify no;
};</pre></div></div><br class="example-break"><p>
The <code class="systemitem">options</code> entry is followed by entries for the
zone, <code class="systemitem">localhost</code>, and
<code class="systemitem">0.0.127.in-addr.arpa</code>. The <code class="literal">type
hint</code> entry under <span class="quote">“<span class="quote">.</span>”</span> should always be present. The
corresponding files do not need to be modified and should work as they
are. Also make sure that each entry is closed with a <span class="quote">“<span class="quote">;</span>”</span> and
that the curly braces are in the correct places. After changing the
configuration file <code class="filename">/etc/named.conf</code> or the zone
files, tell BIND to reread them with
<span class="command"><strong>rcnamed</strong></span> <code class="option">reload</code>. Achieve the same
by stopping and restarting the name server with
<span class="command"><strong>rcnamed</strong></span> <code class="option">restart</code>. Stop the server
at any time by entering
<span class="command"><strong>rcnamed</strong></span> <code class="option">stop</code>.
</p></div><div class="sect1" title="23.5. The /etc/named.conf Configuration File"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.named"></a>23.5. The /etc/named.conf Configuration File<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.named">¶</a></span></h2></div></div></div><a class="indexterm" name="idx.configuration_files_named.conf"></a><p>
All the settings for the BIND name server itself are stored in the
<code class="filename">/etc/named.conf</code> file. However, the zone data for the
domains to handle (consisting of the hostnames, IP addresses, and so on)
are stored in separate files in the <code class="filename">/var/lib/named</code>
directory. The details of this are described later.
</p><p>
<code class="filename">/etc/named.conf</code> is roughly divided into two areas.
One is the <code class="systemitem">options</code> section for general settings
and the other consists of <code class="systemitem">zone</code> entries for the
individual domains. A <code class="systemitem">logging</code> section and
<code class="systemitem">acl</code> (access control list) entries are optional.
Comment lines begin with a <code class="literal">#</code> sign or
<code class="literal">//</code>. A minimal <code class="filename">/etc/named.conf</code> is
shown in <a class="xref" href="cha.dns.html#ex.named.mini" title="Example 23.2. A Basic /etc/named.conf">Example 23.2, “A Basic /etc/named.conf”</a>.
</p><div class="example"><a name="ex.named.mini"></a><p class="title"><b>Example 23.2. A Basic /etc/named.conf</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#ex.named.mini">¶</a></span></p><div class="example-contents"><pre class="screen">options {
directory "/var/lib/named";
forwarders { 10.0.0.1; };
notify no;
};
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone "." in {
type hint;
file "root.hint";
};</pre></div></div><br class="example-break"><div class="sect2" title="23.5.1. Important Configuration Options"><div class="titlepage"><div><div><h3 class="title"><a name="sec.dns.named.options"></a>23.5.1. Important Configuration Options<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.named.options">¶</a></span></h3></div></div></div><a class="indexterm" name="id486554"></a><div class="variablelist"><dl><dt><span class="term">directory "<em class="replaceable"><code>filename</code></em>";</span></dt><dd><p>
Specifies the directory in which BIND can find the files containing
the zone data. Usually, this is <code class="filename">/var/lib/named</code>.
</p></dd><dt><span class="term">forwarders { <em class="replaceable"><code>ip-address</code></em>; };</span></dt><dd><p>
Specifies the name servers (mostly of the provider) to which DNS
requests should be forwarded if they cannot be resolved directly.
Replace <em class="replaceable"><code>ip-address</code></em> with an IP address like
<code class="literal">192.168.1.116</code>.
</p></dd><dt><span class="term">forward first;</span></dt><dd><p>
Causes DNS requests to be forwarded before an attempt is made to
resolve them via the root name servers. Instead of
<code class="systemitem">forward first</code>, <code class="systemitem">forward
only</code> can be written to have all requests forwarded and
none sent to the root name servers. This makes sense for firewall
configurations.
</p></dd><dt><span class="term">listen-on port 53 { 127.0.0.1; <em class="replaceable"><code>ip-address</code></em>; };<a class="indexterm" name="id486650"></a></span></dt><dd><p>
Tells BIND on which network interfaces and port to accept client
queries. <code class="literal">port 53</code> does not need to be specified
explicitly, because <code class="literal">53</code> is the default port. Enter
<code class="literal">127.0.0.1</code> to permit requests from the local host.
If you omit this entry entirely, all interfaces are used by default.
</p></dd><dt><span class="term">listen-on-v6 port 53 {any; };</span></dt><dd><p>
Tells BIND on which port it should listen for IPv6 client requests.
The only alternative to <code class="literal">any</code> is
<code class="literal">none</code>. As far as IPv6 is concerned, the server only
accepts wild card addresses.
</p></dd><dt><span class="term">query-source address * port 53;</span></dt><dd><p>
This entry is necessary if a firewall is blocking outgoing DNS
requests. This tells BIND to post requests externally from port 53
and not from any of the high ports above 1024.
</p></dd><dt><span class="term">query-source-v6 address * port 53;</span></dt><dd><p>
Tells BIND which port to use for IPv6 queries.
</p></dd><dt><span class="term">allow-query { 127.0.0.1; <em class="replaceable"><code>net</code></em>; };</span></dt><dd><p>
Defines the networks from which clients can post DNS requests.
Replace <em class="replaceable"><code>net</code></em> with address information like
<code class="literal">192.168.2.0/24</code>. The <code class="systemitem">/24</code>
at the end is an abbreviated expression for the netmask (in this case
<code class="systemitem">255.255.255.0</code>).
</p></dd><dt><span class="term">allow-transfer ! *;;</span></dt><dd><p>
Controls which hosts can request zone transfers. In the example, such
requests are completely denied with <code class="systemitem">! *</code>.
Without this entry, zone transfers can be requested from anywhere
without restrictions.
</p></dd><dt><span class="term">statistics-interval 0;</span></dt><dd><p>
In the absence of this entry, BIND generates several lines of
statistical information per hour in
<code class="filename">/var/log/messages</code>. Set it to 0 to suppress these
statistics completely or set an interval in minutes.
</p></dd><dt><span class="term">cleaning-interval 720;</span></dt><dd><p>
This option defines at which time intervals BIND clears its cache.
This triggers an entry in <code class="filename">/var/log/messages</code> each
time it occurs. The time specification is in minutes. The default is
60 minutes.
</p></dd><dt><span class="term">interface-interval 0;</span></dt><dd><p>
BIND regularly searches the network interfaces for new or nonexistent
interfaces. If this value is set to <code class="systemitem">0</code>, this
is not done and BIND only listens at the interfaces detected at
start-up. Otherwise, the interval can be defined in minutes. The
default is sixty minutes.
</p></dd><dt><span class="term">notify no;</span></dt><dd><p>
<code class="option">no</code> prevents other name servers from being informed
when changes are made to the zone data or when the name server is
restarted.
</p></dd></dl></div><p>
For a list of available options, read the manual page <span class="command"><strong>man 5
named.conf</strong></span>.
</p></div><div class="sect2" title="23.5.2. Logging"><div class="titlepage"><div><div><h3 class="title"><a name="sec.dns.named.log"></a>23.5.2. Logging<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.named.log">¶</a></span></h3></div></div></div><a class="indexterm" name="id486896"></a><p>
What, how, and where logging takes place can be extensively configured
in BIND. Normally, the default settings should be sufficient.
<a class="xref" href="cha.dns.html#ex.no.log" title="Example 23.3. Entry to Disable Logging">Example 23.3, “Entry to Disable Logging”</a>, shows the simplest form of such an entry
and completely suppresses any logging.
</p><div class="example"><a name="ex.no.log"></a><p class="title"><b>Example 23.3. Entry to Disable Logging</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#ex.no.log">¶</a></span></p><div class="example-contents"><pre class="screen">logging {
category default { null; };
};</pre></div></div><br class="example-break"></div><div class="sect2" title="23.5.3. Zone Entries"><div class="titlepage"><div><div><h3 class="title"><a name="sec.dns.named.zones"></a>23.5.3. Zone Entries<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.named.zones">¶</a></span></h3></div></div></div><div class="example"><a name="ex.meine.domain"></a><p class="title"><b>Example 23.4. Zone Entry for example.com</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#ex.meine.domain">¶</a></span></p><div class="example-contents"><pre class="screen">zone "example.com" in {
type master;
file "example.com.zone";
notify no;
};</pre></div></div><br class="example-break"><p>
After <code class="systemitem">zone</code>, specify the name of the domain to
administer (<code class="systemitem">example.com</code>)
followed by <code class="systemitem">in</code> and a block of relevant options
enclosed in curly braces, as shown in <a class="xref" href="cha.dns.html#ex.meine.domain" title="Example 23.4. Zone Entry for example.com">Example 23.4, “Zone Entry for example.com”</a>.
To define a <span class="emphasis"><em>slave zone</em></span>, switch the
<code class="systemitem">type</code> to <code class="literal">slave</code> and specify a
name server that administers this zone as <code class="literal">master</code>
(which, in turn, may be a slave of another master), as shown in
<a class="xref" href="cha.dns.html#ex.andere.domain" title="Example 23.5. Zone Entry for example.net">Example 23.5, “Zone Entry for example.net”</a>.
</p><div class="example"><a name="ex.andere.domain"></a><p class="title"><b>Example 23.5. Zone Entry for example.net</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#ex.andere.domain">¶</a></span></p><div class="example-contents"><pre class="screen">zone "example.net" in {
type slave;
file "slave/example.net.zone";
masters { 10.0.0.1; };
};</pre></div></div><br class="example-break"><p>
The zone options:
</p><div class="variablelist"><dl><dt><span class="term">type master;</span></dt><dd><p>
By specifying <code class="literal">master</code>, tell BIND that the zone is
handled by the local name server. This assumes that a zone file has
been created in the correct format.
</p></dd><dt><span class="term">type slave;</span></dt><dd><p>
This zone is transferred from another name server. It must be used
together with <code class="systemitem">masters</code>.
</p></dd><dt><span class="term">type hint;</span></dt><dd><p>
The zone <code class="literal">.</code> of the <code class="literal">hint</code> type is
used to set the root name servers. This zone definition can be left
as is.
</p></dd><dt><span class="term">file <code class="filename">example.com.zone</code> or file
<span class="quote">“<span class="quote">slave/example.net.zone</span>”</span>;</span></dt><dd><p>
This entry specifies the file where zone data for the domain is
located. This file is not required for a slave, because this data is
pulled from another name server. To differentiate master and slave
files, use the directory <code class="filename">slave</code> for the slave
files.
</p></dd><dt><span class="term">masters { <em class="replaceable"><code>server-ip-address</code></em>; };</span></dt><dd><p>
This entry is only needed for slave zones. It specifies from which
name server the zone file should be transferred.
</p></dd><dt><span class="term">allow-update {! *; };</span></dt><dd><p>
This option controls external write access, which would allow clients
to make a DNS entry—something not normally desirable for
security reasons. Without this entry, zone updates are not allowed at
all. The above entry achieves the same because <code class="literal">! *</code>
effectively bans any such activity.
</p></dd></dl></div></div></div><div class="sect1" title="23.6. Zone Files"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.zonefile"></a>23.6. Zone Files<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.zonefile">¶</a></span></h2></div></div></div><a class="indexterm" name="id487169"></a><p>
Two types of zone files are needed. One assigns IP addresses to hostnames
and the other does the reverse: it supplies a hostname for an IP address.
</p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Using the Dot (Period, Fullstop) in Zone Files"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Using the Dot (Period, Fullstop) in Zone Files</th></tr><tr><td colspan="2" align="left" valign="top"><p>
The <code class="literal">"."</code> has an important meaning in the zone files.
If hostnames are given without a final <code class="literal">.</code>, the zone is
appended. Complete hostnames specified with a full domain name must end
with a <code class="literal">.</code> to avoid having the domain added to it
again. A missing or wrongly placed "." is probably the most frequent
cause of name server configuration errors.
</p></td></tr></table></div><p>
The first case to consider is the zone file
<code class="filename">example.com.zone</code>, responsible for the domain
<code class="filename">example.com</code>, shown in
<a class="xref" href="cha.dns.html#ex.welt.zone" title="Example 23.6. The /var/lib/named/example.com.zone File">Example 23.6, “The /var/lib/named/example.com.zone File”</a>.
</p><div class="example"><a name="ex.welt.zone"></a><p class="title"><b>Example 23.6. The /var/lib/named/example.com.zone File</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#ex.welt.zone">¶</a></span></p><div class="example-contents"><pre class="screen">1. $TTL 2D
2. example.com. IN SOA dns root.example.com. (
3. 2003072441 ; serial
4. 1D ; refresh
5. 2H ; retry
6. 1W ; expiry
7. 2D ) ; minimum
8.
9. IN NS dns
10. IN MX 10 mail
11.
12. gate IN A 192.168.5.1
13. IN A 10.0.0.1
14. dns IN A 192.168.1.116
15. mail IN A 192.168.3.108
16. jupiter IN A 192.168.2.100
17. venus IN A 192.168.2.101
18. saturn IN A 192.168.2.102
19. mercury IN A 192.168.2.103
20. ntp IN CNAME dns
21. dns6 IN A6 0 2002:c0a8:174::
</pre></div></div><br class="example-break"><div class="variablelist"><dl><dt><span class="term">Line 1:</span></dt><dd><p>
<code class="systemitem">$TTL</code> defines the default time to live that
should apply to all the entries in this file. In this example, entries
are valid for a period of two days (<code class="literal">2 D</code>).
</p></dd><dt><span class="term">Line 2:</span></dt><dd><p>
This is where the SOA (start of authority) control record begins:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
The name of the domain to administer is
<code class="literal">example.com</code> in the first position. This ends
with <code class="literal">"."</code>, because otherwise the zone would be
appended a second time. Alternatively, <code class="literal">@</code> can be
entered here, in which case the zone would be extracted from the
corresponding entry in <code class="filename">/etc/named.conf</code>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
After <code class="systemitem">IN SOA</code> is the name of the name server
in charge as master for this zone. The name is expanded from
<code class="literal">dns</code> to <code class="literal">dns.example.com</code>, because it
does not end with a <code class="literal">"."</code>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
An e-mail address of the person in charge of this name server
follows. Because the <code class="literal">@</code> sign already has a special
meaning, <code class="literal">"."</code> is entered here instead. For
<code class="systemitem">root@example.com</code> the entry must read
<code class="systemitem">root.example.com.</code>. The
<code class="literal">"."</code> must be included at the end to prevent the
zone from being added.
</p></li><li class="listitem" style="list-style-type: disc"><p>
The <code class="literal">(</code> includes all lines up to
<code class="literal">)</code> into the SOA record.
</p></li></ul></div></dd><dt><span class="term">Line 3:</span></dt><dd><p>
The <code class="systemitem">serial number</code> is an arbitrary number that
is increased each time this file is changed. It is needed to inform
the secondary name servers (slave servers) of changes. For this, a 10
digit number of the date and run number, written as YYYYMMDDNN, has
become the customary format.
</p></dd><dt><span class="term">Line 4:</span></dt><dd><p>
The <code class="systemitem">refresh rate</code> specifies the time interval
at which the secondary name servers verify the zone <code class="systemitem">serial
number</code>. In this case, one day.
</p></dd><dt><span class="term">Line 5:</span></dt><dd><p>
The <code class="systemitem">retry rate</code> specifies the time interval at
which a secondary name server, in case of error, attempts to contact
the primary server again. Here, two hours.
</p></dd><dt><span class="term">Line 6:</span></dt><dd><p>
The <code class="systemitem">expiration time</code> specifies the time frame
after which a secondary name server discards the cached data if it has
not regained contact to the primary server. Here, a week.
</p></dd><dt><span class="term">Line 7:</span></dt><dd><p>
The last entry in the SOA record specifies the <code class="systemitem">negative
caching TTL</code>—the time for which results of
unresolved DNS queries from other servers may be cached.
</p></dd><dt><span class="term">Line 9:</span></dt><dd><p>
The <code class="systemitem">IN NS</code> specifies the name server
responsible for this domain. <code class="systemitem">dns</code> is extended
to <code class="systemitem">dns.example.com</code> because it does not end with a
<code class="literal">"."</code>. There can be several lines like this—one
for the primary and one for each secondary name server. If
<code class="systemitem">notify</code> is not set to <code class="option">no</code> in
<code class="filename">/etc/named.conf</code>, all the name servers listed here
are informed of the changes made to the zone data.
</p></dd><dt><span class="term">Line 10:</span></dt><dd><p>
The MX record specifies the mail server that accepts, processes, and
forwards e-mails for the domain
<code class="systemitem">example.com</code>. In
this example, this is the host
<code class="systemitem">mail.example.com</code>. The number in
front of the hostname is the preference value. If there are multiple
MX entries, the mail server with the smallest value is taken first
and, if mail delivery to this server fails, an attempt is made with
the next higher value.
</p></dd><dt><span class="term">Lines 12–19:</span></dt><dd><p>
These are the actual address records where one or more IP addresses
are assigned to hostnames. The names are listed here without a
<code class="literal">"."</code> because they do not include their domain, so
<code class="systemitem">example.com</code> is added
to all of them. Two IP addresses are assigned to the host
<code class="systemitem">gate</code>, as it has two network cards.
Wherever the host address is a traditional one (IPv4), the record is
marked with <code class="literal">A</code>. If the address is an IPv6 address,
the entry is marked with <code class="literal">AAAA</code>.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note: IPv6 Syntax"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left">IPv6 Syntax</th></tr><tr><td colspan="2" align="left" valign="top"><p>
The IPv6 record has a slightly different syntax than IPv4. Because of
the fragmentation possibility, it is necessary to provide information
about missed bits before the address. To just fill up the IPv6
address with the needed number of <span class="quote">“<span class="quote">0</span>”</span>, add two colons at
the correct place in the address.
</p><pre class="screen">pluto AAAA 2345:00C1:CA11::1234:5678:9ABC:DEF0
pluto AAAA 2345:00D2:DA11::1234:5678:9ABC:DEF0</pre></td></tr></table></div></dd><dt><span class="term">Line 20:</span></dt><dd><p>
The alias <code class="literal">ntp</code> can be used to address
<code class="literal">dns</code> (<code class="systemitem">CNAME</code> means
<span class="emphasis"><em>canonical name</em></span>).
</p></dd></dl></div><p>
The pseudodomain <code class="literal">in-addr.arpa</code> is used for the reverse
lookup of IP addresses into hostnames. It is appended to the network part
of the address in reverse notation. So
<code class="systemitem">192.168</code> is resolved into
<code class="systemitem">168.192.in-addr.arpa</code>. See
<a class="xref" href="cha.dns.html#dat.arpa" title="Example 23.7. Reverse Lookup">Example 23.7, “Reverse Lookup”</a>. <a class="indexterm" name="id487687"></a>
</p><div class="example"><a name="dat.arpa"></a><p class="title"><b>Example 23.7. Reverse Lookup</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#dat.arpa">¶</a></span></p><div class="example-contents"><pre class="screen">1. $TTL 2D
2. 168.192.in-addr.arpa. IN SOA dns.example.com. root.example.com. (
3. 2003072441 ; serial
4. 1D ; refresh
5. 2H ; retry
6. 1W ; expiry
7. 2D ) ; minimum
8.
9. IN NS dns.example.com.
10.
11. 1.5 IN PTR gate.example.com.
12. 100.3 IN PTR www.example.com.
13. 253.2 IN PTR cups.example.com. </pre></div></div><br class="example-break"><div class="variablelist"><dl><dt><span class="term">Line 1:</span></dt><dd><p>
$TTL defines the standard TTL that applies to all entries here.
</p></dd><dt><span class="term">Line 2:</span></dt><dd><p>
The configuration file should activate reverse lookup for the network
<code class="systemitem">192.168</code>. Given
that the zone is called <code class="systemitem">168.192.in-addr.arpa</code>,
it should not be added to the hostnames. Therefore, all hostnames are
entered in their complete form—with their domain and with a
<code class="literal">"."</code> at the end. The remaining entries correspond to
those described for the previous
<code class="systemitem">example.com</code> example.
</p></dd><dt><span class="term">Lines 3–7:</span></dt><dd><p>
See the previous example for <code class="systemitem">example.com</code>.
</p></dd><dt><span class="term">Line 9:</span></dt><dd><p>
Again this line specifies the name server responsible for this zone.
This time, however, the name is entered in its complete form with the
domain and a <code class="literal">"."</code> at the end.
</p></dd><dt><span class="term">Lines 11–13:</span></dt><dd><p>
These are the pointer records hinting at the IP addresses on the
respective hosts. Only the last part of the IP address is entered at
the beginning of the line, without the <code class="literal">"."</code> at the
end. Appending the zone to this (without the
<code class="systemitem">.in-addr.arpa</code>) results in the complete IP
address in reverse order.
</p></dd></dl></div><p>
Normally, zone transfers between different versions of BIND should be
possible without any problem.
<a class="indexterm" name="id487842"></a>
<a class="indexterm" name="id487849"></a>
<a class="indexterm" name="id487856"></a>
</p></div><div class="sect1" title="23.7. Dynamic Update of Zone Data"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.dynupdate"></a>23.7. Dynamic Update of Zone Data<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.dynupdate">¶</a></span></h2></div></div></div><p>
The term <span class="emphasis"><em>dynamic update</em></span> refers to operations by
which entries in the zone files of a master server are added, changed, or
deleted. This mechanism is described in RFC 2136. Dynamic update is
configured individually for each zone entry by adding an optional
<code class="systemitem">allow-update</code> or
<code class="systemitem">update-policy</code> rule. Zones to update dynamically
should not be edited by hand.
</p><p>
Transmit the entries to update to the server with the command
<span class="command"><strong>nsupdate</strong></span>. For the exact syntax of this command, check
the manual page for nsupdate (<span class="command"><strong>man</strong></span> <code class="option">8
nsupdate</code>). For security reasons, any such update should be
performed using TSIG keys as described in <a class="xref" href="cha.dns.html#sec.dns.tsig" title="23.8. Secure Transactions">Section 23.8, “Secure Transactions”</a>.
</p></div><div class="sect1" title="23.8. Secure Transactions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.tsig"></a>23.8. Secure Transactions<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.tsig">¶</a></span></h2></div></div></div><p>
Secure transactions can be made with the help of transaction signatures
(TSIGs) based on shared secret keys (also called TSIG keys). This section
describes how to generate and use such keys.
</p><p>
Secure transactions are needed for communication between different
servers and for the dynamic update of zone data. Making the access
control dependent on keys is much more secure than merely relying on IP
addresses.
</p><p>
Generate a TSIG key with the following command (for details, see
<span class="command"><strong>man</strong></span> <code class="option">dnssec-keygen</code>):
</p><pre class="screen">dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2</pre><p>
This creates two files with names similar to these:
</p><pre class="screen">Khost1-host2.+157+34265.private Khost1-host2.+157+34265.key</pre><p>
The key itself (a string like
<code class="literal">ejIkuCyyGJwwuN3xAteKgg==</code>) is found in both files. To
use it for transactions, the second file
(<code class="filename">Khost1-host2.+157+34265.key</code>) must be transferred to
the remote host, preferably in a secure way (using scp, for example). On
the remote server, the key must be included in the
<code class="filename">/etc/named.conf</code> file to enable a secure
communication between <code class="literal">host1</code> and
<code class="literal">host2</code>:
</p><pre class="screen">key host1-host2 {
algorithm hmac-md5;
secret "ejIkuCyyGJwwuN3xAteKgg==";
};</pre><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning: File Permissions of /etc/named.conf"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left">File Permissions of <code class="filename">/etc/named.conf</code></th></tr><tr><td colspan="2" align="left" valign="top"><p>
Make sure that the permissions of <code class="filename">/etc/named.conf</code>
are properly restricted. The default for this file is
<code class="literal">0640</code>, with the owner being
<code class="systemitem">root</code> and the group
<code class="systemitem">named</code>. As an alternative, move
the keys to an extra file with specially limited permissions, which is
then included from <code class="filename">/etc/named.conf</code>. To include an
external file, use:
</p><pre class="screen">include "filename"</pre><p>
Replace <code class="option">filename</code> with an absolute path to your file
with keys.
</p></td></tr></table></div><p>
To enable the server <code class="literal">host1</code> to use the key for
<code class="literal">host2</code> (which has the address
<code class="literal">10.1.2.3</code> in this example), the server's
<code class="filename">/etc/named.conf</code> must include the following rule:
</p><pre class="screen">server 10.1.2.3 {
keys { host1-host2. ;};
};</pre><p>
Analogous entries must be included in the configuration files of
<code class="literal">host2</code>.
</p><p>
Add TSIG keys for any ACLs (access control lists, not to be confused with
file system ACLs) that are defined for IP addresses and address ranges to
enable transaction security. The corresponding entry could look like
this:
</p><pre class="screen">allow-update { key host1-host2. ;};</pre><p>
This topic is discussed in more detail in the <span class="emphasis"><em>BIND
Administrator Reference Manual</em></span> under
<code class="literal">update-policy</code>.
</p></div><div class="sect1" title="23.9. DNS Security"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.dnssec"></a>23.9. DNS Security<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.dnssec">¶</a></span></h2></div></div></div><p>
DNSSEC, or DNS security, is described in RFC 2535. The tools
available for DNSSEC are discussed in the BIND Manual.
</p><p>
A zone considered secure must have one or several zone keys associated
with it. These are generated with <span class="command"><strong>dnssec-keygen</strong></span>, just
like the host keys. The DSA encryption algorithm is currently used to
generate these keys. The public keys generated should be included in the
corresponding zone file with an <code class="systemitem">$INCLUDE</code> rule.
</p><p>
With the command <span class="command"><strong>dnssec-makekeyset</strong></span>, all keys generated
are packaged into one set, which must then be transferred to the parent
zone in a secure manner. On the parent, the set is signed with
<span class="command"><strong>dnssec-signkey</strong></span>. The files generated by this command
are then used to sign the zones with <span class="command"><strong>dnssec-signzone</strong></span>,
which in turn generates the files to include for each zone in
<code class="filename">/etc/named.conf</code>.
</p></div><div class="sect1" title="23.10. For More Information"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.dns.info"></a>23.10. For More Information<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.dns.info">¶</a></span></h2></div></div></div><p>
For additional information, refer to the <span class="emphasis"><em>BIND Administrator
Reference Manual</em></span> from package
<code class="systemitem">bind-doc</code>, which is installed
under <code class="filename">/usr/share/doc/packages/bind/</code>. Consider
additionally consulting the RFCs referenced by the manual and the manual
pages included with BIND.
<code class="filename">/usr/share/doc/packages/bind/README.SuSE</code> contains
up-to-date information about BIND in openSUSE.
</p></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.opensuse.reference.html">Reference</a><span class="breadcrumbs-sep"> > </span><a href="part.reference.services.html">Services</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 22. SLP Services in the Network" href="cha.slp.html"><span>◀</span></a> <a accesskey="n" title="Chapter 24. DHCP" href="cha.dhcp.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018