Copyright (C) Internet Systems Consortium, Inc. ("ISC")
SPDX-License-Identifier: MPL-2.0
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 https://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
The test setup for the checkds tests.
These servers are parent servers:
- ns1 is the root server.
- ns2 is a primary authoritative server that serves the parent zone for zones
configured in ns9.
- ns4 is the secondary server for ns2.
- ns8 is the secondary server for ns2 that is not part of the NS RRset,
used for testing explicit parental-agents.
- ns5 is a primary authoritative server that serves the parent zone for zones
configured in ns9, but this one does not publish DS records (to test cases
where the DS is missing and the DS needs to be withdrawn).
- ns7 is the secondary server for ns5.
- ns10 is the secondary server for ns5 that is not part of the NS RRset,
used for testing explicit parental-agents.
- ns6 is an authoritative server for a different zone, to test badly configured
parental agents.
- ns3 is a resolver that can be configured as a parental agent.
- Finally, ns9 is the authoritative server for the various DNSSEC enabled test
domains.
We need multiple test cases for testing the "checkds" functionality. Basically,
the behavior of "checkds" is of importance in three cases:
1. Enabling DNSSEC
2. KSK rollover
3. Going insecure
All these three cases involve publishing DS records into the parent, and
withdrawing them. The named instance is responsible for checking that the
relevant DS records are published or removed from the parent zone. Therefor,
it needs to know what the parental agents are (the servers that it can send
the DS queries to).
Then there are two ways of retrieving parental agents, either through explicit
configuration ("checkds explicit;"), or through discovery ("checkds yes;"). In
the latter case, the parental agents are retrieved by querying for the parent NS
RRset.
The third value is "checkds no;", which disables the feature.
Depending on the DS publication status, the DS state of the key needs to be
updated. In case of DS publication, the "DSPublish" state should be set, only
if all parental agents have the relevant DS published. In case of DS withdrawal,
the "DSRemoved" state should be set, only if none of the parental agents have
the relevant DS in their zone.
Regardless of how parental agents are retrieved, we identify the following test
cases:
1. Enabling DNSSEC
1.1. - With one parental agent
1.1.1. - DS is correctly published in the parent: DSPublish
1.1.2. - DS is not (yet) published in the parent: !DSPublish
1.1.3. - The parental agent is badly configured: !DSPublish
1.1.4. - DS is published, but has bogus signature: !DSPublish
1.2. - With multiple parental agents
1.2.1. - DS is correctly published in all parents: DSPublish
1.2.2. - DS is not (yet) published in some parents: !DSPublish
1.2.3. - One parental agent is badly configured: !DSPublish
1.2.4. - DS is completely published, bogus signature: !DSPublish
2. Going insecure
2.1. - With one parental agent
2.1.1. - DS is correctly withdrawn from the parent: DSRemoved
2.1.2. - DS is (still) published in the parent: !DSRemoved
2.1.3. - The parental agent is badly configured: !DSRemoved
2.1.4. - DS is withdrawn, but has bogus signature: !DSRemoved
2.2. - With multiple parental agents
2.2.1. - DS is correctly withdrawn from all parents: DSRemoved
2.2.2. - DS is not (yet) withdrawn from some parents: !DSRemoved
2.2.3. - One parental agent is badly configured: !DSRemoved
2.2.4. - DS is removed completely, bogus signature: !DSRemoved
We deliberately don't test the "KSK Rollover" case in this system test as this
can be considered as the same as "Enabling DNSSEC" for one key and
"Going insecure" for another case. In other words, it is covered by the two
other scenarios (although we might still add the test cases in the future).
