012ca0a27d
Calling nextpart() after reconfiguring ns1 is not safe, because the
expected log message may appear in ns5/named.run before nextpart() is
run. With the TTL for ./DNSKEY set to 20 seconds, ns5 will refresh it
after 10 seconds, by which time wait_for_log() will already have failed.
This results in a false negative.
However, just calling nextpart() before reconfiguring ns1 would
introduce a different problem: if ns5 refreshed ./DNSKEY between these
two steps, the subsequent wait_for_log() call would return immediately
as it would come across the log message about a failure while refreshing
./DNSKEY instead of the expected success. This in turn would result in
a different false negative as the root key would still be uninitialized
by the time "rndc secroots" is called.
Prevent both kinds of false negatives by:
- calling nextpart() before reconfiguring ns1, in order to prevent the
first case described above,
- looking for a more specific log message, in order to prevent the
second case described above.
Also look for a more specific log message in the first part of the
relevant check, not to fix any problem, but just to emphasize that a
different fetch result is expected in that case.
With these tweaks in place, if a (failed) ./DNSKEY refresh is scheduled
between nextpart() and reconfiguring ns1, wait_for_log() will just wait
for two more seconds (one "hour"), at which point another refresh
attempt will be made that will succeed.
Copyright (C) 2015-2018 Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
This is for testing managed-keys, in particular with problems
with RFC 5011 Automated Updates of DNSSEC Trust Anchors.
ns1 is the root server that offers new KSKs and hosts one record for
testing. The TTL for the zone's records is 2 seconds.
ns2 is a validator that uses managed-keys. "-T mkeytimers=2/20/40"
is used so it will attempt do automated updates frequently. "-T tat=1"
is used so it will send TAT queries once per second.
ns3 is a validator with a broken key in managed-keys.
ns4 is a validator with a deliberately broken managed-keys.bind and
managed-keys.jnl, causing RFC 5011 initialization to fail.
ns5 is a validator which is prevented from getting a response from the
root server, causing key refresh queries to fail.