Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni <[e-mail]>]

On Fri, Feb 17, 2023 at 01:55:40PM +0900, Masataka Ohta wrote:

> 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.

This is a very weak argument, because the two domains need not be in the
same TLD, and then sibling glue never happens.  The sibling glue IMHO
accomodates corner cases that are marginal to careless.

> >      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.

And yet, because it is particularly badly maintained, the overall
effect is IMHO negative.

On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:

> The cyclic dependency based sibling glue (Section 2.3) is arguably a
> bit of a corner case, and in past discussions some folks have
> expressed the view that we shouldn't make accommodations to support
> it. I think I can agree with that, but there were opposing views that
> we also shouldn't break configurations that currently work. So it was
> left in.

Sure, a parent domain *may* serve sibling glue if it so chooses, but I
would not lump it in with a "glue is not optional" RFC.  This gives
sibling glue too much "weight", and sets expectations that it SHOULD
be used when provided, but I'd be inclined to downplay its importance,
and any expectation that it will save the day when all else fails.

> The case of normal (non-circular) sibling glue, described in Section
> 2.2 is in my opinion useful though, and also extremely common - where
> it isn't necessarily required for resolution but allows resolvers to
> obviate additional follow-on queries (to the same servers) to obtain
> the sibling glue.  Previous lengthy discussions on this topic indicate
> a consensus to retain them, but not mandate their inclusion (or set
> TC=1 if message size limits are exceeded).

Can we leave its availability and treatment as *unspecified*?  I don't
have a rock solid case for never sending it, but I do think we'd be
better of if as little as possible of it were in fact provided and as
few as possible relied on it.

> Note that this document does not place any requirements on DNS
> resolvers, so if a resolver implementer chooses to, they can ignore
> sibling glue in referral responses, and/or explicitly fetch them.

And so my take is that it is in fact "optional".

-- 
    Viktor.