Re: [Add] Comparative DoH Discovery DNS RR Types

Paul Wouters <paul@nohats.ca> Wed, 01 July 2020 01:10 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581573A085C for <add@ietfa.amsl.com>; Tue, 30 Jun 2020 18:10:00 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 eawE1AzfOsbK for <add@ietfa.amsl.com>; Tue, 30 Jun 2020 18:09:59 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 E07F33A085B for <add@ietf.org>; Tue, 30 Jun 2020 18:09:58 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49xNS523X2zLkS; Wed, 1 Jul 2020 03:09:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1593565797; bh=CCQJQZ6wqNqUytvkahpzv6dC+Y8LzNBfVB4wlRkdPVc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TCK3nwHl17byOjXvPv21TsEdTOL2CyEuzf0OKunHEWCDSPPaCqIsvtC54F+9rOybc /2tlVZpM0Nz2Ag4TfngfqSx0Lh3jVIGdFXuaaV0PCDrpTEnxfAwRxDb4mDC7tLNSwl odaaxWJogoW/4NZAJOH6+szdUm+fs8F8TfFjKFC4=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DwsWVI02SpfI; Wed, 1 Jul 2020 03:09:56 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Jul 2020 03:09:56 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id C15966020EC4; Mon, 29 Jun 2020 20:34:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B8A3B66ADE; Mon, 29 Jun 2020 20:34:46 -0400 (EDT)
Date: Mon, 29 Jun 2020 20:34:46 -0400
From: Paul Wouters <paul@nohats.ca>
To: Paul Vixie <paul@redbarn.org>
cc: ADD Mailing list <add@ietf.org>
In-Reply-To: <26559974.PdTMpzyJZD@linux-9daj>
Message-ID: <alpine.LRH.2.23.451.2006292030190.129764@bofh.nohats.ca>
References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/3nBRwjZf5gOq0WO4GdfyAG5Liaw>
Subject: Re: [Add] Comparative DoH Discovery DNS RR Types
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 01:10:00 -0000

On Mon, 29 Jun 2020, Paul Vixie wrote:

> if on the other hand we're going to continue to evolve DNS in ways that
> include adding new RR types, and all the initiators who are stuck behind
> dumbass middleboxes who reject or butcher unknown RR types are going to fail
> hard and be excluded from the new applications and protocols in order to put
> more pressure on middlebox users/makers/distributors, we should say that.

I fully agree with Paul V here, but I do want to point out that in this
case, we _might_ want an exception to this because this is a mechanism
to find and get to a well working modern DNS resolver. We are specifically
using some crappy old hotspot technology DNS to gain access to proper
DNS.

For everything else, I agree to just do the RRTYPE. And once we have
the mechanism to get to a proper modern DNS resolver, never come to IETF
again with proposals that hack or overload existing RRTYPEs.

And even in this case, perhaps we should insist on defining both, so we
can kill the hack in 10-15 years.

Paul