I wanted to respond to this thread earlier, so apologies in advance for late posting and if this is a no-op at this point. Me getting confused about the last call for this draft (https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/) and https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ being combined didn't help either.
The draft does not contain any reference to the rfc8499bis I-D or to RFC 8499. It would be helpful to have a reference. On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque <shu...@gmail.com> wrote: > > On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett <m...@conundrum.com> wrote: >> >> >> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen <pe...@desec.io> wrote: >>> >>> >>> >>> On 3/28/23 03:14, Shumon Huque wrote: >>> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni <ietf-d...@dukhovni.org >>> > <mailto:ietf-d...@dukhovni.org>> wrote: >>> > >>> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote: >>> > 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. >>> >>> I support adding such a statement about cyclic dependencies. >> >> >> As do I. >> >> >>> >>> >>> In addition, I would support saying that data suggests that, while >>> (non-cyclic) glue records may have a benefit in certain cases, they >>> frequently are a source of harm (time-outs), and the trade-off remains >>> unclear. >> >> >> I would support this as well. >> >> In my anecdotal experience as an operator, I routinely encounter mismatches >> in sibling glue and child zone NS sets that appear to be due to the glue >> being forgotten. My assumption is that, because it's not necessary to >> operate, when operators fail to update it they don't receive any kind of >> signal that something is wrong. >> >> Viktor's numbers are pretty clear data, though, so nobody should need my >> anecdotes to be convinced. While sibling glue may be a useful optimisation >> in some cases, given how poorly maintained it is it seems to cause more >> problems than it solves. If it's not too late in the process: Given the numbers presented upthread, at a minimum could we have one sentence in section 2.3 Glue Cyclic Sibling Domain Name Server, discouraging implementers from doing this? >> > > I'd like to remind folks that the scope of this draft when it was adopted by > the working group was very narrow. Mainly to say that 'required' glue must > set TC=1 if it doesn't fit into the DNS response payload. That required > talking about other types of non-mandatory glue like sibling, but has not > proposed to change authoritative server behavior in those areas. > > If folks want to deprecate sibling glue entirely, it would be best to write > another draft saying that and see if we can get consensus on that. This is a reasonable position. Sending a separate email. -Puneet > > Shumon. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
