Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

Tony Finch <> Fri, 11 June 2021 17:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3F3E3A0781 for <>; Fri, 11 Jun 2021 10:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6OPbn5HjjygU for <>; Fri, 11 Jun 2021 10:29:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 633243A0789 for <>; Fri, 11 Jun 2021 10:29:23 -0700 (PDT)
X-Cam-AntiVirus: no malware found
Received: from [] (port=57724 helo=milebook.lan) by ( []:25) with esmtpsa (PLAIN:fanf2) (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1lrky8-000acc-7o (Exim 4.94.2) (return-path <>); Fri, 11 Jun 2021 18:29:20 +0100
Date: Fri, 11 Jun 2021 18:29:20 +0100
From: Tony Finch <>
To: Shivan Kaul Sahib <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Sender: Tony Finch <>
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Jun 2021 17:29:28 -0000

Shivan Kaul Sahib <> wrote:

> Hi all, Shumon and I have been working on an early draft that surveys
> current DNS domain verification techniques. Depending on how it goes, we
> hope to eventually explore if we can come up with some best practices.

This looks like a useful document!

One thing that's operationally awkward for me is how some providers do
one-time verifications, and others re-validate periodically. I suppose
there is another distinction between static re-validation done by (e.g.)
Google, and dynamic renewal as required by ACME.

Best practice for providers ought to be to document re-validation
requirements very prominently and clearly. (In my experience the common
ones are not too bad but occasionally we have to guess, so maybe a service
stops working for mysterious reasons 30 or 90 days later.)

It's kind of ugly the way static verification records clutter
up the place, but on the other hand it is a useful protection against
subdomain takeover attacks. So I hope that this document will have a good
survey of the security considerations.

Here's an overview of subdomain takeovers

f.anthony.n.finch  <>
Southeast Fitzroy: Northerly or northeasterly 5 to 7, occasionally
gale 8 at first. Moderate or rough. Fair. Good.