Break a closed sibling dependency cycle

RFC 9471 §2.3 gives a cyclic sibling arrangement: foo.test uses name servers under bar.test, while bar.test uses name servers under foo.test. The parent test has their glue. Each child’s NS target remains a sibling, not in-domain for that child’s referral.

• RFC 9471 §2.3 gives a cyclic sibling arrangement: foo.test uses name servers under bar.test, while bar.test uses name servers under foo.test. The parent test has their glue. Each child’s NS target remains a sibling, not in-domain for that child’s referral.
• Our drawn fixture starts without cached server addresses, other usable name servers or another bootstrap path. To reach foo, the resolver needs a bar server address; to reach bar, it needs a foo server address. These are address-resolution dependencies, not packets already successfully delivered to either child.
• Withholding both sides’ sibling glue can therefore leave this fixture unable to start. A TC=0 referral that omits sibling glue for size is permitted by the §3.2 TC choice, yet users may still experience failure for cyclically dependent siblings. Permission is not a guarantee of successful resolution.
• Adding a usable parent-supplied address for ns1.bar.test. gives the resolver a first contact for foo.test. It can then continue obtaining the other needed address through ordinary DNS processing. The reachability helper models only this supplied dependency graph and seed-address set, not real cache state, validation or network success. Its nodes describe modeled address availability, not a trace of contacted servers.
• The RFC’s late 2021 survey found a small number of such arrangements (§2.3); this guide does not present those historical measurements as current prevalence or recommend cyclic delegation designs.