Re: DNSSEC architecture vs reality

Michael Thomas <> Tue, 13 April 2021 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE7893A084C for <>; Mon, 12 Apr 2021 18:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Cx_--Ovfqf2 for <>; Mon, 12 Apr 2021 18:28:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D4D53A083B for <>; Mon, 12 Apr 2021 18:28:26 -0700 (PDT)
Received: by with SMTP id u11so3955535pjr.0 for <>; Mon, 12 Apr 2021 18:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=13iZBQCEecUcaPTxr/cpdFYqa8XfUhQncWQ+VOsrq2w=; b=AyYqH+a0hW41YeN8T9NsJheCE7cqPs5Mbh3Y44kGVi2CFJNUItHh0UXAeOouRkS6tr WB6rw4tagrtKxo2EMvoZ3IzIuTQxy6aiXarj1Q6f5vjKYXuzzgFcPzOmlEaxtxMrvXhM 8zFKp/EbwL6FxHb/hn79Zs45RAPI9RKSkZ7S3MIdAEBpmE0LM7lQByfczpHxArcuvvzM HQpHERCCVLb9qtON9qzsD1lxXTO6YzFBzmlWF9BymdB8htOfpf0wSVp+Gx+6bkqI8Rwa fuM5wVezSu5TstACra/KWcI8UWzcsCzjXp1UtUC8yRYSOie/lMpIP9R8VP1MBXWiYgf2 1NCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=13iZBQCEecUcaPTxr/cpdFYqa8XfUhQncWQ+VOsrq2w=; b=Gn91yeG1T4p3Dzce6GJMcb/SKcews0W9NQZ78pMAuQFYPss5NLGrfAmjfzyszJwTmF DxX6uRbgKddeJ/eDKRK55eDYxnafcRWoG/T/6QrtBErbP86i76qwjYRHEX/XvSQG0Gwz 4Oa56HALPPQw9xaSPJA/HebO73kFKzWep8vfMQ7BdHMRuKJTTIcsL1uFrdq8ihNBaE0K H2nojA4r268AAHSQSFaN1dn0eaLL3XhNHmFlGevQjA+uuZWxorkodMbktQV2VBK6H4vx re+23fVo31/iCABqWJkdOehbpnSKS8MOUmvu8GEeMRtLJVj1eGd5NALEUz7pDyhnRlDt aV2Q==
X-Gm-Message-State: AOAM531xMqTJy9EMBsbQJH7iCDWPQoh5QRQFsnL0c2UK4ehyMsIEiQES ayOoXyARKRdp9pA3e9i989NUuMmBvQ3fmw==
X-Google-Smtp-Source: ABdhPJz+6m3PbVnmXXaggSYPI3waKvYCL4ZGe0CflbzPVHVh/zOt6xJ64aGHMO8i56t3YgZpZl049A==
X-Received: by 2002:a17:90b:4c87:: with SMTP id my7mr2127413pjb.162.1618277304916; Mon, 12 Apr 2021 18:28:24 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id c9sm7558094pfo.122.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Apr 2021 18:28:24 -0700 (PDT)
Subject: Re: DNSSEC architecture vs reality
To: John C Klensin <>, Nico Williams <>
References: <> <> <> <> <> <> <> <> <20210412221435.GV9612@localhost> <> <20210412222748.GW9612@localhost> <> <5F7F84363A52E9AB79CBF9B2@PSB> <> <D871236156E274EABD68A85D@PSB>
From: Michael Thomas <>
Message-ID: <>
Date: Mon, 12 Apr 2021 18:28:23 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <D871236156E274EABD68A85D@PSB>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Apr 2021 01:28:31 -0000

On 4/12/21 6:16 PM, John C Klensin wrote:
> --On Monday, April 12, 2021 17:48 -0700 Michael Thomas
> <> wrote:
> You also wrote:
>> The problem is that it's not this simple. Software needs to
>> change to implement new RR types which inevitably begs the
>> question "what's in it for me?"
> Sure.  But (different) software also has to change to implement
> (to use the comments that started us down this thread) DANE.
> Those changes are to mail software, systems, and configurations,
> not DNS support, but they are changes nonetheless.  Yes, other
> changes are needed for anything that requires that
> authentication or authorization information be stored in the
> DNS, but that raises the question of whether DANE's designers
> could have put that information somewhere else and whether that
> would have been worth it (my guess is that the answer to the
> former is "probably" and, to the latter, "probably not", but
> that is what gets us to the rant in RFC 8324).
> So the answer to your question is "The enterprise has decided
> DANE is useful and DNS updates are as much part of the price as
> email changes" and, if that is not enough, then either DANE is
> not actually needed or the second part of the answer is "want to
> keep your job?".
I think part of the key of success with new protocols is how few players 
need buy-in. The fewer the better. Had we had to get buy in from the 
folks that maintained our DNS with DKIM too, our likelihood of failure 
would have been a *lot* higher. It wasn't even a given that they'd give 
us TXT. The overarching point of my initial blog post is that when you 
have an opportunity to route around fiefdoms to get something done, you 
have a much higher chance of success. That is really the lesson we 
should take away with Google re: Quic. That's why I think it's a 
realistic opportunity for quic+dane. But finding out that Google doesn't 
sign their zones is disappointing.