IETF Logo Mail Archive

Re: [dns-privacy] ADoT signalling

Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 04 November 2019 14:26 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E6612013B for <dns-privacy@ietfa.amsl.com>; Mon, 4 Nov 2019 06:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 B8S9M8qdfEh0 for <dns-privacy@ietfa.amsl.com>; Mon, 4 Nov 2019 06:25:57 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 659BD120099 for <dns-privacy@ietf.org>; Mon, 4 Nov 2019 06:25:57 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id DAC0B28066A; Mon, 4 Nov 2019 15:25:55 +0100 (CET)
Received: from relay01.prive.nic.fr (pa-th3.interco.nic.fr [192.134.4.74]) by mx4.nic.fr (Postfix) with ESMTP id D518C2802DF; Mon, 4 Nov 2019 15:25:55 +0100 (CET)
Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id D1D2A663E720; Mon, 4 Nov 2019 15:25:55 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id C41AA3FD14; Mon, 4 Nov 2019 15:25:55 +0100 (CET)
Date: Mon, 04 Nov 2019 15:25:55 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: John Levine <johnl@taugh.com>
Cc: dns-privacy@ietf.org
Message-ID: <20191104142555.GA10561@nic.fr>
References: <20191103223335.4395EE54E62@ary.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20191103223335.4395EE54E62@ary.local>
X-Operating-System: Debian GNU/Linux 10.1
X-Kernel: Linux 4.19.0-6-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/z40YoLzT8s4xKpXVp3E9G7HzzTo>
Subject: Re: [dns-privacy] ADoT signalling
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 14:26:02 -0000

On Sun, Nov 03, 2019 at 05:33:34PM -0500,
 John Levine <johnl@taugh.com> wrote 
 a message of 14 lines which said:

> I thought it might be useful to make a list of possible ways to signal
> that a server offers ADoT:

I would like also a discussion on whether signaling is 1) good 2)
necessary.

Even if you get a signal, the reality may be out-of-sync with the
signal, for instance because of a problem on the server side (remember
AAAAs published without checking IPv6 connectivity works) or on the
client side (port 853 blocked). So, in any case, the client has to be
ready to encounter a problem and to try a fallback.

So, why not an "happy eyeball" (RFC 8305) approach? Check 53 and 853
more or less in parallel and keep DoT if it works.

v2.23.0 | Report a Bug | By Email