メインコンテンツまでスキップ

Appendix A. Failure Scenarios due to Inconsistencies

Appendix A. Failure Scenarios due to Inconsistencies

A.1. DS Breakage due to Replication Lag

If an authoritative nameserver lags during a key rollover, the parent may see different CDS/CDNSKEY RRsets depending on which nameserver is queried. This can cause old and new DS RRsets to be deployed alternately and may break the chain of trust by removing a DNSKEY that is still referenced by a stale CDS/CDNSKEY RRset.

A.2. Escalation of Lame Delegation Takeover

If a delegation contains a nonexistent NS hostname, a third party can register that nameserver domain and run authoritative DNS service for domains delegated to it. Without consistency checks, an attacker can publish CDS/CDNSKEY records, cause the delegation to be secured with attacker-controlled DNSSEC keys, and then use CSYNC to remove other nameservers or change glue.

A.3. Multi-Provider (Permanent Multi-Signer)

In a permanent multi-signer setup, a provider might accidentally publish CDS/CDNSKEY records containing only its own keys. If the parent retrieves those records and removes the other providers' DS records, the zone breaks for some queries. A similar CSYNC problem can update the delegation to a flawed NS RRset, breaking resolution or silently reducing redundancy.

A.4. Bogus Provider Change (Temporary Multi-Signer)

During provider transfer without going insecure, the domain temporarily operates in multi-signer mode. If the new provider omits the old provider's keys from DNSKEY and CDS/CDNSKEY RRsets, DNSSEC validation can fail. If the parent scans and uses the incorrect CDS/CDNSKEY RRset, the old provider can be prematurely removed from the DNSSEC chain of trust.