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

Peter van Dijk <peter.van.dijk@powerdns.com> Fri, 19 March 2021 11:24 UTC

Return-Path: <peter.van.dijk@powerdns.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 7476B3A0F2E for <dnsop@ietfa.amsl.com>; Fri, 19 Mar 2021 04:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nNswCG5SW28h for <dnsop@ietfa.amsl.com>; Fri, 19 Mar 2021 04:24:34 -0700 (PDT)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0D73A0F22 for <dnsop@ietf.org>; Fri, 19 Mar 2021 04:24:33 -0700 (PDT)
Received: from imap.open-xchange.com (imap.open-xchange.com [84.81.54.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id 2093C6A261; Fri, 19 Mar 2021 12:24:31 +0100 (CET)
Received: from plato ([84.81.54.175]) by imap.open-xchange.com with ESMTPSA id 2FMkB++JVGCsBgAA3c6Kzw (envelope-from <peter.van.dijk@powerdns.com>); Fri, 19 Mar 2021 12:24:31 +0100
Message-ID: <e2524a8ccdbd4619ef96edadc3b147e93445fc12.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: IETF DNSOP WG <dnsop@ietf.org>
Date: Fri, 19 Mar 2021 12:24:30 +0100
In-Reply-To: <CAH1iCirbWyKdQUbnqy7fBFGa=gJ3akk6AW2sdqyRavW2bfBwpg@mail.gmail.com>
References: <159123820967.306.12808925210425325877@ietfa.amsl.com> <B339E4C9-5F28-41A7-99C7-5B8ECC9CF14C@verisign.com> <E15EACC7-ACF3-4312-9D32-52E0860F668A@icann.org> <CAH1iCirbWyKdQUbnqy7fBFGa=gJ3akk6AW2sdqyRavW2bfBwpg@mail.gmail.com>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bpW-LQoNZO6OpmkoSGx3bjUb4gc>
Subject: Re: [DNSOP] [Ext] 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: Fri, 19 Mar 2021 11:24:36 -0000

On Thu, 2021-03-11 at 19:11 -0800, Brian Dickson wrote:
> From the status updates today, I see this draft has expired. I really like it (and it is quite simple), and would like to see it picked up and completed (adopted, rough consensus reached, published).
> 
> Having reread it and the discussion, I am wondering if useful guidance can be provided regarding the TC=1 and records added.
> 
> If as much glue as will fit is included, but not all glue fits, add all the glue that fits, and set TC=1.
> The resolver SHOULD attempt to use the available glue, but retry over TCP if none of the servers found via the available glue respond.

This sounds like something that might be very hard to fit into the flow
of at least some code bases out there.

> I.e. How is TC=1 interpreted currently by different implementations, and is THAT an issue that could/should be clarified, either in this document, or in a separate document?

Answered below for us.

> Is it necessary (at all) to mention keeping the glue that fits before setting TC=1?
> I don't think so, but maybe some commentary to that effect would be helpful?

When we (PowerDNS auth) set TC=1, we empty the packet, based on the
(somewhat under-argued) belief that different resolvers may draw
different conclusions from what is there and what is not, and emptyingthe packet avoids ambiguity. 

Mirroring that, if the PowerDNS Recursor receives a TC=1 response (with
rcode NOERROR or NXDOMAIN), no records are harvested and the whole
query is retried over TCP.

Based on only our choices, it is pointless to have any content in a
TC=1 response. Others may feel somewhat differently, of course!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/