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

[Shumon Huque <[e-mail]>]

On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni <[e-mail]>
wrote:

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

Viktor - I've so far not seen many other people speak up in support of your
position. I suspect this is because this draft was discussed to death many
months ago during long discussion threads on the list, and there is likely
already rough consensus for the current content. Personally, I would be ok
with adding a statement that configurations involving cyclic dependencies
are not recommended, but others will likely have to also speak up in support
of this too.

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.


Yes, I agree that this is the real area of work that could improve the
situation,
but probably outside of the scope of what the IETF can influence. If you
want
to organize an effort to do something about this in the ICANN/RRR community,
I suspect you might be able to recruit some of us into helping.

Shumon.