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

Brian Dickson <> Mon, 10 May 2021 23:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DD0F3A2FEF for <>; Mon, 10 May 2021 16:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bHkral5ta1pz for <>; Mon, 10 May 2021 16:59:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DB653A2FF1 for <>; Mon, 10 May 2021 16:59:24 -0700 (PDT)
Received: by with SMTP id f12so10340529ljp.2 for <>; Mon, 10 May 2021 16:59:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YQnF4tvTgGbtuzFViIMw2nd/LYBNKogZPPCGNcpdPUQ=; b=jhcT+4hWBNYaZd8KXK4JgKwEN9VsS5Gn0OoAcKK00pPIcbrqn+pFaX40Sv9jxV/+rt ByPCpKOFzlEKGLqadL3KipOI8av15zD2a+eRDZOfm6XQtL69tq6rcLYDtcyOuOv5hUoq ZNwr9IvA6vXDlZbKPZoyZnaGd8z3sDOjYTUbKKnekXXKUOBWzdwzBBH9/LHfEvShhWSt 53IFtuSF1r9Ndlt1ZDLPzxoy3JljMrRRTvJxMEJN12lHo82Kh2w/4hXdMn+tcpc9xazV 0R3A/2nmL+Q6Ckihz5amVvZupqbqTLi+/LTN7FY5v+DTUnarS0ZqESsdr3+swVIjA1US Rw2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YQnF4tvTgGbtuzFViIMw2nd/LYBNKogZPPCGNcpdPUQ=; b=d+Abrdzr+U9ViQCNkFj9VAklStXITpwWZ3fij3MhC0Ldo8T5UDq1AKnB2W+08eX3ON Ne9JSo33fcXnDYQM393bmbMfGCHEMAnz7xnR/soW9umMLNVCSpvT0PtM/ImO5FuYyHtx Hd3amqji8IBWgJpDtgQnqjX+mkoypNIpYJmw3FgkgcD1HIhg8s29yMe03Knwp2vK0cpG XPEEhS3Wi0Z3JqbTczkjCHKc4v8OpZQ187u4N2TzBLpqGEBMr0yHNpZZ8s7tp834jY0O qQISrRzmaweXvl0T8HpX5dCersQT84i8eRDiOBdQ7XbmkVTEgpr6+gr9ixEND5coLAqY kXCw==
X-Gm-Message-State: AOAM533GculOeNh4LzC/9k+YMhpZ1Lny9lE/J1SvR6ynF0ByWkJAYxEk 3iGwpRIaWxOzPqRAR1iELmNg3MpSL32zkz3qKYs=
X-Google-Smtp-Source: ABdhPJwiGWGIrXiiZRM0/Fb/5OrCykj2mlCtOt2YYb4ibPPQjz/ijTLKZH9xp5ZTgaZKIyl8vicU7cjC0xuudQo2gVk=
X-Received: by 2002:a2e:9d10:: with SMTP id t16mr21829178lji.253.1620691157167; Mon, 10 May 2021 16:59:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Mon, 10 May 2021 16:59:04 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: Joe Abley <>, dnsop <>, Pieter Lexis <>
Content-Type: multipart/alternative; boundary="000000000000b6b21d05c20290f2"
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: Mon, 10 May 2021 23:59:30 -0000

On Mon, May 10, 2021 at 9:58 AM Ben Schwartz <bemasc=> wrote:

> I don't support breaking the SvcParams into separate RRs across the
> RRSet.  This would be an extremely inefficient encoding in wire format, and
> would conflict with the usual understanding of resource records as
> independently meaningful alternatives.
> [snip]

> To see why I favor two-pass, consider a SvcParam whose wire format value
> is defined to be CBOR, represented as JSON in the zone file.  JSON is
> defined as UTF-16, and allows strings containing any character from the
> Basic Multilingual Plane.  It also allows various kinds of backslash
> escaping including " \" " for quotes within strings, and "\uD834\uDD1E"
> for extended unicode codepoints.  A one-pass parser must somehow integrate
> this into the flow of zone file parsing.  The easiest way is to simply
> disable all RFC1035-style escapes and line-breaks for the duration of the
> SvcParamValue, but this is a major breach of standard zone file practice,
> and raises questions about how to store UTF-16 characters in a zone file.
> Alternatively, we could somehow combine both RFC1035 and JSON escaping, but
> if this is even possible, it would seem to require writing a new
> RFC1035+JSON hybrid parser.  I also think these behaviors would be
> confusing to users, who would have to try to understand how this new
> integrated escaping works in order to author zone files containing either
> kind of escape.


Let me ask what is probably a really leading question, in terms of the
semantics for SVCB (and HTTPS).
If I understand the draft in its current form, the goal is to be able to
encode and parse some DNS RRset in such a way as it lets you obtain, in one
fell swoop (but possibly multiple passes for parsing) everything needed to
- A well-ordered list of one or more targets, where each target has a set
of attributes.
- The examples currently show RRsets with multiple distinct Priority values
- However, the words indicate that it is permissible for two RRs in the set
to have the same Priority value.
- The effect is having an array of objects, each of which has a priority,
name, and optional set of key/value pairs (where values can be lists).

So, I have a proposed solution that will make the parsing, and generation
of post-parsing JSON objects as close to trivial as possible.
This borrows heavily from what Joe Abley already wrote. I'm just taking the
concept to its (il)logical conclusion.

Encode everything using the following mechanism:
Priority Enumeration Key Value
One of the "Keys" would be Target, with a corresponding Value of FQDN.
All of the records with the same value for "enumeration" belong together,
and form a single SvcParameter list.
For the AliasForm, both the Priority and Enumeration would be 0, and only a
single Target,Value pair are permitted.

To take one example from the draft, and re-encode it thusly:
 $ORIGIN svc.example. ; A hosting provider.
pool  7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..."
              HTTPS 2 .      alpn=h2 ech="abc..."
pool   300 IN A
              AAAA     2001:db8::2
h3pool 300 IN A
              AAAA     2001:db8::3

This would become (for brevity, encoding just a list of RDATA values for
all of the "pool HTTPS" records):
1 1 target "h3pool"
1 1 alpn "h2,h3"
1 1 ech "123..."
2 2 target "."
2 2 alpn "h2"
2 2 ech "abc..."

I think this is likely a lot easier to parse, and to convert into whatever
form your ALPN-handling stuff wants (including JSON).
I is also very close to trivial to write a JSON -> Zone File
transliterator, so user input in JSON (which meets the JSON structure
expected) can be handled, and even bidirectionally allow Zone File -> JSON
for user editing of already-existent entries.

For the example above;
If the priority of both of the above were the same, they would be all "1 1
..." and "1 2 ..." instead of "1 1 ..." and "2 2 ...".
If my JSON isn't horribly bad, I think this would get converted into:
 [ { "name" : "h3pool", "priority" : 1, "SvcParams" : { "alpn" : "h2,h3",
"ech" : "123..." } }, ...]

IMNSHO, it'll be faster to discard any existing parsing code, and embrace
this as the Zone File format (and wire format) going forward.

Hope this is helpful to the discussion.