Skip to content

GitLab

Commit 3ef4b738 authored by Evan Hunt's avatar Evan Hunt
Browse files

[master] improved doc for "rndc signing -list" 

3769.   [doc]           Improved documentation of "rndc signing -list".
                        [RT #30652]
parent 72aa3b2a
Hide whitespace changes
Inline Side-by-side
CHANGES
View file @ 3ef4b738
3769. [doc] Improved documentation of "rndc signing -list".
[RT #30652]
3768. [bug] "dnssec-checkds" was missing the SHA-384 digest
algorithm. [RT #34000]
......
bin/rndc/rndc.docbook
View file @ 3ef4b738
......@@ -672,8 +672,8 @@
<term><userinput>signing <optional>( -list | -clear <replaceable>keyid/algorithm</replaceable> | -clear <literal>all</literal> | -nsec3param ( <replaceable>parameters</replaceable> | <literal>none</literal> ) ) </optional> <replaceable>zone</replaceable> <optional><replaceable>class</replaceable> <optional><replaceable>view</replaceable></optional></optional> </userinput></term>
<listitem>
<para>
List, edit, or remove the DNSSEC signing state for
the specified zone. The status of ongoing DNSSEC
List, edit, or remove the DNSSEC signing state records
for the specified zone. The status of ongoing DNSSEC
operations (such as signing or generating
NSEC3 chains) is stored in the zone in the form
of DNS resource records of type
......
doc/arm/Bv9ARM-book.xml
View file @ 3ef4b738
......@@ -5704,34 +5704,34 @@ options {
</varlistentry>
 
<varlistentry>
<term><command>max-zone-ttl</command></term>
<listitem>
<para>
Specifies a maximum permissible TTL value.
When loading a zone file using a
<option>masterfile-format</option> of
<constant>text</constant> or <constant>raw</constant>,
any record encountered with a TTL higher than
<option>max-zone-ttl</option> will cause the zone to
be rejected.
</para>
<para>
This is useful in DNSSEC-signed zones because when
rolling to a new DNSKEY, the old key needs to remain
available until RRSIG records have expired from
caches. The<option>max-zone-ttl</option> option guarantees
that the largest TTL in the zone will be no higher
the set value.
</para>
<para>
(NOTE: Because <constant>map</constant>-format files
load directly into memory, this option cannot be
used with them.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><command>max-zone-ttl</command></term>
<listitem>
<para>
Specifies a maximum permissible TTL value.
When loading a zone file using a
<option>masterfile-format</option> of
<constant>text</constant> or <constant>raw</constant>,
any record encountered with a TTL higher than
<option>max-zone-ttl</option> will cause the zone to
be rejected.
</para>
<para>
This is useful in DNSSEC-signed zones because when
rolling to a new DNSKEY, the old key needs to remain
available until RRSIG records have expired from
caches. The<option>max-zone-ttl</option> option guarantees
that the largest TTL in the zone will be no higher
the set value.
</para>
<para>
(NOTE: Because <constant>map</constant>-format files
load directly into memory, this option cannot be
used with them.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><command>zone-statistics</command></term>
<listitem>
<para>
......@@ -6273,17 +6273,17 @@ options {
<para>
If <userinput>yes</userinput>, then a SIT (Source Identity
Token) EDNS option is sent along with the query. If the
resolver has previously talked to the server, the SIT
returned in the previous transaction is sent. This
is used by the server to determine whether the resolver
has talked to it before. A resolver sending the correct
SIT is assumed not to be an off-path attacker sending a
spoofed-source query; the query is therefore unlikely to
be part of a reflection/amplification attack, so resolvers
sending a correct SIT option are not subject to response
rate limiting (RRL). Resolvers which do not send a correct
SIT option may be limited to receiving smaller responses
via the <command>nosit-udp-size</command> option.
resolver has previously talked to the server, the SIT
returned in the previous transaction is sent. This
is used by the server to determine whether the resolver
has talked to it before. A resolver sending the correct
SIT is assumed not to be an off-path attacker sending a
spoofed-source query; the query is therefore unlikely to
be part of a reflection/amplification attack, so resolvers
sending a correct SIT option are not subject to response
rate limiting (RRL). Resolvers which do not send a correct
SIT option may be limited to receiving smaller responses
via the <command>nosit-udp-size</command> option.
</para>
</varlistentry>
 
......@@ -7271,53 +7271,53 @@ options {
<varlistentry>
<term><command>no-case-compress</command></term> <listitem>
<para>
Specifies a list of addresses which require responses
to use case-insensitive compression. This ACL can be
used when <command>named</command> needs to work with
clients that do not comply with the requirement in RFC
1034 to use case-insensitive name comparisons when
checking for matching domain names.
</para>
<para>
If left undefined, the ACL defaults to
<command>none</command>: case-insensitive compression
will be used for all clients. If the ACL is defined and
matches a client, then case will be ignored when
compressing domain names in DNS responses sent to that
client.
</para>
<para>
This can result in slightly smaller responses: if
a response contains the names "example.com" and
"example.COM", case-insensitive compression would treat
the second one as a duplicate. It also ensures
that the case of the query name exactly matches the
case of the owner names of returned records, rather
than matching the case of the records entered in
the zone file. This allows responses to exactly
match the query, which is required by some clients
due to incorrect use of case-sensitive comparisions.
</para>
<para>
Case-insensitive compression is <emphasis>always</emphasis>
used in AXFR and IXFR responses, regardless of whether
the client matches this ACL.
</para>
<para>
There are circusmstances in which <command>named</command>
will not preserve the case of owner names of records:
if a zone file defines records of different types with
the same name, but the capitalization of the name is
different (e.g., "www.example.com/A" and
"WWW.EXAMPLE.COM/AAAA"), then all resposnes for that
name will use the <emphasis>first</emphasis> version
of the name that was used in the zone file. This
limitation may be addressed in a future release. However,
domain names specified in the rdata of resource records
(i.e., records of type NS, MX, CNAME, etc) will always
have their case preserved unless the client matches this
ACL.
</para>
Specifies a list of addresses which require responses
to use case-insensitive compression. This ACL can be
used when <command>named</command> needs to work with
clients that do not comply with the requirement in RFC
1034 to use case-insensitive name comparisons when
checking for matching domain names.
</para>
<para>
If left undefined, the ACL defaults to
<command>none</command>: case-insensitive compression
will be used for all clients. If the ACL is defined and
matches a client, then case will be ignored when
compressing domain names in DNS responses sent to that
client.
</para>
<para>
This can result in slightly smaller responses: if
a response contains the names "example.com" and
"example.COM", case-insensitive compression would treat
the second one as a duplicate. It also ensures
that the case of the query name exactly matches the
case of the owner names of returned records, rather
than matching the case of the records entered in
the zone file. This allows responses to exactly
match the query, which is required by some clients
due to incorrect use of case-sensitive comparisions.
</para>
<para>
Case-insensitive compression is <emphasis>always</emphasis>
used in AXFR and IXFR responses, regardless of whether
the client matches this ACL.
</para>
<para>
There are circusmstances in which <command>named</command>
will not preserve the case of owner names of records:
if a zone file defines records of different types with
the same name, but the capitalization of the name is
different (e.g., "www.example.com/A" and
"WWW.EXAMPLE.COM/AAAA"), then all resposnes for that
name will use the <emphasis>first</emphasis> version
of the name that was used in the zone file. This
limitation may be addressed in a future release. However,
domain names specified in the rdata of resource records
(i.e., records of type NS, MX, CNAME, etc) will always
have their case preserved unless the client matches this
ACL.
</para>
</listitem>
</varlistentry>
 
......@@ -8675,7 +8675,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
<listitem>
<para>
Specify a private RDATA type to be used when generating
key signing records. The default is
signing state records. The default is
<literal>65534</literal>.
</para>
<para>
......@@ -8683,13 +8683,20 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
in a future version once there is a standard type.
</para>
<para>
These records can be removed from the zone once named
has completed signing the zone with the matching key
using <command>nsupdate</command> or
<command>rndc signing -clear</command>.
<command>rndc signing -clear</command> is the only supported
way to remove these records from
<command>inline-signing</command> zones.
Signing state records are used to internally by
<command>named</command> to track the current state of
a zone-signing process, i.e., whether it is still active
or has been completed. The records can be inspected
using the command
<command>rndc signing -list <replaceable>zone</replaceable></command>.
Once <command>named</command> has finished signing
a zone with a particular key, the signing state
record associated with that key can be removed from
the zone by running
<command>rndc signing -clear <replaceable>keyid/algorithm</replaceable> <replaceable>zone</replaceable></command>.
To clear all of the completed signing state
records for a zone, use
<command>rndc signing -clear all <replaceable>zone</replaceable></command>.
</para>
</listitem>
</varlistentry>
......@@ -9847,9 +9854,9 @@ deny-answer-aliases { "example.net"; };
DNSSEC requests (DO=1) unless <command>break-dnssec yes</command>
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.
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.
</para>
 
<para>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment