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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop