Re: snarls in real life

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 21 April 2021 23:47 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 CB9AE3A3BC5 for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 16:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, 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 vOEiIa5mStBR for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 16:47:25 -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 8AFB53A3BC3 for <ietf@ietf.org>; Wed, 21 Apr 2021 16:47:25 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 2B5C2C101F; Wed, 21 Apr 2021 19:47:24 -0400 (EDT)
Date: Wed, 21 Apr 2021 19:47:24 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: snarls in real life
Message-ID: <YIC5jFjv/Q7ehujw@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <914f3492-d56b-40ca-b7e0-bbbc65603dfa@dogfood.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/-kRGj8SQ61axP3uQs1sU7FO8b2c>
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: Wed, 21 Apr 2021 23:47:30 -0000

On Thu, Apr 22, 2021 at 08:57:12AM +1000, Bron Gondwana wrote:

> Personally, I'm right in there with indictments on DNSSec in general.  I didn't write this, but I stand by it:
> 
> https://fastmail.blog/2016/12/20/dnssec-dane/
> 
> Rob wrote "DNSSEC is fragile and easy to get wrong in subtle ways."  I
> say that DNSSEC is operational poison - it's hard to get right, easy
> to get wrong, and most importantly hard to debug failures when it
> happens - your users aren't going to be able to report the cause.
> It's theoretically good tech, but it clearly isn't getting traction
> and berating those who choose not to use it doesn't help.

This rehashing of stale and outdated strawman DNSSEC-bashing is neither
necessary nor productive.  Your critique of the assumptions about Google
stands on its merits, without needing to disparage the technical
specifics.

The tools for managing DNSSEC reliably have gotten substantially better
over the years.  Indeed Google has signed a number of its own domains,
including the .goog TLD and hundreds of thousands of customer domains
they're DNS hosting.  Google are having no problems running one of the
largest DNSSEC operations on the planet.  What they have not done, for
various reasons that are not relevant here is sign google.com or
gmail.com, ...  I can make potentially plausible guess as to why, but
they're not relevant.

> DNSSEC makes things fragile based on the number of big name sites that
> screw it up every year.

Microsoft just had a recent DNS failure without DNSSEC, the major cloud
services have had intermittent outages also unrelated to DNSSEC.  I've
seen no evidence that DNSSEC is particularly more fragile than other
technologies we operate.

> It also makes it much more expensive - DNSSEC is hard to get right and
> hard to keep right.

This is no longer true.  The tools for reliable automated signing and
monitoring thereof have improved substantially.  Only naive seat of
the pants deployments with no monitoring are more fragile.

My domain has been signed since 2014 without any disruptions, with just
a modest monitoring script that has alerted me to pendign expiration
(automated re-signing wasn't kicking in) a couple of times, well before
the signatures expired.  The bugs that resulted in resigning not
happening have been fixed for some time, and I don't have to expend any
energy to keep DNSSEC running, it just works.

-- 
    Viktor.