On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni <ietf-d...@dukhovni.org> 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
