Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Ralf Weber <> Sun, 23 May 2021 08:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BB113A0A34 for <>; Sun, 23 May 2021 01:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nCSrerAzJwRj for <>; Sun, 23 May 2021 01:45:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F8FE3A0A2D for <>; Sun, 23 May 2021 01:45:38 -0700 (PDT)
Received: by (Postfix, from userid 107) id 89A6A5F40B47; Sun, 23 May 2021 08:45:32 +0000 (UTC)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 8C38B5F402C2; Sun, 23 May 2021 08:45:31 +0000 (UTC)
From: "Ralf Weber" <>
To: "Brian Dickson" <>
Cc: "Eric Orth" <>, WG <>, "Martin Thomson" <>
Date: Sun, 23 May 2021 10:45:30 +0200
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <>
In-Reply-To: <>
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.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, 23 May 2021 08:45:41 -0000


On 21 May 2021, at 20:16, Brian Dickson wrote:
> I think the handling of presentation formats and wire formats leaves much
> to be desired.
As others said the wire format is a pretty standard TLV format, so I don’t
think there is a change needed as this sort of format is well understood.
I’m also confident that zone file presentation can be sorted out for regular
uses and we always have the generic \nnn escaping for the more complicated

> However, the handling of future extensions is not (IMHO) currently usable
> via the existing proposed mechanism.
> The discussion about "what if ECN needed to be added later" got me thinking
> about the issue.
> I think there is a need for something similar to RFC3597, except for fields
> in a record rather than a BLOB for the record itself.
> RFC3597 is fine for an RRTYPE with only one RDATA element/structure, but
> not for complex RRs.
RFC3597 just works fine with HTTPS. Most people have been using it for some
time now, unless they have recursor already supports HTTPS/SVCB. IMHO HTTPS
has shown that RFC3597 works today as there were only minor effects on
rolling out a new resource record. I think Google did an additional test
with an unregistered RRType and came to the same conclusion, but I don’t
have the details at hand.

> So, this problem on sub-field encodings has arisen from ignoring RFC5507
> (regardless of why it has been ignored).
The only mention of that is in comparison to TXT records people used for
e.g SPF and other things. The specific advise there is only if your record
size is so big that it exceeds general DNS packet size make it a pointer
instead of stuffing it in the resource record. The generic advice of RFC5507
is to create a real resource record type instead of using TXT, and IMHO
this draft follows this advice (both the RR and size recommendations).

So long
Ralf Weber