This is confusing as hell, but we cannot fix that in the manual itself.
At least now the user is made aware of two distinct defaults.
(cherry picked from commit 405a0931ea)
All statements now use .. namedconf:statement:: or
.. rndcconf:statement:: syntax provided by our Sphinx extension.
This has several consequences:
- It changes how statement headings are rendered
- Statements are indexed and show up as separate items in doc
search results (in the HTML version)
- Statements can be linked to using either :any:`statement` or
:namedconf:ref:`statement` syntax (not used in this commit)
- Statements can be categorized and printed using ..
namedconf:statatementlist:: syntax (not used in this commit)
(cherry picked from commit e5b7022dcb)
To give a hint to users that get an error that the key lifetime is
shorter than the time it takes to do a rollover.
(cherry picked from commit c47735b86b)
Add a system test that checks whether IP addresses are present in a
dnstap capture of resolver traffic if "query-source" is explicitly set.
(cherry picked from commit 1f5c2ea8e5)
Warn users that server-side IP addresses are not stored in dnstap
captures of resolver traffic unless "query-source(-v6)" is explicitly
set, explaining why it is so.
(cherry picked from commit 366f7a938b)
The two procedures were essentially the same, but each instance was
missing some details from the other. They are now combined into one text
in the DNSSEC Guide and linked from DNSSEC chapter.
(cherry picked from commit 7d25027898)
Private Type Records are not specific to manually signing, so it is
better to move it to the end of the "Zone Signing" section shared by all
three methods.
(cherry picked from commit 5ba618fd28)
Mostly deduplicating and linking information across the ARM.
Generally people should not touch it unless they what they are doing, so
let's try to discourage them a bit.
(cherry picked from commit bffa3063f0)
Let's make more automated methods more prominent:
- KASP first
- dynamic updates second
- command-line tools only as last resort
(cherry picked from commit 28a533322b)
The goal is simplicity. Copy&paste to do the right thing, or read
referenced material and make up your mind if you need specialities.
NSEC discussion is already present in the DNSSEC guide so I merged
KASP examples with example for NSEC3 and removed NSEC text from the
DNSSEC chapter.
(cherry picked from commit 744763f8f2)
I've attempted to drop most of DNSSEC-specific jargon from the intro
paragraph, and to convince readers to read on.
(cherry picked from commit 0dc9c33149)
Use best practice values in examples that follow new guidance from
draft-ietf-dnsop-nsec3-guidance:
; SHA-1, no extra iterations, empty salt:
;
bcp.example. IN NSEC3PARAM 1 0 0 -
(cherry picked from commit 93601d8325)
Move this section up so that DNSSEC signing topics are grouped together
(and not split by the DNSSEC Validation chapter).
(cherry picked from commit 7824c5c967)
Restructure the section about dynamic zones and automatic signing:
- Focus on dynamic zones with 'auto-dnssec allow;'.
- Add a section about multi-signer models.
- Move NSEC3 related topics into one section.
- Remove any text that does not concern dynamic zones (mostly duplicate
text anyway).
(cherry picked from commit be54c08d2b)
Move bits from the "DNSSEC, Dynamic Zones, and Automatic Signing"
about denial of existence to a separate section below the "Key and
Signing Policy" section.
Add a brief introduction about denial of existence to this section.
(cherry picked from commit 71490a5a2d)
Restructure the first part of the DNSSEC chapter that deals with zone
signing. Put dnssec-policy first. Mention Key and Signing Policy.
Only then talk about the DNSSEC tools.
(cherry picked from commit a1c95e8e7c)
DNSSEC-bis is an uncommon term. Other servers are typically resolvers
and they usually are configured with the root key.
(cherry picked from commit fb24454c58)
