Re: snarls in real life

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 22 April 2021 05:11 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054583A0E93 for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 22:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 p3lXw1wTfwPg for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 22:11:03 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 1A4E53A0E91 for <ietf@ietf.org>; Wed, 21 Apr 2021 22:11:02 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 8DAE4C14B1; Thu, 22 Apr 2021 01:11:00 -0400 (EDT)
Date: Thu, 22 Apr 2021 01:11:00 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: snarls in real life
Message-ID: <YIEFZMf1kDANeq9H@straasha.imrryr.org>
Reply-To: ietf@ietf.org
References: <93fedaa0-5ad0-dcc0-ff01-43b8e1c97989@mtcc.com> <19f2b2e1-6365-480a-86f2-111377cac2de@www.fastmail.com> <7c77e401-4703-3921-d15d-6d69b74df488@mtcc.com> <914f3492-d56b-40ca-b7e0-bbbc65603dfa@dogfood.fastmail.com> <YIC5jFjv/Q7ehujw@straasha.imrryr.org> <efacee7c-bb7d-4861-9037-4c122d3e28ca@dogfood.fastmail.com> <4AF10FFE-0045-4776-B4DD-CE0FD9084F88@dukhovni.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4AF10FFE-0045-4776-B4DD-CE0FD9084F88@dukhovni.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/YZKiGx9ycAAH2ZffILrtSJDU78I>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2021 05:11:06 -0000

On Wed, Apr 21, 2021 at 08:23:52PM -0400, Viktor Dukhovni wrote:

> I am suggesting that Google can easily do DNSSEC for google.com, they likely
> face non-trivial adoption barriers with global DNSSEC load-balancing, and
> other specialised tech.  I am just saying the old excuses are tired out, we
> can and should move on.

P.S.  My typo (crucial skipped negation) in the above may have given
rather the wrong impression.  I meant to write:

    I am *not* suggesting that Google can easily do DNSSEC for
    google.com, ...

There are likely significant complexities in making changes at Google's
scale, given all the specialised machinery in use for DNS load-balancing.

Mind you, there could be an opportunity to revisit this once support for
DNS SVCB/HTTPS records is ubiquitous.  In a clean-slate design the
targets of these can be stable names in unsigned zones, with all the
dynamic IP responses limited to those zones:

    ; Signed largely static data:
    ;
    example.com. 1D IN HTTPS 0 www.dyndns.example.com.
    _443._tcp.example.com IN TLSA 2 1 1 ...
    ;
    www.example.com. 1D IN HTTPS 0 www.dyndns.example.com.
    _443._tcp.www.example.com IN TLSA 2 1 1 ...

    ; Unsigned, short TTL dynamic data, client-subnet dependent, ...
    ;
    www.dyndns.example.com. IN A ...
    www.dyndns.example.com. IN AAAA ...

and all the short TTLs, non-DNSSEC load-balancers, ... limited to just
such specialised zones.

-- 
	Viktor.