IETF Logo Mail Archive

Re: [dns-privacy] [Ext] next steps for draft-opportunistic-adotq

Paul Wouters <paul@nohats.ca> Tue, 23 March 2021 23:01 UTC

Return-Path: <paul@nohats.ca>
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 F20F53A18F6 for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 16:01:31 -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 2yhC4eQBA1ia for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 16:01:27 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 2ECCC3A18FB for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 16:01:27 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4F4n0z2XXBzFKn; Wed, 24 Mar 2021 00:01:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1616540483; bh=ilkyObKNjWxanU1yMlw9uf56EvXhS+kByiLDkkRzVYc=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=TH38c2FSGma0kwhg5Bx7GCZ558m5+n9wpDc3WyA4r2rrvpOdFMqsiWA9bPy0Dfegc IIhZHSXSCtd2Li1dhOm4m6OgHHGDtA1ihUDu0SC15YMpuvDwAzoE0Cb+L2Bw1Oo9Qi OIXc31hThuSffX6mWgbG0TiaUtWvz+L6yM6Qvdq8=
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 YWZqsaaXGpBl; Wed, 24 Mar 2021 00:01:22 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 24 Mar 2021 00:01:22 +0100 (CET)
Received: from [193.110.157.220] (unknown [193.110.157.220]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 0FFE66029A53; Tue, 23 Mar 2021 19:01:21 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Tue, 23 Mar 2021 19:01:19 -0400
Message-Id: <DF40D081-1EA8-4E92-BB67-2966E32688DE@nohats.ca>
References: <A68841F4-B7CC-4AAC-BC9F-0961ADF2C8FA@rfc1035.com>
Cc: dns-privacy@ietf.org
In-Reply-To: <A68841F4-B7CC-4AAC-BC9F-0961ADF2C8FA@rfc1035.com>
To: Jim Reid <jim@rfc1035.com>
X-Mailer: iPhone Mail (18D61)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/5rj95lIXpvAuiobT1IHGRpz_UzM>
Subject: Re: [dns-privacy] [Ext] next steps for draft-opportunistic-adotq
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: Tue, 23 Mar 2021 23:01:32 -0000

On Mar 23, 2021, at 18:48, Jim Reid <jim@rfc1035.com> wrote:
> 
> 
> 
>> On 23 Mar 2021, at 22:32, Paul Wouters <paul@nohats.ca> wrote:
>> 
>> So what is it that you are exactly objecting to? The syntax or the capability?
> 
> The capability - mostly. TLDs should not be publishing SVCB records for the reasons I outlined before.

What you outlined is not clear.


> I’m not too keen on using SVCB records apart from stubs finding resolvers on their local network. It’s OK for me to publish SVCB records in rfc1035.com for anyone who has the misfortune to be one of my local users and needs to find an encrypted resolver. IMO it’s not OK to do that in .com (say) for everthing on the planet that needs to lookup a .com domain name.

I think you are misinterpreting the draft. The goal is to advertise DoT servers ONLY for yourself, not for your children or parent.

There might be some confusion because the draft editors mistakenly believe they can get child SVCB records published at the server, like DS records. I’ve already tried to convince them that is not going to happen.

> This is all somewhat moot because I very much doubt any busy TLD will ever turn on DoT or DoH on their authoritative name servers.

SVCB allows them to put those servers in as separate infrastructure that would not affect regular nameserver operation. There is discussion about conveying status (testing, production) within the SVCB record.

Paul

v2.23.0 | Report a Bug | By Email