6. Features¶
6.1. Resolver¶
6.1.1. Smoothed round-trip time computation¶
The Loop resolver maintains a smoothed round-trip time (SRTT) for every nameserver address in the ADB. The SRTT is used to select the next nameserver to contact when there are multiple nameservers available.
It is initialized and updated during a fetch operation as follows:
Initially the SRTT to a nameserver address is set to a random value between [0, 31] microseconds, so that the nameserver can be tried in some random order as no RTT is currently known for that address.
Whenever a response is received from a nameserver address, an RTT from that roundtrip is available to Loop. The SRTT for that nameserver address is updated as 7/10ths of the old SRTT plus 3/10ths of the RTT of the response. Hence the term "smoothed".
Whenever a request to a nameserver address ends in timeout and there's no response, the RTT for that request is not available. In this case:
In the case of EDNS queries for which no EDNS response has been received from that address previously, the SRTT is not updated, as the response may not have been received due to improper support for EDNS and not actual network conditions.
In all other cases, the SRTT for that nameserver address is increased as follows, and then clamped to a maximum of the maximum single query timeout value which is 9 seconds:
If the existing SRTT value is greater than 800000 microseconds, increase by a random value in the interval [0, 16383] microseconds.
If the existing SRTT value is in the half-open interval (400000, 800000] microseconds, increase by a random value in the interval [0, 32767] microseconds.
If the existing SRTT value is in the half-open interval (200000, 400000] microseconds, increase by a random value in the interval [0, 65535] microseconds.
If the existing SRTT value is in the half-open interval (100000, 200000] microseconds, increase by a random value in the interval [0, 131071] microseconds.
If the existing SRTT value is in the half-open interval (50000, 100000] microseconds, increase by a random value in the interval [0, 262143] microseconds.
If the existing SRTT value is in the half-open interval (25000, 50000] microseconds, increase by a random value in the interval [0, 524287] microseconds.
If the existing SRTT value is less than or equal to 25000 microseconds, increase by a random value in the interval [0, 1048575] microseconds.
For all other nameservers in that fetch that were not contacted, and that are not marked as bad or marked for some other reason, their SRTTs are aged by multiplying them with a factor 511/512 using integer arithmetic (~0.998046875) which lowers their SRTT slightly.
6.1.2. Nameserver selection¶
For nameserver selection, Loop initially tries to gather a variety of nameserver addresses to be used with the fetch depending on the view configuration and the nameservers for the current zonecut. Some of these are skipped if they are known to be bad. The lists may not be necessarily complete too depending on what addresses are known currently. Finally, the lists of nameserver addresses that we have are sorted by their SRTT values to pick the order in which they're contacted.
Error
TODO: This has to be described in more detail.
6.2. DNS NOTIFY¶
DNS NOTIFY (see RFC 1996) is a mechanism that allows master servers
to notify their slave servers of changes to a zone's data. When a slave
receives a NOTIFY message from a master server, it will check to see
that its version of the zone is the current version and, if not,
initiate a zone transfer.
For more information about DNS NOTIFY, see the description of the
notify option in section_title and the
description of the zone option also-notify in
section_title. The NOTIFY protocol is
specified in RFC 1996.
Note
As a slave zone can also be a master to other slaves, named, by
default, sends DNS NOTIFY messages for every zone it loads.
Specifying notify master-only will cause named to only send
NOTIFY for master zones that it loads.
6.3. DNS UPDATE (dynamic updates)¶
DNS UPDATE (see RFC 2136) is a method for adding, replacing or deleting records in a master server by sending it a special form of DNS messages. This method is also referred to as dynamic update.
Dynamic update is enabled by including an allow-update or an
update-policy clause in the zone statement.
If the zone's update-policy is set to local, updates to the zone
will be permitted for the key local-ddns, which will be generated by
named at startup. See section_title
for more details.
Dynamic updates using Kerberos signed requests can be made using the
TKEY/GSS protocol by setting either the tkey-gssapi-keytab option,
or alternatively by setting both the tkey-gssapi-credential and
tkey-domain options. Once enabled, Kerberos signed requests will be
matched against the update policies for the zone, using the Kerberos
principal as the signer for the request.
Updating of secure zones (zones using DNSSEC) follows RFC 3007: RRSIG, NSEC and NSEC3 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.
6.3.1. Journal files¶
All changes made to a zone using dynamic update are stored in the zone's
journal file. This file is automatically created by the server when the
first dynamic update takes place. The name of the journal file is formed
by appending the extension .jnl to the name of the corresponding
zone file unless specifically overridden. The journal file is in a
binary format and should not be edited manually.
The server will also occasionally write ("dump") the complete contents
of the updated zone to its zone file. This is not done immediately after
each dynamic update, because that would be too slow when a large zone is
updated frequently. Instead, the dump is delayed by up to 15 minutes,
allowing additional updates to take place. During the dump process,
transient files will be created with the extensions .jnw and
.jbk; under ordinary circumstances, these will be removed when the
dump is complete, and can be safely ignored.
When a server is restarted after a shutdown or crash, it will replay the journal file to incorporate into the zone any updates that took place after the last zone dump.
Changes that result from incoming incremental zone transfers are also journalled in a similar way.
The zone files of dynamic zones cannot normally be edited by hand
because they are not guaranteed to contain the most recent dynamic
changes — those are only in the journal file. The only way to ensure
that the zone file of a dynamic zone is up to date is to run
rndc stop.
If you have to make changes to a dynamic zone manually, the following
procedure will work: Disable dynamic updates to the zone using
rndc freeze zone. This will update the zone's master file with the
changes stored in its .jnl file. Edit the zone file. Run
rndc thaw zone to reload the changed zone and re-enable dynamic
updates.
rndc sync zone will update the zone file with changes from the
journal file without stopping dynamic updates; this may be useful for
viewing the current zone state. To remove the .jnl file after
updating the zone file, use rndc sync -clean.
6.4. IXFR (incremental zone transfers)¶
The incremental zone transfer (IXFR) protocol (see RFC 1995) is a way for slave servers to transfer only changed data, instead of having to transfer the entire zone.
When acting as a master, Loop supports IXFR for those zones where the
necessary change history information is available. These include master
zones maintained by dynamic update and slave zones whose data was
obtained by IXFR. For manually maintained master zones, and for slave
zones obtained by performing a full zone transfer (AXFR), IXFR is
supported only if the option ixfr-from-differences is set to
yes.
When acting as a slave, Loop will attempt to use IXFR unless it is
explicitly disabled. For more information about disabling IXFR, see the
description of the request-ixfr clause of the server statement.
6.5. Split DNS¶
Setting up different views, or visibility, of the DNS space to internal and external resolvers is usually referred to as a Split DNS setup. There are several reasons an organization would want to set up its DNS this way.
One common reason for setting up a DNS system this way is to hide "internal" DNS information from "external" clients on the Internet. There is some debate as to whether or not this is actually useful. Internal DNS information leaks out in many ways (via email headers, for example) and most savvy "attackers" can find the information they need using other means. However, since listing addresses of internal servers that external clients cannot possibly reach can result in connection delays and other annoyances, an organization may choose to use a Split DNS to present a consistent view of itself to the outside world.
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.
6.5.1. Example split DNS setup¶
Let's say a company named Example, Inc. (example.com) has several
corporate sites that have an internal network with reserved Internet
Protocol (IP) space and an external demilitarized zone (DMZ), or
"outside" section of a network, that is available to the public.
Example, Inc. wants its internal clients to be able to resolve external hostnames and to exchange mail with people on the outside. The company also wants its internal resolvers to have access to certain internal-only zones that are not available at all outside of the internal network.
In order to accomplish this, the company will set up two sets of name servers. One set will be on the inside network (in the reserved IP space) and the other set will be on bastion hosts, which are "proxy" hosts that can talk to both sides of its network, in the DMZ.
The internal servers will be configured to forward all queries, except
queries for site1.internal, site2.internal,
site1.example.com, and site2.example.com, to the servers in the
DMZ. These internal servers will have complete sets of information for
site1.example.com, site2.example.com, site1.internal, and
site2.internal.
To protect the site1.internal and site2.internal domains, the
internal name servers must be configured to disallow all queries to
these domains from any external hosts, including the bastion hosts.
The external servers, which are on the bastion hosts, will be configured
to serve the "public" version of the site1 and site2.example.com
zones. This could include things such as the host records for public
servers (www.example.com and ftp.example.com), and mail exchange
(MX) records (a.mx.example.com and b.mx.example.com).
In addition, the public site1 and site2.example.com 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.
Here's an example of a wildcard MX record:
* IN MX 10 external1.example.com.
Now that they accept mail on behalf of anything in the internal network, the bastion hosts will need to know how to deliver mail to internal hosts. In order for this to work properly, the resolvers on the bastion hosts will need to be configured to point to the internal name servers for DNS resolution.
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.
In order for all this to work properly, internal clients will need to be configured to query only the internal name servers for DNS queries. This could also be enforced via selective filtering on the network.
If everything has been set properly, Example, Inc.'s internal clients will now be able to:
Look up any hostnames in the
site1andsite2.example.comzones.Look up any hostnames in the
site1.internalandsite2.internaldomains.Look up any hostnames on the Internet.
Exchange mail with both internal and external people.
Hosts on the Internet will be able to:
Look up any hostnames in the
site1andsite2.example.comzones.Exchange mail with anyone in the
site1andsite2.example.comzones.
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 section_title.
Internal DNS server config:
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
acl externals { bastion-ips-go-here; };
options {
...
...
forward only;
// forward to external servers
forwarders {
bastion-ips-go-here;
};
// sample allow-transfer (no one)
allow-transfer { none; };
// restrict query access
allow-query { internals; externals; };
// restrict recursion
allow-recursion { internals; };
...
...
};
// sample master zone
zone "site1.example.com" {
type master;
file "m/site1.example.com";
// do normal iterative resolution (do not forward)
forwarders { };
allow-query { internals; externals; };
allow-transfer { internals; };
};
// sample slave zone
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; }
};
External (bastion host) DNS server config:
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
acl externals { bastion-ips-go-here; };
options {
...
...
// sample allow-transfer (no one)
allow-transfer { none; };
// default query access
allow-query { any; };
// restrict cache access
allow-query-cache { internals; externals; };
// restrict recursion
allow-recursion { internals; externals; };
...
...
};
// sample slave zone
zone "site1.example.com" {
type master;
file "m/site1.foo.com";
allow-transfer { internals; externals; };
};
zone "site2.example.com" {
type slave;
file "s/site2.foo.com";
masters { another_bastion_host_maybe; };
allow-transfer { internals; externals; }
};
In the resolv.conf (or equivalent) on the bastion host(s):
search ...
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4
6.5.2. Example split DNS setup 2¶
Here is an example of a typical split DNS setup implemented using
view statements:
view "internal" {
// This should match our internal networks.
match-clients { 10.0.0.0/8; };
// Provide recursive service to internal
// clients only.
recursion yes;
// Provide a complete view of the example.com
// zone including addresses of internal hosts.
zone "example.com" {
type master;
file "example-internal.db";
};
};
view "external" {
// Match all clients not matched by the
// previous view.
match-clients { any; };
// Refuse recursive service to external clients.
recursion no;
// Provide a restricted view of the example.com
// zone containing only publicly accessible hosts.
zone "example.com" {
type master;
file "example-external.db";
};
};
6.6. TSIG (transaction signatures)¶
TSIG (originally specified in RFC 2845, extended in RFC 4635, and revised in RFC 8945) is a mechanism for authenticating DNS messages between two parties by cryptographically signing them using HMACs (RFC 2104). TSIG can be used in any DNS transaction as a way to restrict access to certain nameserver functions (e.g., recursive queries) only to authorized clients, when IP-based access control is insufficient or needs to be overridden, or as a way to ensure message authenticity when it is critical to the integrity of data, such as with DNS UPDATE messages or zone transfers from a primary to a secondary nameserver.
This is a guide to setting up TSIG in Loop. It describes the configuration syntax and the process of creating TSIG keys.
named supports TSIG for server-to-server communication, and some of the tools included with Loop support TSIG for sending messages to named:
dig supports TSIG via the
-kand-ycommand line options.nsupdate supports TSIG via the
-k,-l, and-ycommand line options, or via thekeycommand when running interactively.
6.6.2. Loading a new key¶
For a key shared between servers called host1 and host2, the
following could be added to each server's named.conf file:
key "host1-host2." {
algorithm hmac-sha256;
secret "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY=";
};
(This is the same key generated above using ddns-confgen.)
Since this text contains a secret, it is recommended that either
named.conf not be world-readable, or that the key directive be
stored in a file which is not world-readable, and which is included in
named.conf via the include directive.
Once a key has been added to named.conf and the server has been
restarted or reconfigured, the server can recognize the key. If the
server receives a message signed by the key, it will be able to verify
the signature. If the signature is valid, the response will be signed
using the same key.
TSIG keys that are known to a server can be listed using the command
rndc tsig-list.
6.6.3. Instructing the server to use a key¶
A server sending a request to another server must be told whether to use a key, and if so, which key to use.
For example, a key may be specified for each server in the masters
statement in the definition of a slave zone; in this case, all SOA QUERY
messages, NOTIFY messages, and zone transfer requests (AXFR or IXFR)
will be signed using the specified key. Keys may also be specified in
the also-notify statement of a master or slave zone, causing NOTIFY
messages to be signed using the specified key.
Keys can also be specified in a server directive. Adding the
following on host1, if the IP address of host2 is 10.1.2.3, would
cause all requests from host1 to host2, including normal DNS
queries, to be signed using the host1-host2. key:
server 10.1.2.3 {
keys { host1-host2. ;};
};
Multiple keys may be present in the keys statement, but only the
first one is used. As this directive does not contain secrets, it can be
used in a world-readable file.
Requests sent by host2 to host1 would not be signed, unless a
similar server directive were in host2's configuration file.
Whenever any server sends a TSIG-signed DNS request, it will expect the response to be signed with the same key. If a response is not signed, or if the signature is not valid, the response will be rejected.
6.6.4. TSIG-based access control¶
TSIG keys may be specified in ACL definitions and ACL directives such as
allow-query, allow-transfer and allow-update. The above key
would be denoted in an ACL element as key host1-host2.
An example of an allow-update directive using a TSIG key:
allow-update { !{ !localnets; any; }; key host1-host2. ;};
This allows dynamic updates to succeed only if the UPDATE request comes
from an address in localnets, and if it is signed using the
host1-host2. key.
See section_title for a discussion of the
more flexible update-policy statement.
6.6.5. TSIG errors¶
Processing of TSIG-signed messages can result in several kinds of errors:
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 from a known key but with an invalid signature, 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 all of the above cases, the server will return a response code of NOTAUTH (not authenticated).
6.7. TKEY (transaction keys)¶
TKEY (originally specified in RFC 2930) is a mechanism for automatically negotiating a TSIG shared secret between two hosts.
There are several TKEY "modes" that specify how a key is to be generated or assigned. Loop implements only one of these modes: Diffie-Hellman key exchange. Both hosts are required to have a KEY record with algorithm DH (though this record is not required to be present in a zone).
The TKEY process is initiated by a client or server by sending a query of type TKEY to a TKEY-aware server. The query must include an appropriate KEY record in the additional section, and must be signed using either TSIG or SIG(0) with a previously established key. The server's response, if successful, will contain a TKEY record in its answer section. After this transaction, both participants will have enough information to calculate a shared secret using Diffie-Hellman key exchange. The shared secret can then be used by to sign subsequent transactions between the two servers.
TSIG keys known by the server, including TKEY-negotiated keys, can be
listed using rndc tsig-list.
TKEY-negotiated keys can be deleted from a server using
rndc tsig-delete. This can also be done via the TKEY protocol
itself, by sending an authenticated TKEY query specifying the "key
deletion" mode.
Whenever named is shutdown, for each view it dumps keyrings
containing dynamically negotiated keys to a file respectively; the
filename will be the view name followed by the suffix
.tsigkeys. Whenever named is restarted, it attempts to
restore any dumped keyrings from previous invocations of
named.
Error
TODO: This should be replaced with the hashed filename mechanism.
6.8. SIG(0)¶
Loop partially supports SIG(0) transaction signatures as specified in RFC 2535 and RFC 2931. 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 in ACL directives based on the key name.
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 recursively fetch or validate the key.
SIG(0) signing of multiple-message TCP streams is not supported.
nsupdate is the only program shipped with Loop that generates SIG(0) signed messages.
6.9. DNSSEC¶
Cryptographic authentication of DNS information is possible through the DNS Security (DNSSEC-bis) extensions, defined in RFC 4033, RFC 4034, and RFC 4035. This section describes the creation and use of DNSSEC signed zones.
In order to set up a DNSSEC secure zone, there are a series of steps
which must be followed. Loop ships with several tools that are used in
this process, which are explained in more detail below. In all cases,
the -h option prints a full list of parameters. Note that the DNSSEC
tools require the keyset files to be in the working directory or the
directory specified by the -d option.
There must also be communication with the administrators of the parent
and/or child zone to transmit keys. A zone's security status must be
indicated by the parent zone for a DNSSEC capable resolver to trust its
data. This is done through the presence or absence of a DS record at
the delegation point.
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.
6.9.1. Generating Keys¶
The dnssec-keygen program is used to generate keys.
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 ZONE, and must be usable for authentication. It is
recommended that zone keys use a cryptographic algorithm designated as
"mandatory to implement" by the IETF; currently the only one is RSASHA1.
The following command will generate a 768-bit RSASHA1 key for the
child.example zone:
dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.
Two output files will be produced: Kchild.example.+005+12345.key and
Kchild.example.+005+12345.private (where 12345 is an example of a
key tag). The key filenames contain the key name (child.example.),
algorithm (3 is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag
(12345 in this case). The private key (in the .private file) is used
to generate signatures, and the public key (in the .key file) is
used for signature verification.
To generate another key with the same properties (but with a different key tag), repeat the above command.
The dnssec-keyfromlabel program is used to get a key pair from a
crypto hardware and build the key files. Its usage is similar to
dnssec-keygen.
The public keys should be inserted into the zone file by including the
.key files using $INCLUDE statements.
6.9.2. Signing the Zone¶
The dnssec-signzone program is used to sign a zone.
Any keyset files corresponding to secure subzones should be present.
The zone signer will generate NSEC, NSEC3 and RRSIG records
for the zone, as well as DS for the child zones if '-g' is
specified. If '-g' is not specified, then DS RRsets for the secure
child zones need to be added manually.
The following command signs the zone, assuming it is in a file called
zone.child.example. By default, all zone keys which have an
available private key are used to generate signatures.
dnssec-signzone -o child.example zone.child.example
One output file is produced: zone.child.example.signed. This file
should be referenced by named.conf as the input file for the zone.
dnssec-signzone will also produce a keyset and dsset files and
optionally a dlvset file. These are used to provide the parent zone
administrators with the DNSKEYs (or their corresponding DS
records) that are the secure entry point to the zone.
6.9.3. Configuring Servers¶
To enable named to respond appropriately to DNS requests from DNSSEC
aware clients, dnssec-enable must be set to yes. (This is the
default setting.)
To enable named to validate answers from other servers, the
dnssec-enable option must be set to yes, and the
dnssec-validation options must be set to yes or auto.
If dnssec-validation is set to auto, then a default trust anchor
for the DNS root zone will be used. If it is set to yes, however,
then at least one trust anchor must be configured with a
trusted-keys or managed-keys statement in named.conf, or
DNSSEC validation will not occur. The default setting is yes.
trusted-keys are copies of DNSKEY RRs for zones that are used to
form the first link in the cryptographic chain of trust. All keys listed
in trusted-keys (and corresponding zones) are deemed to exist and
only the listed keys will be used to validated the DNSKEY RRset that
they are from.
managed-keys are trusted keys which are automatically kept up to
date via RFC 5011 trust anchor maintenance.
trusted-keys and managed-keys are described in more detail later
in this document.
Loop does not verify signatures on load, so zone keys for authoritative zones do not need to be specified in the configuration file.
After DNSSEC gets established, a typical DNSSEC configuration will look
something like the following. It has one or more public keys for the
root. This allows answers from outside the organization to be validated.
It will also have several keys for parts of the namespace the
organization controls. These are here to ensure that named is immune
to compromises in the DNSSEC components of the security of parent zones.
managed-keys {
/* Root Key */
"." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh
aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy
4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg
hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp
5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke
g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq
66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ
dgxbcDTClU0CRBdiieyLMNzXG3";
};
trusted-keys {
/* Key for our organization's forward zone */
example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6
5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z
GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb
4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL
kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O
g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S
TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq
FxmAVZP20igTixin/1LcrgX/KMEGd/biuv
F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm
/oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o
1OTQ09A0=";
/* Key for our reverse zone. */
2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc
xOdNax071L18QqZnQQQAVVr+i
LhGTnNGp3HoWQLUIzKrJVZ3zg
gy3WwNT6kZo6c0tszYqbtvchm
gQC8CzKojM/W16i6MG/eafGU3
siaOdS0yOI6BgPsw+YZdzlYMa
IJGf4M4dyoKIhzdZyQ2bYQrjy
Q4LB0lC7aOnsMyYKHHYeRvPxj
IQXmdqgOJGq+vsevG06zW+1xg
YJh9rCIfnm1GX/KMgxLPG2vXT
D/RnLX+D3T3UL7HJYHJhAZD5L
59VvjSPsZJHeDCUyWYrvPZesZ
DIRvhDD52SKvbheeTJUm6Ehkz
ytNN2SN96QRk8j/iI8ib";
};
options {
...
dnssec-enable yes;
dnssec-validation yes;
};
Note
None of the keys listed in this example are valid. In particular, the root key is not valid.
When DNSSEC validation is enabled and properly configured, the resolver will reject any answers from signed, secure zones which fail to validate, and will return SERVFAIL to the client.
Responses may fail to validate for any of several reasons, including missing, expired, or invalid signatures, a key which does not match the DS RRset in the parent zone, or an insecure response from a zone which, according to its parent, should have been secure.
Note
When the validator receives a response from an unsigned zone that has a signed parent, it must confirm with the parent that the zone was intentionally left unsigned. It does this by verifying, via signed and validated NSEC/NSEC3 records, that the parent zone contains no DS records for the child.
If the validator can prove that the zone is insecure, then the response is accepted. However, if it cannot, then it must assume an insecure response to be a forgery; it rejects the response and logs an error.
The logged error reads "insecurity proof failed" and "got insecure response; parent indicates it should be secure".
6.10. DNSSEC, Dynamic Zones, and Automatic Signing¶
6.10.1. Converting from insecure to secure¶
Changing a zone from insecure to secure can be done in two ways: using a
dynamic DNS update, or the auto-dnssec zone option.
For either method, you need to configure named so that it can see
the K* files which contain the public and private parts of the keys
that will be used to sign the zone. These files will have been generated
by dnssec-keygen. You can do this by placing them in the
key-directory, as specified in named.conf:
zone example.net {
type master;
update-policy local;
file "dynamic/example.net/example.net";
key-directory "dynamic/example.net";
};
If one KSK and one ZSK DNSKEY key have been generated, this configuration will cause all records in the zone to be signed with the ZSK, and the DNSKEY RRset to be signed with the KSK as well. An NSEC chain will be generated as part of the initial signing process.
6.10.2. Dynamic DNS update method¶
To insert the keys via dynamic update:
% nsupdate
> ttl 3600
> update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfBfL8eQ8al35zz3Y I1m/SAQBxIqMfLtIwqWPdgthsu36azGQAX8=
> update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
> send
While the update request will complete almost immediately, the zone will
not be completely signed until named has had time to walk the zone
and generate the NSEC and RRSIG records. The NSEC record at the apex
will be added last, to signal that there is a complete NSEC chain.
If you wish to sign using NSEC3 instead of NSEC, you should add an NSEC3PARAM record to the initial update request. If you wish the NSEC3 chain to have the OPTOUT bit set, set it in the flags field of the NSEC3PARAM record.
% nsupdate
> ttl 3600
> update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfBfL8eQ8al35zz3Y I1m/SAQBxIqMfLtIwqWPdgthsu36azGQAX8=
> update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
> update add example.net NSEC3PARAM 1 1 100 1234567890
> send
Again, this update request will complete almost immediately; however,
the record won't show up until named has had a chance to
build/remove the relevant chain. A private type record will be created
to record the state of the operation (see below for more details), and
will be removed once the operation completes.
While the initial signing and NSEC/NSEC3 chain generation is happening, other updates are possible as well.
6.10.3. Fully automatic zone signing¶
To enable automatic signing, add the auto-dnssec option to the zone
statement in named.conf. auto-dnssec has two possible arguments:
allow or maintain.
With auto-dnssec allow, named can search the key directory for
keys matching the zone, insert them into the zone, and use them to sign
the zone. It will do so only when it receives an
rndc sign <zonename>.
auto-dnssec maintain includes the above functionality, but will also
automatically adjust the zone's DNSKEY records on schedule according to
the keys' timing metadata. (See ??? and
??? for more information.)
named will periodically search the key directory for keys matching
the zone, and if the keys' metadata indicates that any change should be
made the zone, such as adding, removing, or revoking a key, then that
action will be carried out. By default, the key directory is checked for
changes every 60 minutes; this period can be adjusted with the
dnssec-loadkeys-interval, up to a maximum of 24 hours. The
rndc loadkeys forces named to check for key updates immediately.
If keys are present in the key directory the first time the zone is
loaded, the zone will be signed immediately, without waiting for an
rndc sign or rndc loadkeys command. (Those commands can still be
used when there are unscheduled key changes, however.)
When new keys are added to a zone, the TTL is set to match that of any
existing DNSKEY RRset. If there is no existing DNSKEY RRset, then the
TTL will be set to the TTL specified when the key was created (using the
dnssec-keygen -L option), if any, or to the SOA TTL.
If you wish the zone to be signed using NSEC3 instead of NSEC, submit an NSEC3PARAM record via dynamic update prior to the scheduled publication and activation of the keys. If you wish the NSEC3 chain to have the OPTOUT bit set, set it in the flags field of the NSEC3PARAM record. The NSEC3PARAM record will not appear in the zone immediately, but it will be stored for later reference. When the zone is signed and the NSEC3 chain is completed, the NSEC3PARAM record will appear in the zone.
Using the auto-dnssec option requires the zone to be configured to
allow dynamic updates, by adding an allow-update or
update-policy statement to the zone configuration. If this has not
been done, the configuration will fail.
6.10.4. Private-type records¶
The state of the signing process is signaled by private-type records (with a default type value of 65534). When signing is complete, these records will have a nonzero value for the final octet (for those records which have a nonzero initial octet).
The private type record format: If the first octet is non-zero then the record indicates that the zone needs to be signed with the key matching the record, or that all signatures that match the record should be removed.
algorithm (octet 1) key id in network order (octet 2 and 3) removal flag (octet 4) complete flag (octet 5)
Only records flagged as "complete" can be removed via dynamic update. Attempts to remove other private type records will be silently ignored.
If the first octet is zero (this is a reserved algorithm number that should never appear in a DNSKEY record) then the record indicates changes to the NSEC3 chains are in progress. The rest of the record contains an NSEC3PARAM record. The flag field tells what operation to perform based on the flag bits.
0x01 OPTOUT 0x80 CREATE 0x40 REMOVE 0x20 NONSEC
6.10.5. DNSKEY rollovers¶
As with insecure-to-secure conversions, rolling DNSSEC keys can be done
in two ways: using a dynamic DNS update, or the auto-dnssec zone
option.
6.10.6. Dynamic DNS update method¶
To perform key rollovers via dynamic update, you need to add the K*
files for the new keys so that named can find them. You can then add
the new DNSKEY RRs via dynamic update. named will then cause the
zone to be signed with the new keys. When the signing is complete the
private type records will be updated so that the last octet is non zero.
If this is for a KSK you need to inform the parent and any trust anchor repositories of the new KSK.
You should then wait for the maximum TTL in the zone before removing the old DNSKEY. If it is a KSK that is being updated, you also need to wait for the DS RRset in the parent to be updated and its TTL to expire. This ensures that all clients will be able to verify at least one signature when you remove the old DNSKEY.
The old DNSKEY can be removed via UPDATE. Take care to specify the
correct key. named will clean out any signatures generated by the
old key after the update completes.
6.10.7. Automatic key rollovers¶
When a new key reaches its activation date (as set by dnssec-keygen
or dnssec-settime), if the auto-dnssec zone option is set to
maintain, named will automatically carry out the key rollover.
If the key's algorithm has not previously been used to sign the zone,
then the zone will be fully signed as quickly as possible. However, if
the new key is replacing an existing key of the same algorithm, then the
zone will be re-signed incrementally, with signatures from the old key
being replaced with signatures from the new key as their signature
validity periods expire. By default, this rollover completes in 30 days,
after which it will be safe to remove the old key from the DNSKEY RRset.
6.10.8. NSEC3PARAM rollovers via UPDATE¶
Add the new NSEC3PARAM record via dynamic update. When the new NSEC3 chain has been generated, the NSEC3PARAM flag field will be zero. At this point you can remove the old NSEC3PARAM record. The old chain will be removed after the update request completes.
6.10.9. Converting from NSEC to NSEC3¶
To do this, you just need to add an NSEC3PARAM record. When the conversion is complete, the NSEC chain will have been removed and the NSEC3PARAM record will have a zero flag field. The NSEC3 chain will be generated before the NSEC chain is destroyed.
6.10.10. Converting from NSEC3 to NSEC¶
To do this, use nsupdate to remove all NSEC3PARAM records with a
zero flag field. The NSEC chain will be generated before the NSEC3 chain
is removed.
6.10.11. Converting from secure to insecure¶
To convert a signed zone to unsigned using dynamic DNS, delete all the
DNSKEY records from the zone apex using nsupdate. All signatures,
NSEC or NSEC3 chains, and associated NSEC3PARAM records will be removed
automatically. This will take place after the update request completes.
This requires the dnssec-secure-to-insecure option to be set to
yes in named.conf.
In addition, if the auto-dnssec maintain zone statement is used, it
should be removed or changed to allow instead (or it will re-sign).
6.10.12. Periodic re-signing¶
In any secure zone which supports dynamic updates, named will periodically re-sign RRsets which have not been re-signed as a result of some update action. The signature lifetimes will be adjusted so as to spread the re-sign load over time rather than all at once.
6.10.13. NSEC3 and OPTOUT¶
named only supports creating new NSEC3 chains where all the NSEC3
records in the zone have the same OPTOUT state. named supports
UPDATES to zones where the NSEC3 records in the chain have mixed OPTOUT
state. named does not support changing the OPTOUT state of an
individual NSEC3 record, the entire chain needs to be changed if the
OPTOUT state of an individual NSEC3 needs to be changed.
6.11. Dynamic Trust Anchor Management¶
Loop is able to maintain DNSSEC trust anchors using RFC 5011 key
management. This feature allows named to keep track of changes to
critical DNSSEC keys without any need for the operator to make changes
to configuration files.
6.11.1. Validating Resolver¶
To configure a validating resolver to use RFC 5011 to maintain a trust
anchor, configure the trust anchor using a managed-keys statement.
Information about this can be found in ???.
6.12. PKCS#11¶
PKCS#11 (Public Key Cryptography Standard #11) defines a platform-independent API for the control of hardware security modules (HSMs) and other cryptographic support devices.
PKCS#11 makes use of a "provider library": a dynamically loadable library which provides a low-level PKCS#11 interface to drive the HSM hardware. The PKCS#11 provider library comes from the HSM vendor, and it is specific to the HSM to be controlled.
Loop provides OpenSSL-based PKCS#11, which loads the provider library and operates the HSM indirectly; any cryptographic operations not supported by the HSM can be carried out by OpenSSL instead.
6.13. IPv6¶
Loop 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.
For forward lookups, Loop supports only AAAA records. RFC 3363 deprecated the use of A6 records, and client-side support for A6 records is not present in Loop. However, authoritative Loop name servers still load zone files containing A6 records correctly, answer queries for A6 records, and accept zone transfer for a zone containing A6 records.
For IPv6 reverse lookups, Loop supports the traditional "nibble" format used in the ip6.arpa domain, as well as the older, deprecated ip6.int domain. Per RFC 3363, there is no support for "binary labels" (also known as "bitstring") format. In particular, an authoritative Loop name server will not load a zone file containing binary labels.
For an overview of the format and structure of IPv6 addresses, see section_title.
6.13.1. Address Lookups Using AAAA Records¶
The IPv6 AAAA record is a parallel to the IPv4 A record, and, unlike the deprecated A6 record, specifies the entire IPv6 address in a single record. For example,
$ORIGIN example.com.
host 3600 IN AAAA 2001:db8::1
Use of IPv4-in-IPv6 mapped addresses is not recommended. If a host has
an IPv4 address, use an A record, not a AAAA, with
::ffff:192.168.42.1 as the address.
6.13.2. Address to Name Lookups Using Nibble Format¶
When looking up an address in nibble format, the address components are
simply reversed, just as in IPv4, and ip6.arpa. is appended to the
resulting name. For example, the following would provide reverse name
lookup for a host with address 2001:db8::1.
$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR (
host.example.com. )
6.14. Empty zones¶
named has some built-in "empty" zones containing SOA and NS records only. These are for zones that should normally be answered locally and which queries should not be sent to the internet. The official servers which cover these namespaces return NXDOMAIN responses to these queries. In particular, these cover the reverse namespaces for addresses from RFC 1918, RFC 3849, RFC 4193, RFC 5735, RFC 5737, RFC 6598, RFC 7534, and RFC 8375. They also include the reverse namespace for IPv6 local address (locally assigned), IPv6 link local addresses, the IPv6 loopback address, and the IPv6 unknown address. The IANA IPv4 Special-Purpose Address Registry and the IANA IPv6 Special-Purpose Address Registry now track all special-purpose address blocks.
named will attempt to determine if a built-in zone already exists or is active (covered by a forward-only forwarding declaration) and will not create an empty zone in that case.
The current list of empty zones is:
10.IN-ADDR.ARPA
16.172.IN-ADDR.ARPA
17.172.IN-ADDR.ARPA
18.172.IN-ADDR.ARPA
19.172.IN-ADDR.ARPA
20.172.IN-ADDR.ARPA
21.172.IN-ADDR.ARPA
22.172.IN-ADDR.ARPA
23.172.IN-ADDR.ARPA
24.172.IN-ADDR.ARPA
25.172.IN-ADDR.ARPA
26.172.IN-ADDR.ARPA
27.172.IN-ADDR.ARPA
28.172.IN-ADDR.ARPA
29.172.IN-ADDR.ARPA
30.172.IN-ADDR.ARPA
31.172.IN-ADDR.ARPA
168.192.IN-ADDR.ARPA
64.100.IN-ADDR.ARPA
65.100.IN-ADDR.ARPA
66.100.IN-ADDR.ARPA
67.100.IN-ADDR.ARPA
68.100.IN-ADDR.ARPA
69.100.IN-ADDR.ARPA
70.100.IN-ADDR.ARPA
71.100.IN-ADDR.ARPA
72.100.IN-ADDR.ARPA
73.100.IN-ADDR.ARPA
74.100.IN-ADDR.ARPA
75.100.IN-ADDR.ARPA
76.100.IN-ADDR.ARPA
77.100.IN-ADDR.ARPA
78.100.IN-ADDR.ARPA
79.100.IN-ADDR.ARPA
80.100.IN-ADDR.ARPA
81.100.IN-ADDR.ARPA
82.100.IN-ADDR.ARPA
83.100.IN-ADDR.ARPA
84.100.IN-ADDR.ARPA
85.100.IN-ADDR.ARPA
86.100.IN-ADDR.ARPA
87.100.IN-ADDR.ARPA
88.100.IN-ADDR.ARPA
89.100.IN-ADDR.ARPA
90.100.IN-ADDR.ARPA
91.100.IN-ADDR.ARPA
92.100.IN-ADDR.ARPA
93.100.IN-ADDR.ARPA
94.100.IN-ADDR.ARPA
95.100.IN-ADDR.ARPA
96.100.IN-ADDR.ARPA
97.100.IN-ADDR.ARPA
98.100.IN-ADDR.ARPA
99.100.IN-ADDR.ARPA
100.100.IN-ADDR.ARPA
101.100.IN-ADDR.ARPA
102.100.IN-ADDR.ARPA
103.100.IN-ADDR.ARPA
104.100.IN-ADDR.ARPA
105.100.IN-ADDR.ARPA
106.100.IN-ADDR.ARPA
107.100.IN-ADDR.ARPA
108.100.IN-ADDR.ARPA
109.100.IN-ADDR.ARPA
110.100.IN-ADDR.ARPA
111.100.IN-ADDR.ARPA
112.100.IN-ADDR.ARPA
113.100.IN-ADDR.ARPA
114.100.IN-ADDR.ARPA
115.100.IN-ADDR.ARPA
116.100.IN-ADDR.ARPA
117.100.IN-ADDR.ARPA
118.100.IN-ADDR.ARPA
119.100.IN-ADDR.ARPA
120.100.IN-ADDR.ARPA
121.100.IN-ADDR.ARPA
122.100.IN-ADDR.ARPA
123.100.IN-ADDR.ARPA
124.100.IN-ADDR.ARPA
125.100.IN-ADDR.ARPA
126.100.IN-ADDR.ARPA
127.100.IN-ADDR.ARPA
0.IN-ADDR.ARPA
127.IN-ADDR.ARPA
254.169.IN-ADDR.ARPA
2.0.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA
D.F.IP6.ARPA
8.E.F.IP6.ARPA
9.E.F.IP6.ARPA
A.E.F.IP6.ARPA
B.E.F.IP6.ARPA
EMPTY.AS112.ARPA
HOME.ARPA
You can configure empty zones by using the empty-server,
empty-contact, empty-zones-enable, and the
disable-empty-zone options of named.conf(5). Empty zones
can be set at the view-level and only apply to views of class
IN. Disabled empty zones are only inherited from the options
statement if there are no disabled empty zones specified at the
view-level. To override the list of disabled zones from the options
statement, you can disable the root zone at the view-level. For
example:
disable-empty-zone ".";
If you are using the address ranges covered here, you should already have reverse zones covering the addresses you use. In practice this appears to not be the case with many queries being made to the infrastructure servers for names in these spaces. So many in fact that sacrificial servers were needed to be deployed to channel the query load away from the infrastructure servers.
Note
The real parent servers for these zones should disable all empty zone under the parent zone they serve. For the real root servers, this is all built-in empty zones. This will enable them to return referrals to deeper in the tree.
6.15. DNS64¶
acl rfc1918 { 10/8; 192.168/16; 172.16/12; };
dns64 64:FF9B::/96 {
clients { any; };
mapped { !rfc1918; any; };
exclude { 64:FF9B::/96; ::ffff:0000:0000/96; };
suffix ::;
};
6.16. Forwarding queries¶
The forwarding facility can be used to create a large site-wide cache on a few servers, reducing traffic over links to external name servers. It can also be used to allow queries by servers that do not have direct access to the Internet, but wish to look up exterior names anyway. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache.
forward
forwarders
Forwarding can also be configured on a per-domain basis, allowing for
the global forwarding options to be overridden in a variety of ways. You
can set particular domains to use different forwarders, or have a
different forward only/first behavior, or not forward at all, see
section_title.
6.17. Dual-stack Servers¶
Dual-stack servers are used as servers of last resort to work around problems in reachability due the lack of support for either IPv4 or IPv6 on the host machine.
dual-stack-servers
6.18. Access Control¶
Access to the server can be restricted based on the IP address of the requesting system. See section_title for details on how to specify IP address lists.
allow-notify
allow-query
allow-query-on
allow-query-cache
allow-query-cache-on
allow-recursion
allow-recursion-on
allow-update
allow-update-forwarding
allow-transfer
block
no-case-compress
resolver-query-timeout
6.19. Interfaces¶
The interfaces and ports that the server will answer queries from may be
specified using the listen-on option. listen-on takes an
optional port and an address_match_list of IPv4 addresses. (IPv6
addresses are ignored, with a logged warning.) The server will listen on
all interfaces allowed by the address match list. If a port is not
specified, port 53 will be used.
Multiple listen-on statements are allowed. For example,
listen-on { 5.6.7.8; };
listen-on port 1234 { !1.2.3.4; 1.2/16; };
will enable the name server on port 53 for the IP address 5.6.7.8, and on port 1234 of an address on the machine in net 1.2 that is not 1.2.3.4.
If no listen-on is specified, the server will listen on port 53 on
all IPv4 interfaces.
The listen-on-v6 option is used to specify the interfaces and the
ports on which the server will listen for incoming queries sent using
IPv6. If not specified, the server will listen on port 53 on all IPv6
interfaces.
When
{ any; }
is specified as the address_match_list for the listen-on-v6
option, the server does not bind a separate socket to each IPv6
interface address as it does for IPv4 if the operating system has enough
API support for IPv6 (specifically if it conforms to RFC 3493 and RFC
3542). Instead, it listens on the IPv6 wildcard address. If the system
only has incomplete API support for IPv6, however, the behavior is the
same as that for IPv4.
A list of particular IPv6 addresses can also be specified, in which case
the server listens on a separate socket for each specified address,
regardless of whether the desired API is supported by the system. IPv4
addresses specified in listen-on-v6 will be ignored, with a logged
warning.
Multiple listen-on-v6 options can be used. For example,
listen-on-v6 { any; };
listen-on-v6 port 1234 { !2001:db8::/32; any; };
will enable the name server on port 53 for any IPv6 addresses (with a single wildcard socket), and on port 1234 of IPv6 addresses that is not in the prefix 2001:db8::/32 (with separate sockets for each matched address.)
To make the server not listen on any IPv6 address, use
listen-on-v6 { none; };
6.20. Query address¶
If the server doesn't know the answer to a question, it will query other
name servers. query-source specifies the address and port used for
such queries. For queries sent over IPv6, there is a separate
query-source-v6 option. If address is * (asterisk) or is
omitted, a wildcard IP address (INADDR_ANY) will be used.
If port is * or is omitted, a random port number from a
pre-configured range is picked up and will be used for each query. The
port range(s) is that specified in the use-v4-udp-ports (for IPv4)
and use-v6-udp-ports (for IPv6) options, excluding the ranges
specified in the avoid-v4-udp-ports and avoid-v6-udp-ports
options, respectively.
The defaults of the query-source and query-source-v6 options
are:
query-source address * port *;
query-source-v6 address * port *;
If use-v4-udp-ports or use-v6-udp-ports is unspecified,
named will check if the operating system provides a programming
interface to retrieve the system's default range for ephemeral ports. If
such an interface is available, named will use the corresponding
system default range; otherwise, it will use its own defaults:
use-v4-udp-ports { range 1024 65535; };
use-v6-udp-ports { range 1024 65535; };
Note: make sure the ranges be sufficiently large for security. A
desirable size depends on various parameters, but we generally recommend
it contain at least 16384 ports (14 bits of entropy). Note also that the
system's default range when used may be too small for this purpose, and
that the range may even be changed while named is running; the new
range will automatically be applied when named is reloaded. It is
encouraged to configure use-v4-udp-ports and use-v6-udp-ports
explicitly so that the ranges are sufficiently large and are reasonably
independent from the ranges used by other applications.
Note: the operational configuration where named runs may prohibit
the use of some ports. For example, UNIX systems will not allow
named running without a root privilege to use ports less than 1024.
If such ports are included in the specified (or detected) set of query
ports, the corresponding query attempts will fail, resulting in
resolution failures or delay. It is therefore important to configure the
set of ports that can be safely used in the expected operational
environment.
The defaults of the avoid-v4-udp-ports and avoid-v6-udp-ports
options are:
avoid-v4-udp-ports {};
avoid-v6-udp-ports {};
Note: It is generally strongly discouraged to specify a particular port
for the query-source or query-source-v6 options; it implicitly
disables the use of randomized port numbers.
Note
The address specified in the
query-sourceoption is used for both UDP and TCP queries, but the port applies only to UDP queries. TCP queries always use a random unprivileged port.
Note
See also
transfer-sourceandnotify-source.
6.21. Zone Transfers¶
Loop has mechanisms in place to facilitate zone transfers and set limits on the amount of load that transfers place on the system. The following options apply to zone transfers.
also-notify
max-transfer-time-in
max-transfer-idle-in
max-transfer-time-out
max-transfer-idle-out
serial-query-rate
transfers-in
transfers-out
transfers-per-ns
transfer-source
transfer-source-v6
alt-transfer-source
alt-transfer-source-v6
use-alt-transfer-source
notify-source
notify-source-v6
6.22. UDP port lists¶
use-v4-udp-ports, avoid-v4-udp-ports, use-v6-udp-ports, and
avoid-v6-udp-ports specify a list of IPv4 and IPv6 UDP ports that
will be used or not used as source ports for UDP messages. See
Query address about how the available ports are determined.
For example, with the following configuration:
use-v6-udp-ports { range 32768 65535; };
avoid-v6-udp-ports { 40000; range 50000 60000; };
UDP ports of IPv6 messages sent from named will be in one of the ranges 32768 to 39999, 40001 to 49999, and 60001 to 65535.
avoid-v4-udp-ports and avoid-v6-udp-ports can be used to prevent
named from choosing as its random source port a port that is
blocked by your firewall or a port that is used by other applications;
if a query went out with a source port blocked by a firewall, the answer
would not get by the firewall and the name server would have to query
again.
Note
The desired range can also be represented only with
use-v4-udp-ports and use-v6-udp-ports, and the
avoid- options are redundant in that sense; they are
provided for backward compatibility and to possibly simplify
the port specification.
Error
TODO: Remove the avoid- options.
6.23. Operating System Resource Limits¶
The server's usage of many system resources can be limited. Scaled
values are allowed when specifying resource limits. For example, 1G
can be used instead of 1073741824 to specify a limit of one
gigabyte. unlimited requests unlimited use, or the maximum available
amount. default uses the limit that was in force when the server was
started. See the description of size_spec in
section_title.
The following options set operating system resource limits for the name server process. Some operating systems don't support some or any of the limits. On such systems, a warning will be issued if the unsupported limit is used.
coresize
datasize
files
stacksize
6.24. Server Resource Limits¶
The following options set limits on the server's resource consumption that are enforced internally by the server rather than the operating system.
max-journal-size
max-records
recursive-clients
tcp-clients
clients-per-query; max-clients-per-query
fetches-per-zone
fetches-per-server
fetch-quota-params
reserved-sockets
max-cache-size
tcp-listen-queue
6.25. Periodic Task Intervals¶
heartbeat-interval
interface-interval
6.26. RRset ordering¶
When multiple records are returned in an answer, it may be useful to configure the order of the records placed into the response.
rrset-order
6.27. Tuning¶
max-ncache-ttl
max-cache-ttl
sig-validity-interval
sig-signing-nodes
sig-signing-signatures
sig-signing-type
min-refresh-time; max-refresh-time; min-retry-time; max-retry-time
edns-udp-size
max-udp-size
max-recursion-depth
max-recursion-queries
notify-delay
max-rsa-exponent-size
prefetch
6.28. Built-in server information zones¶
The server provides some helpful diagnostic information through a number
of built-in zones under the pseudo-top-level-domain loop in the
CHAOS class. These zones are part of a built-in view (see
section_title) of class CHAOS which is
separate from the default view of class IN. Most global
configuration options (allow-query, etc) will apply to this view,
but some are locally overridden: notify, recursion and
allow-new-zones are always set to no, and rate-limit is set
to allow three responses per second.
If you need to disable these zones, use the options below, or hide the
built-in CHAOS view by defining an explicit view of class CHAOS
that matches all clients.
version
server-id
6.29. Built-in Empty Zones¶
empty-server
empty-contact
empty-zones-enable
disable-empty-zone
6.30. Content Filtering¶
Loop provides the ability to filter out DNS responses from external
DNS servers containing certain types of data in the answer section.
Specifically, it can reject address (A or AAAA) records if the
corresponding IPv4 or IPv6 addresses match the given
address_match_list of the deny-answer-addresses option. It can
also reject CNAME or DNAME records if the "alias" name (i.e., the CNAME
alias or the substituted query name due to DNAME) matches the given
namelist of the deny-answer-aliases option, where "match" means
the alias name is a subdomain of one of the name_list elements. If
the optional namelist is specified with except-from, records
whose query name matches the list will be accepted regardless of the
filter setting. Likewise, if the alias name is a subdomain of the
corresponding zone, the deny-answer-aliases filter will not apply;
for example, even if "example.com" is specified for
deny-answer-aliases,
www.example.com. CNAME xxx.example.com.
returned by an "example.com" server will be accepted.
In the address_match_list of the deny-answer-addresses option,
only ip_addr and ip_prefix are meaningful; any key_id will
be silently ignored.
If a response message is rejected due to the filtering, the entire message is discarded without being cached, and a SERVFAIL error will be returned to the client.
This filtering is intended to prevent "DNS rebinding attacks," in which an attacker, in response to a query for a domain name the attacker controls, returns an IP address within your own network or an alias name within your own domain. A naive web browser or script could then serve as an unintended proxy, allowing the attacker to get access to an internal node of your local network that couldn't be externally accessed otherwise. See the paper available at http://portal.acm.org/citation.cfm?id=1315245.1315298 for more details about the attacks.
For example, if you own a domain named "example.net" and your internal network uses an IPv4 prefix 192.0.2.0/24, you might specify the following rules:
deny-answer-addresses { 192.0.2.0/24; } except-from { "example.net"; };
deny-answer-aliases { "example.net"; };
If an external attacker lets a web browser in your local network look up an IPv4 address of "attacker.example.com", the attacker's DNS server would return a response like this:
attacker.example.com. A 192.0.2.1
in the answer section. Since the rdata of this record (the IPv4 address) matches the specified prefix 192.0.2.0/24, this response will be ignored.
On the other hand, if the browser looks up a legitimate internal web server "www.example.net" and the following response is returned to the Loop server
www.example.net. A 192.0.2.2
it will be accepted since the owner name "www.example.net" matches the
except-from element, "example.net".
Note that this is not really an attack on the DNS per se. In fact, there is nothing wrong for an "external" name to be mapped to your "internal" IP address or domain name from the DNS point of view. It might actually be provided for a legitimate purpose, such as for debugging. As long as the mapping is provided by the correct owner, it is not possible or does not make sense to detect whether the intent of the mapping is legitimate or not within the DNS. The "rebinding" attack must primarily be protected at the application that uses the DNS. For a large site, however, it may be difficult to protect all possible applications at once. This filtering feature is provided only to help such an operational environment; it is generally discouraged to turn it on unless you are very sure you have no other choice and the attack is a real threat for your applications.
Care should be particularly taken if you want to use this option for addresses within 127.0.0.0/8. These addresses are obviously "internal", but many applications conventionally rely on a DNS mapping from some name to such an address. Filtering out DNS records containing this address spuriously can break such applications.
6.31. Response Policy Zones (RPZ)¶
Loop includes a limited mechanism to modify DNS responses for requests analogous to email anti-spam DNS blacklists. Responses can be changed to deny the existence of domains (NXDOMAIN), deny the existence of IP addresses for domains (NODATA), or contain other IP addresses or data.
Response policy zones are named in the response-policy option for
the view or among the global options if there is no response-policy
option for the view. Response policy zones are ordinary DNS zones
containing RRsets that can be queried normally if allowed. It is usually
best to restrict those queries with something like
allow-query { localhost; };.
A response-policy option can support multiple policy zones. To
maximize performance, a radix tree is used to quickly identify response
policy zones containing triggers that match the current query. This
imposes an upper limit of 32 on the number of policy zones in a single
response-policy option; more than that is a configuration error.
Five policy triggers can be encoded in RPZ records.
RPZ-CLIENT-IPIP records are triggered by the IP address of the DNS client. Client IP address triggers are encoded in records that have owner names that are subdomains of
rpz-client-iprelativized to the policy zone origin name and encode an address or address block. IPv4 addresses are represented asprefixlength.B4.B3.B2.B1.rpz-client-ip. The IPv4 prefix length must be between 1 and 32. All four bytes, B4, B3, B2, and B1, must be present. B4 is the decimal value of the least significant byte of the IPv4 address as in IN-ADDR.ARPA.IPv6 addresses are encoded in a format similar to the standard IPv6 text representation,
prefixlength.W8.W7.W6.W5.W4.W3.W2.W1.rpz-client-ip. Each of W8,...,W1 is a one to four digit hexadecimal number representing 16 bits of the IPv6 address as in the standard text representation of IPv6 addresses, but reversed as in IP6.ARPA. (Note that this representation of IPv6 address is different from IP6.ARPA where each hex digit occupies a label.) All 8 words must be present except when one set of consecutive zero words is replaced with.zz.analogous to double colons (::) in standard IPv6 text encodings. The IPv6 prefix length must be between 1 and 128.QNAMEQNAME policy records are triggered by query names of requests and targets of CNAME records resolved to generate the response. The owner name of a QNAME policy record is the query name relativized to the policy zone.
RPZ-IPIP triggers are IP addresses in an A or AAAA record in the ANSWER section of a response. They are encoded like client-IP triggers except as subdomains of
rpz-ip.RPZ-NSDNAMENSDNAME triggers match names of authoritative servers for the query name, a parent of the query name, a CNAME for query name, or a parent of a CNAME. They are encoded as subdomains of
rpz-nsdnamerelativized to the RPZ origin name. NSIP triggers match IP addresses in A and AAAA RRsets for domains that can be checked against NSDNAME policy records.RPZ-NSIPNSIP triggers are encoded like IP triggers except as subdomains of
rpz-nsip. NSDNAME and NSIP triggers are checked only for names with at leastmin-ns-dotsdots. The default value ofmin-ns-dotsis 1 to exclude top level domains.
The query response is checked against all response policy zones, so two
or more policy records can be triggered by a response. Because DNS
responses are rewritten according to at most one policy record, a single
record encoding an action (other than DISABLED actions) must be
chosen. Triggers or the records that encode them are chosen for the
rewriting in the following order:
Choose the triggered record in the zone that appears first in the response-policy option.
Prefer CLIENT-IP to QNAME to IP to NSDNAME to NSIP triggers in a single zone.
Among NSDNAME triggers, prefer the trigger that matches the smallest name under the DNSSEC ordering.
Among IP or NSIP triggers, prefer the trigger with the longest prefix.
Among triggers with the same prefix length, prefer the IP or NSIP trigger that matches the smallest IP address.
When the processing of a response is restarted to resolve DNAME or CNAME records and a policy record set has not been triggered, all response policy zones are again consulted for the DNAME or CNAME names and addresses.
RPZ record sets are any types of DNS record except DNAME or DNSSEC that
encode actions or responses to individual queries. Any of the policies
can be used with any of the triggers. For example, while the
TCP-only policy is commonly used with client-IP triggers, it cn
be used with any type of trigger to force the use of TCP for responses
with owner names in a zone.
PASSTHRUThe whitelist policy is specified by a CNAME whose target is
rpz-passthru. It causes the response to not be rewritten and is most often used to "poke holes" in policies for CIDR blocks.DROPThe blacklist policy is specified by a CNAME whose target is
rpz-drop. It causes the response to be discarded. Nothing is sent to the DNS client.TCP-OnlyThe "slip" policy is specified by a CNAME whose target is
rpz-tcp-only. It changes UDP responses to short, truncated DNS responses that require the DNS client to try again with TCP. It is used to mitigate distributed DNS reflection attacks.NXDOMAINThe domain undefined response is encoded by a CNAME whose target is the root domain (.)
NODATAThe empty set of resource records is specified by CNAME whose target is the wildcard top-level domain (
*.). It rewrites the response to NODATA or ANCOUNT=1.Local DataA set of ordinary DNS records can be used to answer queries. Queries for record types not the set are answered with NODATA.
A special form of local data is a CNAME whose target is a wildcard such as *.example.com. It is used as if were an ordinary CNAME after the astrisk (*) has been replaced with the query name. The purpose for this special form is query logging in the walled garden's authority DNS server.
All of the actions specified in all of the individual records in a
policy zone can be overridden with a policy clause in the
response-policy option. An organization using a policy zone provided
by another organization might use this mechanism to redirect domains to
its own walled garden.
GIVENThe placeholder policy says "do not override but perform the action specified in the zone."
DISABLEDThe testing override policy causes policy zone records to do nothing but log what they would have done if the policy zone were not disabled. The response to the DNS query will be written (or not) according to any triggered policy records that are not disabled. Disabled policy zones should appear first, because they will often not be logged if a higher precedence trigger is found first.
PASSTHRU;DROP;TCP-Only;NXDOMAIN;NODATAoverride with the corresponding per-record policy.
CNAME domaincauses all RPZ policy records to act as if they were "cname domain" records.
By default, the actions encoded in a response policy zone are applied
only to queries that ask for recursion (RD=1). That default can be
changed for a single policy zone or all response policy zones in a view
with a recursive-only no clause. This feature is useful for serving
the same zone files both inside and outside an RFC 1918 cloud and using
RPZ to delete answers that would otherwise contain RFC 1918 values on
the externally visible name server or view.
Also by default, RPZ actions are applied only to DNS requests that
either do not request DNSSEC metadata (DO=0) or when no DNSSEC records
are available for request name in the original zone (not the response
policy zone). This default can be changed for all response policy zones
in a view with a break-dnssec yes clause. In that case, RPZ actions
are applied regardless of DNSSEC. The name of the clause option reflects
the fact that results rewritten by RPZ actions cannot verify.
No DNS records are needed for a QNAME or Client-IP trigger. The name or
IP address itself is sufficient, so in principle the query name need not
be recursively resolved. However, not resolving the requested name can
leak the fact that response policy rewriting is in use and that the name
is listed in a policy zone to operators of servers for listed names. To
prevent that information leak, by default any recursion needed for a
request is done before any policy triggers are considered. Because
listed domains often have slow authoritative servers, this default
behavior can cost significant time. The qname-wait-recurse no option
overrides that default behavior when recursion cannot change a non-error
response. The option does not affect QNAME or client-IP triggers in
policy zones listed after other zones containing IP, NSIP and NSDNAME
triggers, because those may depend on the A, AAAA, and NS records that
would be found during recursive resolution. It also does not affect
DNSSEC requests (DO=1) unless break-dnssec yes is in use, because
the response would depend on whether or not RRSIG records were found
during resolution. Using this option can cause error responses such as
SERVFAIL to appear to be rewritten, since no recursion is being done to
discover problems at the authoritative server.
The TTL of a record modified by RPZ policies is set from the TTL of the
relevant record in policy zone. It is then limited to a maximum value.
The max-policy-ttl clause changes that maximum from its default of
5.
For example, you might use this option statement
response-policy { zone "badlist"; };
and this zone statement
zone "badlist" {type master; file "master/badlist"; allow-query {none;}; };
with this zone file
$TTL 1H
@ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
NS LOCALHOST.
; QNAME policy records. There are no periods (.) after the owner names.
nxdomain.domain.com CNAME . ; NXDOMAIN policy
*.nxdomain.domain.com CNAME . ; NXDOMAIN policy
nodata.domain.com CNAME *. ; NODATA policy
*.nodata.domain.com CNAME *. ; NODATA policy
bad.domain.com A 10.0.0.1 ; redirect to a walled garden
AAAA 2001:2::1
bzone.domain.com CNAME garden.example.com.
; do not rewrite (PASSTHRU) OK.DOMAIN.COM
ok.domain.com CNAME rpz-passthru.
; redirect x.bzone.domain.com to x.bzone.domain.com.garden.example.com
*.bzone.domain.com CNAME *.garden.example.com.
; IP policy records that rewrite all responses containing A records in 127/8
; except 127.0.0.1
8.0.0.0.127.rpz-ip CNAME .
32.1.0.0.127.rpz-ip CNAME rpz-passthru.
; NSDNAME and NSIP policy records
ns.domain.com.rpz-nsdname CNAME .
48.zz.2.2001.rpz-nsip CNAME .
; blacklist and whitelist some DNS clients
112.zz.2001.rpz-client-ip CNAME rpz-drop.
8.0.0.0.127.rpz-client-ip CNAME rpz-drop.
; force some DNS clients and responses in the example.com zone to TCP
16.0.0.1.10.rpz-client-ip CNAME rpz-tcp-only.
example.com CNAME rpz-tcp-only.
*.example.com CNAME rpz-tcp-only.
RPZ can affect server performance. Each configured response policy zone requires the server to perform one to four additional database lookups before a query can be answered. For example, a DNS server with four policy zones, each with all four kinds of response triggers, QNAME, IP, NSIP, and NSDNAME, requires a total of 17 times as many database lookups as a similar DNS server with no response policy zones. A Loop server with adequate memory and one response policy zone with QNAME and IP triggers might achieve a maximum queries-per-second rate about 20% lower. A server with four response policy zones with QNAME and IP triggers might have a maximum QPS rate about 50% lower.
Responses rewritten by RPZ are counted in the RPZRewrites
statistics.
6.32. Response Rate Limiting (RRL)¶
Excessive almost identical UDP responses can be controlled by
configuring a rate-limit clause in an options or view
statement. This mechanism keeps authoritative Loop from being used in
amplifying reflection denial of service (DoS) attacks. Short truncated
(TC=1) responses can be sent to provide rate-limited responses to
legitimate clients within a range of forged, attacked IP addresses.
Legitimate clients react to dropped or truncated response by retrying
with UDP or with TCP respectively.
This mechanism is intended for authoritative DNS servers. It can be used on recursive servers but can slow applications such as SMTP servers (mail receivers) and HTTP clients (web browsers) that repeatedly request the same domains. When possible, closing "open" recursive servers is better.
Response rate limiting uses a "credit" or "token bucket" scheme. Each
combination of identical response and client has a conceptual account
that earns a specified number of credits every second. A prospective
response debits its account by one. Responses are dropped or truncated
while the account is negative. Responses are tracked within a rolling
window of time which defaults to 15 seconds, but can be configured with
the window option to any value from 1 to 3600 seconds (1 hour). The
account cannot become more positive than the per-second limit or more
negative than window times the per-second limit. When the specified
number of credits for a class of responses is set to 0, those responses
are not rate limited.
The notions of "identical response" and "DNS client" for rate limiting
are not simplistic. All responses to an address block are counted as if
to a single client. The prefix lengths of addresses blocks are specified
with ipv4-prefix-length (default 24) and ipv6-prefix-length
(default 56).
All non-empty responses for a valid domain name (qname) and record type
(qtype) are identical and have a limit specified with
responses-per-second (default 0 or no limit). All empty (NODATA)
responses for a valid domain, regardless of query type, are identical.
Responses in the NODATA class are limited by nodata-per-second
(default responses-per-second). Requests for any and all undefined
subdomains of a given valid domain result in NXDOMAIN errors, and are
identical regardless of query type. They are limited by
nxdomains-per-second (default base responses-per-second). This
controls some attacks using random names, but can be relaxed or turned
off (set to 0) on servers that expect many legitimate NXDOMAIN
responses, such as from anti-spam blacklists. Referrals or delegations
to the server of a given domain are identical and are limited by
referrals-per-second (default responses-per-second).
Responses generated from local wildcards are counted and limited as if they were for the parent domain name. This controls flooding using random.wild.example.com.
All requests that result in DNS errors other than NXDOMAIN, such as
SERVFAIL and FORMERR, are identical regardless of requested name (qname)
or record type (qtype). This controls attacks using invalid requests or
distant, broken authoritative servers. By default the limit on errors is
the same as the responses-per-second value, but it can be set
separately with errors-per-second.
Many attacks using DNS involve UDP requests with forged source
addresses. Rate limiting prevents the use of Loop to flood a network
with responses to requests with forged source addresses, but could let a
third party block responses to legitimate requests. There is a mechanism
that can answer some legitimate requests from a client whose address is
being forged in a flood. Setting slip to 2 (its default) causes
every other UDP request to be answered with a small truncated (TC=1)
response. The small size and reduced frequency, and so lack of
amplification, of "slipped" responses make them unattractive for
reflection DoS attacks. slip must be between 0 and 10. A value of 0
does not "slip": no truncated responses are sent due to rate limiting,
all responses are dropped. A value of 1 causes every response to slip;
values between 2 and 10 cause every n'th response to slip. Some error
responses including REFUSED and SERVFAIL cannot be replaced with
truncated responses and are instead leaked at the slip rate.
(NOTE: Dropped responses from an authoritative server may reduce the
difficulty of a third party successfully forging a response to a
recursive resolver. The best security against forged responses is for
authoritative operators to sign their zones using DNSSEC and for
resolver operators to validate the responses. When this is not an
option, operators who are more concerned with response integrity than
with flood mitigation may consider setting slip to 1, causing all
rate-limited responses to be truncated rather than dropped. This reduces
the effectiveness of rate-limiting against reflection attacks.)
When the approximate query per second rate exceeds the qps-scale
value, then the responses-per-second, errors-per-second,
nxdomains-per-second and all-per-second values are reduced by
the ratio of the current rate to the qps-scale value. This feature
can tighten defenses during attacks. For example, with
qps-scale 250; responses-per-second 20; and a total query rate of
1000 queries/second for all queries from all DNS clients including via
TCP, then the effective responses/second limit changes to (250/1000)*20
or 5. Responses sent via TCP are not limited but are counted to compute
the query per second rate.
Communities of DNS clients can be given their own parameters or no rate
limiting by putting rate-limit statements in view statements
instead of the global option statement. A rate-limit statement
in a view replaces, rather than supplementing, a rate-limit
statement among the main options. DNS clients within a view can be
exempted from rate limits with the exempt-clients clause.
UDP responses of all kinds can be limited with the all-per-second
phrase. This rate limiting is unlike the rate limiting provided by
responses-per-second, errors-per-second, and
nxdomains-per-second on a DNS server which are often invisible to
the victim of a DNS reflection attack. Unless the forged requests of the
attack are the same as the legitimate requests of the victim, the
victim's requests are not affected. Responses affected by an
all-per-second limit are always dropped; the slip value has no
effect. An all-per-second limit should be at least 4 times as large
as the other limits, because single DNS clients often send bursts of
legitimate requests. For example, the receipt of a single mail message
can prompt requests from an SMTP server for NS, PTR, A, and AAAA records
as the incoming SMTP/TCP/IP connection is considered. The SMTP server
can need additional NS, A, AAAA, MX, TXT, and SPF records as it
considers the STMP Mail From command. Web browsers often repeatedly
resolve the same names that are repeated in HTML <IMG> tags in a page.
All-per-second is similar to the rate limiting offered by firewalls
but often inferior. Attacks that justify ignoring the contents of DNS
responses are likely to be attacks on the DNS server itself. They
usually should be discarded before the DNS server spends resources
making TCP connections or parsing DNS requests, but that rate limiting
must be done before the DNS server sees the requests.
The maximum size of the table used to track requests and rate limit
responses is set with max-table-size. Each entry in the table is
between 40 and 80 bytes. The table needs approximately as many entries
as the number of requests received per second. The default is 20,000. To
reduce the cold start of growing the table, min-table-size (default
500) can set the minimum table size. Enable rate-limit category
logging to monitor expansions of the table and inform choices for the
initial and maximum table size.
Use log-only yes to test rate limiting parameters without actually
dropping any requests.
Responses dropped by rate limits are included in the RateDropped and
QryDropped statistics. Responses that truncated by rate limits are
included in RateSlipped and RespTruncated.
6.32.1. Dynamic Update Policies¶
Loop supports two alternative methods of granting clients the right to
perform dynamic updates to a zone, configured by the allow-update
and update-policy option, respectively.
The allow-update clause is a simple access control list. Any client
that matches the ACL is granted permission to update any record in the
zone.
The update-policy clause allows more fine-grained control over what
updates are allowed. It specifies a set of rules, in which each rule
either grants or denies permission for one or more names in the zone to
be updated by one or more identities. Identity is determined by the key
that signed the update request using either TSIG or SIG(0). In most
cases, update-policy rules only apply to key-based identities. There
is no way to specify update permissions based on client source address.
update-policy rules are only meaningful for zones of type
master, and are not allowed in any other zone type. It is a
configuration error to specify both allow-update and
update-policy at the same time.
A pre-defined update-policy rule can be switched on with the command
update-policy local;. Using this in a zone causes named to
generate a TSIG session key when starting up and store it in a file;
this key can then be used by local clients to update the zone while
named is running. By default, the session key is stored in the file
/var/run/loop/session.key, the key name is
"local-ddns", and the key algorithm is HMAC-SHA256. These values are
configurable with the session-keyfile, session-keyname and
session-keyalg options, respectively. A client running on the local
system, if run with appropriate permissions, may read the session key
from the key file and use it to sign update requests. The zone's update
policy will be set to allow that key to change any record within the
zone. Assuming the key name is "local-ddns", this policy is equivalent
to:
update-policy { grant local-ddns zonesub any; };
...with the additional restriction that only clients connecting from the local system will be permitted to send updates.
Note that only one session key is generated by named; all zones
configured to use update-policy local will accept the same key.
The command nsupdate -l implements this feature, sending requests to
localhost and signing them using the key retrieved from the session key
file.
Other rule definitions look like this:
( grant | deny ) identity ruletype name types
Each rule grants or denies privileges. Rules are checked in the order in
which they are specified in the update-policy statement. Once a
message has successfully matched a rule, the operation is immediately
granted or denied, and no further rules are examined. There are 10 types
of rules; the rule type is specified by the ruletype field, and the
interpretation of other fields varies depending on the rule type.
In general, a rule is matched when the key that signed an update request
matches the identity field, the name of the record to be updated
matches the name field (in the manner specified by the ruletype
field), and the type of the record to be updated matches the types
field. Details for each rule type are described below.
The identity field must be set to a fully-qualified domain name. In
most cases, this represensts the name of the TSIG or SIG(0) key that
must be used to sign the update request. If the specified name is a
wildcard, it is subject to DNS wildcard expansion, and the rule may
apply to multiple identities. When a TKEY exchange has been used to
create a shared secret, the identity of the key used to authenticate the
TKEY exchange will be used as the identity of the shared secret. Some
rule types use indentities matching the client's Kerberos principal
(e.g, "host/machine@REALM") or Windows realm (machine$@REALM).
The name field also specifies a fully-qualified domain name. This often represents the name of the record to be updated. Interpretation of this field is dependent on rule type.
If no types are explicitly specified, then a rule matches all types
except RRSIG, NS, SOA, NSEC and NSEC3. Types may be specified by name,
including "ANY" (ANY matches all types except NSEC and NSEC3, which can
never be updated). Note that when an attempt is made to delete all
records associated with a name, the rules are checked for each existing
record type.
The ruletype field has 10 values: name, subdomain, wildcard,
self, selfsub, selfwild, tcp-self, 6to4-self,
zonesub, and external.
Name |
Description |
|---|---|
|
Exact-match semantics. This rule matches when the name being updated is identical to the contents of the name field. |
|
This rule matches when the name being updated is a subdomain of, or identical to, the contents of the name field. |
|
This rule is similar to subdomain, except that it matches when
the name being updated is a subdomain of the zone in which the
When this rule is used, the name field is omitted. |
|
The name field is subject to DNS wildcard expansion, and this rule matches when the name being updated is a valid expansion of the wildcard. |
|
This rule matches when the name of the record being updated
matches the contents of the identity field. The name field is
ignored. To avoid confusion, it is recommended that this field be
set to the same value as the identity field or to The |
|
This rule is similar to |
|
This rule is similar to |
|
This rule allows updates that have been sent via TCP and for
which the standard mapping from the client's IP address into the
Note It is theoretically possible to spoof these TCP sessions. |
|
This allows the name matching a 6to4 IPv6 prefix, as specified in
RFC 3056, to be updated by any TCP connection from either the
6to4 network or from the corresponding IPv4 address. This is
intended to allow NS or DNAME RRsets to be added to the
The In addition, if specified for an Note It is theoretically possible to spoof these TCP sessions. |
|
This rule allows The method of communicating with the daemon is specified in the
identity field, the format of which is " Requests to the external daemon are sent over the UNIX-domain socket as datagrams with the following format: Protocol version number (4 bytes, network byte order, currently 1)
Request length (4 bytes, network byte order)
Signer (null-terminated string)
Name (null-terminated string)
TCP source address (null-terminated string)
Rdata type (null-terminated string)
Key (null-terminated string)
TKEY token length (4 bytes, network byte order)
TKEY token (remainder of packet)
The daemon replies with a four-byte value in network byte order, containing either 0 or 1; 0 indicates that the specified update is not permitted, and 1 indicates that it is. |
6.32.2. Multiple views¶
When multiple views are in use, a zone may be referenced by more than
one of them. Often, the views will contain different zones with the same
name, allowing different clients to receive different answers for the
same queries. At times, however, it is desirable for multiple views to
contain identical zones. The in-view zone option provides an
efficient way to do this: it allows a view to reference a zone that was
defined in a previously configured view. Example:
view internal {
match-clients { 10/8; };
zone example.com {
type master;
file "example-external.db";
};
};
view external {
match-clients { any; };
zone example.com {
in-view internal;
};
};
An in-view option cannot refer to a view that is configured later in
the configuration file.
A zone statement which uses the in-view option may not use any
other options with the exception of forward and forwarders.
(These options control the behavior of the containing view, rather than
changing the zone object itself.)
Zone level acls (e.g. allow-query, allow-transfer) and other configuration details of the zone are all set in the view the referenced zone is defined in. Care need to be taken to ensure that acls are wide enough for all views referencing the zone.
An in-view zone cannot be used as a response policy zone.
An in-view zone is not intended to reference a forward zone.