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

[Viktor Dukhovni <[e-mail]>]

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

> > These “rare” cases where the domain is not resolvable when a glue is not
> > present are the ones this draft is done for. So did you look how rare
> > they were in your dataset? Being able to resolve instead of not resolving
> > IMHO has value even if the number is not big.
> >
> > We all know that a lot of data in the DNS is garbage, that should not
> > stop us from using the good data.
> 
> 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.

Can we at least state that domains with cyclic dependencies are a bad
idea, and may not be supported by all resolvers.  In other words, that
the domain owner can't **rely** on the sibling glue recommended to be
sent in this draft to save the day.

My strong preference is still to delete all reference in the draft to
cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
sibling glue primarily as a performance optimisation, and secondarily
as a last resort when the nameserver IP addresses are wrong or gone
from the authoritative zone (another bad practice).

What should really happen is that broken sibling glue should be
regularly purged from public suffix registries (probably requires
gaining support for this in the RRR community more than IETF), and only
then does the remaining valid sibling glue become more of a help than a
hindrance.

- Please, if at all possible, drop the cyclic dependency anti-pattern from the draft.

- The "right" justification for sibling glue (in the minority of cases
  that is is valid, by domain cardinality, though admittedly perhaps not
  a minority by query volume) is then lower latency/cost to reach a
  usable server.

-- 
    Viktor.