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
- [Add] Comparative DoH Discovery DNS RR Types Livingood, Jason
- Re: [Add] Comparative DoH Discovery DNS RR Types Paul Vixie
- [Add] DNS and middleboxes (was Re: Comparative Do… Adam Roach
- Re: [Add] Comparative DoH Discovery DNS RR Types Tommy Pauly
- Re: [Add] Comparative DoH Discovery DNS RR Types Michael Richardson
- Re: [Add] Comparative DoH Discovery DNS RR Types Daniel Migault
- Re: [Add] Comparative DoH Discovery DNS RR Types Christian Huitema
- Re: [Add] Comparative DoH Discovery DNS RR Types Martin Thomson
- Re: [Add] Comparative DoH Discovery DNS RR Types Paul Vixie
- Re: [Add] Comparative DoH Discovery DNS RR Types Rob Sayre
- Re: [Add] Comparative DoH Discovery DNS RR Types dagon
- Re: [Add] Comparative DoH Discovery DNS RR Types tirumal reddy
- Re: [Add] Comparative DoH Discovery DNS RR Types tirumal reddy
- Re: [Add] Comparative DoH Discovery DNS RR Types Paul Wouters
- Re: [Add] Comparative DoH Discovery DNS RR Types Paul Wouters