Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

[Brian Dickson <[e-mail]>]

On Fri, Jul 3, 2020 at 3:03 PM John R Levine <[e-mail]> wrote:

> On Fri, 3 Jul 2020, Brian Dickson wrote:
> > It makes clear the difference between implied and inferred.
> > The flag clearly indicates that some glue which would otherwise be
> > considered necessary has not been sent.
>
> That sounds a lot like the TC flag.  I realize that some people have
> interpreted the TC flag to mean something else, but I think its actual
> meaning is pretty clear.
>

Uh, no. The TC flag means "something didn't fit".
It is not restricted to glue, which is only in the additional section.
TC can also be set if something from the authority section didn't fit, or
if something didn't fit in the answer section.
(Obviously it would be the first section where something didn't fit that
matters.)

I'm suggesting this new "flag" (possibly an OPT TLV rather than actual flag
bit) only be used if TC is set for referral-not-optional glue.

This is a very distinct subset of ways that TC can be set.


>
> > Additionally, the flag would signal compliance with updated 1035, for
> > starters.
>
> This would in effect be a version number.  Our experience with version
> numbers in old protocols has not been great.
>
> > Also, it would facilitate lower effort in figuring out if a TC is
> referral
> > related or not, which could be important for implementers/operators doing
> > large scale stuff.
>
> I don't understand this.  Caches surely already know when a response is a
> referral.  If a referral response has TC set, in what way could that not
> be referral related?
>

See the words "large scale".
At large scale, the amount of work per referral matters a great deal.
(There are lots and lots of domains, and lots of places other than TLD->2LD
where referrals can and do occur.)

Just because a cache can figure out if a response is a referral, doesn't
mean doing so is currently trivial.
(Especially with all of the oddball implementations out there, plus older
versions of not-quite-oddball implementations.)

Having an easy way to identify a significant subset (the opposite of the
long tail) which make it easy to figure this out, seems like a win.


>
> > Most importantly, this is all about interoperability, including not just
> > the wire format but the operational signaling.
>
> Turning on bits that have been zero for 35 years doesn't have a great
> history of interop, either.  Look at the history of queries with EDNS0
> never getting a response.
>

Good point.

s/EDNS bit/EDNS OPT TLV/, and it should be good.

Or am I missing something else there?

Brian