Since October 2019 I have had complaints from `dnssec-cds` reporting
that the signatures on some of my test zones had expired. These were
zones signed by BIND 9.15 or 9.17, with a DNSKEY TTL of 24h and
`sig-validity-interval 10 8`.
This is the same setup we have used for our production zones since
2015, which is intended to re-sign the zones every 2 days, keeping
at least 8 days signature validity. The SOA expire interval is 7
days, so even in the presence of zone transfer problems, no-one
should ever see expired signatures. (These timers are a bit too
tight to be completely correct, because I should have increased
the expiry timers when I increased the DNSKEY TTLs from 1h to 24h.
But that should only matter when zone transfers are broken, which
was not the case for the error reports that led to this patch.)
For example, this morning my test zone contained:
dev.dns.cam.ac.uk. 86400 IN RRSIG DNSKEY 13 5 86400 (
20200701221418 20200621213022 ...)
But one of my resolvers had cached:
dev.dns.cam.ac.uk. 21424 IN RRSIG DNSKEY 13 5 86400 (
20200622063022 20200612061136 ...)
This TTL was captured at 20200622105807 so the resolver cached the
RRset 64976 seconds previously (18h02m56s), at 20200621165511
only about 12h before expiry.
The other symptom of this error was incorrect `resign` times in
the output from `rndc zonestatus`.
For example, I have configured a test zone
zone fast.dotat.at {
file "../u/z/fast.dotat.at";
type primary;
auto-dnssec maintain;
sig-validity-interval 500 499;
};
The zone is reset to a minimal zone containing only SOA and NS
records, and when `named` starts it loads and signs the zone. After
that, `rndc zonestatus` reports:
next resign node: fast.dotat.at/NS
next resign time: Fri, 28 May 2021 12:48:47 GMT
The resign time should be within the next 24h, but instead it is
near the signature expiry time, which the RRSIG(NS) says is
20210618074847. (Note 499 hours is a bit more than 20 days.)
May/June 2021 is less than 500 days from now because expiry time
jitter is applied to the NS records.
Using this test I bisected this bug to 09990672d which contained a
mistake leading to the resigning interval always being calculated in
hours, when days are expected.
This bug only occurs for configurations that use the two-argument form
of `sig-validity-interval`.
(cherry picked from commit 030674b2a3)
these keywords were added to the parser as synonyms for "master"
and "slave" but were never hooked in to the configuration of named,
so they were ignored. this has been fixed and the option is now
checked for correctness.
(cherry picked from commit ba31b189b4)
The first attempt to add DNSSEC sign statistics was naive: for each
zone we allocated 64K counters, twice. In reality each zone has at
most four keys, so the new approach only has room for four keys per
zone. If after a rollover more keys have signed the zone, existing
keys are rotated out.
The DNSSEC sign statistics has three counters per key, so twelve
counters per zone. First counter is actually a key id, so it is
clear what key contributed to the metrics. The second counter
tracks the number of generated signatures, and the third tracks
how many of those are refreshes.
This means that in the zone structure we no longer need two separate
references to DNSSEC sign metrics: both the resign and refresh stats
are kept in a single dns_stats structure.
Incrementing dnssecsignstats:
Whenever a dnssecsignstat is incremented, we look up the key id
to see if we already are counting metrics for this key. If so,
we update the corresponding operation counter (resign or
refresh).
If the key is new, store the value in a new counter and increment
corresponding counter.
If all slots are full, we rotate the keys and overwrite the last
slot with the new key.
Dumping dnssecsignstats:
Dumping dnssecsignstats is no longer a simple wrapper around
isc_stats_dump, but uses the same principle. The difference is that
rather than dumping the index (key tag) and counter, we have to look
up the corresponding counter.
(cherry picked from commit 705810d577)
some empty conditional branches which contained a semicolon were
"fixed" by clang-format to contain nothing. add comments to prevent this.
(cherry picked from commit 735be3b816)
adjust clang-format options to get closer to ISC style
See merge request isc-projects/bind9!3061
(cherry picked from commit d3b49b6675)
0255a974 revise .clang-format and add a C formatting script in util
e851ed0b apply the modified style
Add curly braces using uncrustify and then reformat with clang-format back
Closes#46
See merge request isc-projects/bind9!3057
(cherry picked from commit 67b68e06ad)
36c6105e Use coccinelle to add braces to nested single line statement
d14bb713 Add copy of run-clang-tidy that can fixup the filepaths
056e133c Use clang-tidy to add curly braces around one-line statements
Reformat source code with clang-format
Closes#46
See merge request isc-projects/bind9!2156
(cherry picked from commit 7099e79a9b)
4c3b063e Import Linux kernel .clang-format with small modifications
f50b1e06 Use clang-format to reformat the source files
11341c76 Update the definition files for Windows
df6c1f76 Remove tkey_test (which is no-op anyway)
'dnssec-policy' can now also be set on the options and view level and
a zone that does not set 'dnssec-policy' explicitly will inherit it
from the view or options level.
This requires a new keyword to be introduced: 'none'. If set to
'none' the zone will not be DNSSEC maintained, in other words it will
stay unsigned. You can use this to break the inheritance. Of course
you can also break the inheritance by referring to a different
policy.
The keywords 'default' and 'none' are not allowed when configuring
your own dnssec-policy statement.
Add appropriate tests for checking the configuration (checkconf)
and add tests to the kasp system test to verify the inheritance
works.
Edit the kasp system test such that it can deal with unsigned zones
and views (so setting a TSIG on the query).
If a zone has a dnssec-policy set, use signature validity,
dnskey signature validity, and signature refresh from
dnssec-policy.
Zones configured with 'dnssec-policy' will allow 'named' to create
DNSSEC keys (similar to dnssec-keymgr) if not available.
The ttlval configuration types are replaced by duration configuration
types. The duration is an ISO 8601 duration that is going to be used
for DNSSEC key timings such as key lifetimes, signature resign
intervals and refresh periods, etc. But it is also still allowed to
use the BIND ttlval ways of configuring intervals (number plus
optional unit).
A duration is stored as an array of 7 different time parts.
A duration can either be expressed in weeks, or in a combination of
the other datetime indicators.
Add several unit tests to ensure the correct value is parsed given
different string values.
This second commit uses second semantic patch to replace the calls to
dns_name_copy() with NULL as third argument where the result was stored in a
isc_result_t variable. As the dns_name_copy(..., NULL) cannot fail gracefully
when the third argument is NULL, it was just a bunch of dead code.
Couple of manual tweaks (removing dead labels and unused variables) were
manually applied on top of the semantic patch.
- removed some dead code
- dns_zone_setdbtype is now void as it could no longer return
anything but ISC_R_SUCCESS; calls to it no longer check for a result
- controlkeylist_fromconfig() is also now void
- fixed a whitespace error
In addition to gather how many times signatures are created per
key in a zone, also count how many of those signature creations are
because of DNSSEC maintenance. These maintenance counters are
incremented if a signature is refreshed (but the RRset did not
changed), when the DNSKEY RRset is changed, and when that leads
to additional RRset / RRSIG updates (for example SOA, NSEC).
While implementing the new unit testing framework cmocka, it was found that the
BIND 9 code doesn't compile when assertions are disabled or replaced with any
function (such as mock_assert() from cmocka unit testing framework) that's not
directly recognized as assertion by the compiler.
This made the compiler to complain about blocks of code that was recognized as
unreachable before, but now it isn't.
The changes in this commit include:
* assigns default values to couple of local variables,
* moves some return statements around INSIST assertions,
* adds __builtin_unreachable(); annotations after some INSIST assertions,
* fixes one broken assertion (= instead of ==)
To minimize the effort required to set up IANA root zone mirroring,
define a default master server list for the root zone and use it when
that zone is to be mirrored and no master server list was explicitly
specified. Contents of that list are taken from RFC 7706 and are
subject to change in future releases.
Since the static get_masters_def() function in bin/named/config.c does
exactly what named_zone_configure() in bin/named/zoneconf.c needs to do,
make the former non-static and use it in the latter to prevent code
duplication.
Previous way of handling NOTIFY settings for mirror zones was a bit
tricky: any value of the "notify" option was accepted, but it was
subsequently overridden with dns_notifytype_explicit. Given the way
zone configuration is performed, this resulted in the following
behavior:
- if "notify yes;" was set explicitly at any configuration level or
inherited from default configuration, it was silently changed and so
only hosts specified in "also-notify", if any, were notified,
- if "notify no;" was set at any configuration level, it was
effectively honored since even though zone->notifytype was silently
set to dns_notifytype_explicit, the "also-notify" option was never
processed due to "notify no;" being set.
Effectively, this only allowed the hosts specified in "also-notify" to
be notified, when either "notify yes;" or "notify explicit;" was
explicitly set or inherited from default configuration.
Clean up handling of NOTIFY settings for mirror zones by:
- reporting a configuration error when anything else than "notify no;"
or "notify explicit;" is set for a mirror zone at the zone level,
- overriding inherited "notify yes;" setting with "notify explicit;"
for mirror zones,
- informing the user when the "notify" setting is overridden, unless
the setting in question was inherited from default configuration.
Use a zone's 'type' field instead of the value of its DNS_ZONEOPT_MIRROR
option for checking whether it is a mirror zone. This makes said zone
option and its associated helper function, dns_zone_mirror(), redundant,
so remove them. Remove a check specific to mirror zones from
named_zone_reusable() since another check in that function ensures that
changing a zone's type prevents it from being reused during
reconfiguration.
Rather than overloading dns_zone_slave and discerning between a slave
zone and a mirror zone using a zone option, define a separate enum
value, dns_zone_mirror, to be used exclusively by mirror zones. Update
code handling slave zones to ensure it also handles mirror zones where
applicable.
Update named_zone_reusable() so that it does not consider a zone to be
eligible for reuse if its old value of the "mirror" option differs from
the new one. This causes "rndc reconfig" to create a new zone structure
whenever the value of the "mirror" option is changed, which ensures that
the previous zone database is not reused and that flags are properly set
in responses sourced from zones whose "mirror" setting was changed at
runtime.
Since the mirror zone feature is expected to mostly be used for the root
zone, prevent slaves from sending NOTIFY messages for mirror zones by
default. Retain the possibility to use "also-notify" as it might be
useful in certain cases.
As mirror zone data should be treated the way validated, cached DNS
responses are, outgoing mirror zone transfers should be disabled unless
they are explicitly enabled by zone configuration.
Add a new slave-only boolean configuration option, "mirror", along with
its corresponding dns_zoneopt_t enum and a helper function for checking
whether that option was set for a given zone. This commit does not
introduce any behavior changes yet.
- mark the 'geoip-use-ecs' option obsolete; warn when it is used
in named.conf
- prohibit 'ecs' ACL tags in named.conf; note that this is a fatal error
since simply ignoring the tags could make ACLs behave unpredictably
- re-simplify the radix and iptable code
- clean up dns_acl_match(), dns_aclelement_match(), dns_acl_allowed()
and dns_geoip_match() so they no longer take ecs options
- remove the ECS-specific unit and system test cases
- remove references to ECS from the ARM
Replace dns_fixedname_init() calls followed by dns_fixedname_name()
calls with calls to dns_fixedname_initname() where it is possible
without affecting current behavior and/or performance.
This patch was mostly prepared using Coccinelle and the following
semantic patch:
@@
expression fixedname, name;
@@
- dns_fixedname_init(&fixedname);
...
- name = dns_fixedname_name(&fixedname);
+ name = dns_fixedname_initname(&fixedname);
The resulting set of changes was then manually reviewed to exclude false
positives and apply minor tweaks.
It is likely that more occurrences of this pattern can be refactored in
an identical way. This commit only takes care of the low-hanging fruit.
4762. [func] "update-policy local" is now restricted to updates
from local addresses. (Previously, other addresses
were allowed so long as updates were signed by the
local session key.) [RT #45492]
