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

To follow up with Shumon and Duane's comments, the title of the document
was changed over time to "DNS Glue Requirements in Referral Responses" to
more accurately reflect the document's contents.
The datatracker name did not change to reflect that.
tim

On Tue, Mar 28, 2023 at 9:58 PM Wessels, Duane <dwessels=
40verisign.com@dmarc.ietf.org> wrote:

>
>
> > On Mar 29, 2023, at 10:53 AM, Shumon Huque <shuque@gmail.com> wrote:
> >
> > On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett <matt@conundrum.com>
> wrote:
> >
> > On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen <peter@desec.io> wrote:
> >
> >
> > On 3/28/23 03:14, Shumon Huque wrote:
> > > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni <
> ietf-dane@dukhovni.org <mailto:ietf-dane@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.
> >
> >
> > 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.
> >
>
> I agree with this position.  The scope of the draft is about message size
> and behavior when glue records don’t fit.  Although the “glue is not
> optional” name is catchy, in hindsight I think a different name would
> better reflect the intent of the document.
>
> DW
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>