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

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 04 July 2020 00:55 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4A33A07E1 for <dnsop@ietfa.amsl.com>; Fri, 3 Jul 2020 17:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAkMXTejtMHJ for <dnsop@ietfa.amsl.com>; Fri, 3 Jul 2020 17:55:28 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67BAD3A07D7 for <dnsop@ietf.org>; Fri, 3 Jul 2020 17:55:28 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id f24so17907313vsg.1 for <dnsop@ietf.org>; Fri, 03 Jul 2020 17:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9fU0D75cWhObBJa8Hh2V1ysGjh2ItFfw0p+UPYjSCq8=; b=Ri//bW6MLyJFPOSN72yo9MKu5ym3e4QBf8UcSm6MVUA3NQFKxfjLJ2Fxl1ubZSl0Nu RFBK5wTCY5pD1ZTIRrbZ4C1keDNuSj6yJYB5LyV8pL3vZV0+nehX9lCJcez9rg2ydUga dJkrraJLw+praEyW6wmW5nFPBeFdDh4UIq9bUTqawhPAv6mvZ8h+zOp+McTseNww3Qhp ooBqostnXv3dpsO949U3UnpSKUzucDTBexs7w7xTlTLlgC7Ydd9FHmMZQa+Yh61DM0Ih GNGAm2rSmZhtD5Y6lBlCkwW/VLg4gWqDHaqN1cegwjTvLYkzQ7t7qDJ1DE/E3jqgPb7k qSNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9fU0D75cWhObBJa8Hh2V1ysGjh2ItFfw0p+UPYjSCq8=; b=fBC5h5A35PzS/FykTFYGLTDpNgoXkKUuvloO7A1yX61Xs6Fcf8/D7tKXRwLqRq5xAC xGRJnBNLHFanhPkVQXI7nmZ/iwNhNzW0PHqjsDuW6uK+9CFCkNPKPNBc5Upzga81p+L7 0nJVeuyWRqfF4NyiYdqH2J8GYt3h6ApP9wO0kkGl9cL+HnMNpMWps/LrzlWxL6/FOdyh PPZC6nsUd9L22bkacyGMU3YSsnFf7w4WzL2SrNOVhWEdqUV66eMQiczGhL0ExHOYUXso rQxwJ99XJxpkprfuVI+MU4ODiqPFqEB+aMH7O2KE+0f+I80q1YdOYj0tU25BwZer7sLm i68w==
X-Gm-Message-State: AOAM531IVQJ/+wG/Jdp23TKnOD95McKeAy5NcIGmUHxpfuWK5FxmIF0X z4u1Cwsr+8xqOFznQ976cHDeml1YJkpKBnmqkiC7OA==
X-Google-Smtp-Source: ABdhPJzSCyzByfp/Jokwh3VIYn3KGzbsr9f8XvZi0X08SWwH3+xyPhVyymDYWMe70Nhd1RRmzybs+bBmRt0lWRZsH+4=
X-Received: by 2002:a67:2007:: with SMTP id g7mr28819336vsg.219.1593824127313; Fri, 03 Jul 2020 17:55:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAH1iCirMLsLmohChQCvqiS6ra0MYK40eJsDm_B5pMXAgXRnEpg@mail.gmail.com> <20200703175942.1D0441C485EE@ary.qy> <CAH1iCioMhnb=PthHEP6LB=BZBuB5CQpPzJ7h8uqYAXTjtn_8BQ@mail.gmail.com> <alpine.OSX.2.22.407.2007031758360.2180@ary.qy>
In-Reply-To: <alpine.OSX.2.22.407.2007031758360.2180@ary.qy>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 3 Jul 2020 17:55:16 -0700
Message-ID: <CAH1iCiqui42FdSEXECAMOFfFqHgnbpE6rMW99TgB9wU6JN-kcw@mail.gmail.com>
To: John R Levine <johnl@taugh.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f16c3a05a9931805"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NJP_sNMM5h5nUYDrjqtrZSPQeXg>
Subject: Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Jul 2020 00:55:30 -0000

On Fri, Jul 3, 2020 at 3:03 PM John R Levine <johnl@taugh.com> 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