Viktor Dukhovni wrote:

> The draft states that in rare cases sibling glue could be useful, as a
> result of cyclic dependency loops.

Interesting. Such dependency existed between two TLDs (IIRC
"edu" and "org") 20 or 30 years ago and I thought and still
think there are redundancy issues.

That is, the example in the draft is insufficient
and, at least, the following should be an additional
example:

   bar.test.                  86400   IN NS      ns1.foo.test.
   bar.test.                  86400   IN NS      ns2.foo.test.

   foo.test.                  86400   IN NS      ns1.foo.test.
   foo.test.                  86400   IN NS      ns1.bar.test.
   foo.test.                  86400   IN NS      ns2.bar.test.

in which case, without sibling glue, if ns1.foo.test goes
down, name resolutions of both zones become impossible,
which should not satisfy minimum required redundancy
of DNS.

If zones have local redundancy policy to allow two or more (N)
name servers simuntaneously go down, which should be the cases
with zones having (N+1) name servers, more examples can be
constructed. For example:

   bar.test.                  86400   IN NS      ns1.foo.test.
   bar.test.                  86400   IN NS      ns2.foo.test.
   bar.test.                  86400   IN NS      ns1.bar.test.

   foo.test.                  86400   IN NS      ns1.foo.test.
   foo.test.                  86400   IN NS      ns1.bar.test.
   foo.test.                  86400   IN NS      ns2.bar.test.

suffers, if two in-zone name servers go down.

     In late 2021 the authors analyzed zone file data available from
     ICANN's Centralized Zone Data Service [CZDS] and found 222 out of
     approximately 209,000,000 total delegations that had only sibling
     domain NS RRs in a cyclic dependency as above.

"only sibling domain NS RRs"?

If my examples above are considered, there should be more cases.

                                                Masataka Ohta

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to