Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

Bjørn Mork <> Sun, 04 November 2018 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E454B12D4EC; Sun, 4 Nov 2018 06:11:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QdTLvGrMnk6o; Sun, 4 Nov 2018 06:11:00 -0800 (PST)
Received: from ( [IPv6:2001:4641::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A84CC120072; Sun, 4 Nov 2018 06:10:59 -0800 (PST)
Received: from ( [IPv6:2001:4641:0:2:7627:374e:db74:e353]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id wA4EAt8P003932 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 Nov 2018 15:10:56 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=b; t=1541340656; bh=LuzHV4tBD+43UQXDMX+YCtQI6iqHpzEZTXBIA/YeNY4=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=Y5cr39PILb6Qdw5Pj4sT9KN5ON4o2dAuj8sg2hadxoU+cl3HpUSLYTADqKtH/0umo 5Dbt+E32tQ7VyCZlcgP392/6PV4Yzs8ZatoHGWh8oLOrF4GMXXDl08VfI5KWujcuaY xf0CxnFCkwXR5hsQyReohvlM5f8fD3O6rp3anHnU=
Received: from bjorn by with local (Exim 4.89) (envelope-from <>) id 1gJJ79-0005Ja-5a; Sun, 04 Nov 2018 15:10:55 +0100
From: Bjørn Mork <>
Organization: m
References: <>
Date: Sun, 04 Nov 2018 15:10:55 +0100
In-Reply-To: <> ('s message of "Sat, 03 Nov 2018 13:22:45 -0700")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.100.2 at canardo
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.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: Sun, 04 Nov 2018 14:11:03 -0000

Section 4.3 claims RFC7671 reserves "_dane":

"             +------------+------------------+------------+
              | RR Type    | _NODE NAME       | REFERENCE  |
              | TLSA       | _dane            | [RFC7671]  |

I can't see any support of this in RFC7671.

I assume the misunderstanding comes from a couple of examples using a
"_dane" label. But this is an arbitrary choice, and not an attempt to
reserve a name.  For example from RFC7671 section 5.2:

"  Some domains may prefer to avoid the operational complexity of
   publishing unique TLSA RRs for each TLS service.  If the domain
   employs a common issuing CA to create certificates for multiple TLS
   services, it may be simpler to publish the issuing authority as a TA
   for the certificate chains of all relevant services.  The TLSA query
   domain (TLSA base domain with port and protocol prefix labels) for
   each service issued by the same TA may then be set to a CNAME alias
   that points to a common TLSA RRset that matches the TA.  For example:

   ; Two servers, each with its own certificate, that share
   ; a common issuer (TA).
   ;            IN A            IN A  IN CNAME  IN CNAME      IN TLSA 2 0 1 e3b0c44298fc1c14...

It is obvious from this that "" is a placeholder
alias, and not reserving "tlsa" or "_dane" labels.

The consistent choice of "tlsa._dane" in the RFC7671 examples might have
contributed to this confusion.  Something to keep in mind for future DNS
label examples.  Use your fantasy :-)