mirror of
https://gitlab.isc.org/isc-projects/bind9
synced 2025-08-30 05:57:52 +00:00
Merge branch 'matthijs-dnssec-guide-dnssec-policy-requires-inline-signing-v9_18' into 'v9_18'
[v9_18] Add dnssec-policy inline-signing requirement to documentation See merge request isc-projects/bind9!6832
This commit is contained in:
commit
c179933c09
@ -99,9 +99,13 @@ up-to-date DNSSEC practices:
|
||||
type primary;
|
||||
file "dnssec.example.db";
|
||||
dnssec-policy default;
|
||||
inline-signing yes;
|
||||
};
|
||||
|
||||
This single line is sufficient to create the necessary signing keys, and generate
|
||||
The :any:`dnssec-policy` statement requires dynamic DNS to be set up, or
|
||||
:any:`inline-signing` to be enabled. In the example above we use the latter.
|
||||
|
||||
This is sufficient to create the necessary signing keys, and generate
|
||||
``DNSKEY``, ``RRSIG``, and ``NSEC`` records for the zone. BIND also takes
|
||||
care of any DNSSEC maintenance for this zone, including replacing signatures
|
||||
that are about to expire and managing :ref:`key_rollovers`.
|
||||
@ -171,6 +175,7 @@ by configuring parental agents:
|
||||
type primary;
|
||||
file "dnssec.example.db";
|
||||
dnssec-policy default;
|
||||
inline-signing yes;
|
||||
parental-agents { 192.0.2.1; };
|
||||
};
|
||||
|
||||
|
@ -6339,12 +6339,16 @@ zone is generated even if they have the same policy. If multiple views
|
||||
are configured with different versions of the same zone, each separate
|
||||
version uses the same set of signing keys.
|
||||
|
||||
By default, :any:`dnssec-policy` assumes :any:`inline-signing`. This means that
|
||||
a signed version of the zone is maintained separately and is written out to
|
||||
a different file on disk (the zone's filename plus a ``.signed`` extension).
|
||||
The :any:`dnssec-policy` statement requires dynamic DNS to be set up, or
|
||||
:any:`inline-signing` to be enabled.
|
||||
|
||||
If :any:`inline-signing` is enabled, this means that a signed version of the
|
||||
zone is maintained separately and is written out to a different file on disk
|
||||
(the zone's filename plus a ``.signed`` extension).
|
||||
|
||||
If the zone is dynamic because it is configured with an :any:`update-policy` or
|
||||
:any:`allow-update`, the DNSSEC records are written to the filename set in the original zone's :any:`file`, unless :any:`inline-signing` is explicitly set.
|
||||
:any:`allow-update`, the DNSSEC records are written to the filename set in the
|
||||
original zone's :any:`file`, unless :any:`inline-signing` is explicitly set.
|
||||
|
||||
Key rollover timing is computed for each key according to the key
|
||||
lifetime defined in the KASP. The lifetime may be modified by zone TTLs
|
||||
|
@ -63,6 +63,7 @@ what the :iscman:`named.conf` zone statement looks like on the primary server, 1
|
||||
file "db/example.com.db";
|
||||
key-directory "keys/example.com";
|
||||
dnssec-policy default;
|
||||
inline-signing yes;
|
||||
allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
|
||||
};
|
||||
|
||||
@ -142,6 +143,7 @@ signed data via zone transfer to the other three DNS secondaries. Its
|
||||
file "db/example.com.db";
|
||||
key-directory "keys/example.com";
|
||||
dnssec-policy default;
|
||||
inline-signing yes;
|
||||
allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
|
||||
};
|
||||
|
||||
@ -995,6 +997,7 @@ Here is what :iscman:`named.conf` looks like when it is signed:
|
||||
type primary;
|
||||
file "db/example.com.db";
|
||||
dnssec-policy "default";
|
||||
inline-signing yes;
|
||||
};
|
||||
|
||||
To indicate the reversion to unsigned, change the :any:`dnssec-policy` line:
|
||||
@ -1006,6 +1009,7 @@ To indicate the reversion to unsigned, change the :any:`dnssec-policy` line:
|
||||
type primary;
|
||||
file "db/example.com.db";
|
||||
dnssec-policy "insecure";
|
||||
inline-signing yes;
|
||||
};
|
||||
|
||||
Then use :option:`rndc reload` to reload the zone.
|
||||
|
@ -66,6 +66,7 @@ To sign a zone, add the following statement to its
|
||||
zone "example.com" in {
|
||||
...
|
||||
dnssec-policy default;
|
||||
inline-signing yes;
|
||||
...
|
||||
};
|
||||
|
||||
@ -77,6 +78,17 @@ for most situations. We cover the creation of a custom policy in
|
||||
:ref:`signing_custom_policy`, but for the moment we are accepting the
|
||||
default values.
|
||||
|
||||
Using :any:`dnssec-policy` requires dynamic DNS or :any:`inline-signing`
|
||||
to be enabled.
|
||||
|
||||
.. note::
|
||||
|
||||
Previously, if a zone with a :any:`dnssec-policy` did not have dynamic
|
||||
DNS set up and :any:`inline-signing` was not explicity set, BIND 9 used
|
||||
inline-signing implicitly. But this caused a lot of problems when operators
|
||||
switched on or off dynamic DNS for their zones. Therefor, you now have to
|
||||
configure it explicitly.
|
||||
|
||||
When the configuration file is updated, tell :iscman:`named` to
|
||||
reload the configuration file by running :option:`rndc reconfig`:
|
||||
|
||||
@ -823,6 +835,7 @@ this example, we'll add it to the :any:`zone` statement:
|
||||
zone "example.net" in {
|
||||
...
|
||||
dnssec-policy standard;
|
||||
inline-signing yes;
|
||||
...
|
||||
};
|
||||
|
||||
@ -904,6 +917,7 @@ presence. Let's look at the following configuration excerpt:
|
||||
zone "example.net" in {
|
||||
...
|
||||
dnssec-policy standard;
|
||||
inline-signing yes;
|
||||
parental-agents { "net"; };
|
||||
...
|
||||
};
|
||||
@ -1358,9 +1372,8 @@ repeated here. A few points are worth noting, though:
|
||||
- The :any:`dnssec-policy` statement in the :iscman:`named` configuration file
|
||||
describes all aspects of the DNSSEC policy, including the signing.
|
||||
|
||||
- When using :any:`dnssec-policy`, there is no need to set the
|
||||
:any:`auto-dnssec` and :any:`inline-signing` options for a zone. The zone's
|
||||
``policy`` statement implicitly does this.
|
||||
- The :any:`dnssec-policy` statement requires to zone to use dynamic DNS,
|
||||
or that :any:`inline-signing` is enabled.
|
||||
|
||||
.. _advanced_discussions_manual_key_management_and_signing:
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user