Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02

Eric Orth <> Mon, 20 April 2020 23:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B20D93A12D9 for <>; Mon, 20 Apr 2020 16:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.699
X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 surnAd5-EhoE for <>; Mon, 20 Apr 2020 16:29:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A4F33A12D5 for <>; Mon, 20 Apr 2020 16:29:51 -0700 (PDT)
Received: by with SMTP id y24so1533414wma.4 for <>; Mon, 20 Apr 2020 16:29:51 -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=bf1iyIQEN5T89fisl/Z8WF5Vz6g+9owPkgrLTr9qsKw=; b=PJjLgN+ZlC0R6xikIRQT802ONj0owly2cwwrkwAUjCwH3gcSHfDCo9/VakqxOV0491 LZwigP/tIX9720Ip3mzYb4JeBIKMA4xyEvDZwI4oADNrRGLlKQYEcHM3heUWH8y/Df/5 5aOa8W7dN5Gy04aoIKXsRsxBHITe7j9OH/f7JsMPa3LA7fvXS/yOULtH+Ha5e1ZOO8lE Yk34ejNxhBfZGbELIMFh46CWKu6rFwkemvhlnJHt/sMtmtjWnlmGzGqJdq9cg9aIe+t8 7Gr8nAdnOmD2jIcG8oS8HcmUAJgQotmxYIBC5Gy1uXU+xFAo+uIsDcbXHSmQB2ogcGKM ZJCg==
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=bf1iyIQEN5T89fisl/Z8WF5Vz6g+9owPkgrLTr9qsKw=; b=CIRRNVH05lVnTAo4MNIHFZWomIOJ930Iq85zWIWyISWcToZaHzfmCCemkn9wXYRljr Hj2/7PXli33oFeLamyb4ZcB4dPtgC1dF9KBaxp8bU2qi+FB11gZ9/D2ohget6kvuWG7p tPwkXiph8jYDjcyCXqBG68SDcpY+wCm/dxqvnVBCqV5SSiJu1vUTGEMkO56Y/JNF++xK q0KNOyiBcShe4VFa8VG8pe1nCYtpM8aDYsTvQDnv8W+vF8fX/JW89qX58WMVHIMscTxb OAECNkFXBPOQn3DF9wn/jn6ONiCXwtr9twf5w4x5xaO4/EwXzDW/k4NVrhLnqvxIpqZF adDw==
X-Gm-Message-State: AGi0PuZnu9Id2y6Za04q25UUpn6kaBzDGtvHsawZbOpDZSqDzO8r9drg uFfxPplzRDpqUxnMVbTNdLaJha/H+i5VSTJaNMQ/mr6kjjI=
X-Google-Smtp-Source: APiQypLFjiUKWN5I7uh8CA8MGCjUf17L39rCiMVbwuRNL28ihmJwXftYT4Ws2J5xW2tyOjbsBmEixu7Z9VzLQ2Q2uno=
X-Received: by 2002:a1c:4186:: with SMTP id o128mr1775492wma.21.1587425390095; Mon, 20 Apr 2020 16:29:50 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eric Orth <>
Date: Mon, 20 Apr 2020 19:29:39 -0400
Message-ID: <>
To: Alessandro Ghedini <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000007c3aed05a3c146c2"
Archived-At: <>
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
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, 20 Apr 2020 23:29:57 -0000

On Fri, Apr 17, 2020 at 6:20 AM Alessandro Ghedini <>

> Hello,
> First off, I have started implementing support for SVCB and HTTPSSVC as
> part of
> the dnspython library [0] and I'd be interested in doing some interop
> testing
> with other people's implementations.
> I also have a few comments/questions about the draft, apologies if they
> have
> already been discussed in the past (haven't been following the draft from
> the
> start).
> 1. For interop testing purposes it would be very helpful if the draft
> listed
> commonly agreed upon code-points for the new RR types. Ideally in the form
> of an
> official early assignment from IANA, but if that's not possible picking a
> couple
> of codepoints at random from the "private use" range would also be
> helpful. In
> my implementation I'm currently using "65481" for SVCB and "65482" for
> 2. The structure of the draft is a bit odd, as it lists a bunch of examples
> before introducing any of the records. This was a bit confusing to me, so
> I'd
> suggest moving sections 1.5 and 1.6 _before_ the examples (that is,
> immediately
> after the introduction). It might also be a good idea to just move the
> examples
> to an Appendix instead.
> 3. Would it make sense to move the ESNI/ECHO config paramenter to the
> draft instead? This way the DNS draft wouldn't need to depend on the ESNI
> draft
> (so e.g. if ESNI ends up taking longer, this draft could be published
> without
> having to wait for it).
> 4. What is the point of differentiating between AliasForm and ServiceForm?
> Like,
> couldn't the draft just say that the SvcFieldValue is an optional field
> and be
> done with that? It seems like not having to explicitly differentiate the
> two
> cases would simplify the draft a bit without sacrificing much, though I
> might
> be missing something.

I think the stronger distinction makes it easier to describe the required
behavior differences.  Much simpler to just say things like don't mix both
forms in the same response, and to ignore non-alias if any aliases are
present, than to make more detailed descriptions about what specific
optional contents are allowed to be mixed or not to accomplish the same

> 5. Section 2.1.1 says
>    The presentation format for SvcFieldValue is a whitespace-separated
>    list of elements representing a key-value pair, with an absent value
>    or "=" indicating an empty value.
> It took me longer than I'd like to admit to understand the "with an absent
> value
> or "=" indicating an empty value" part. I'd suggest rewording that
> paragraph to
> something like:
>    The presentation format for SvcFieldValue is a whitespace-separated
> list of
>    key=value pairs (e.g. "key123=value1 keys456=value2"). When the value,
> or
>    both the value and the "=" are omitted, the value should be interpreted
> as
>    being empty.
> Or something better :)
> 6. In Section 2.2 it says (in reference to param field values):
>    o  an octet string of the length defined by the previous field.
> It might be good to say here that the format of this octet string is
> defined
> according to the corresponding SvcParamKey, and then reference section 6
> for
> ths currently defined keys. The same applies for section 2.1.1 for the
> presentation format.
> 7. Section 4.3 says:
>    All DNS servers SHOULD treat the SvcParam portion of the SVCB RR...
> Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not mentioned
> anywhere else.
> 8. Maybe I'm missing something, but the following sentence in Section 6.4
> seems
> wrong:
>    When SvcDomainName is ".", server operators SHOULD NOT include these
> hints,
>    because they are unlikely to convey any performance benefit.
> My understanding is that ipv4hint and ipv6hint are the way to solve the
> multi-CDN problem, so let's say I have "" that CNAMEs to
> both
> "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both A
> and
> HTTPSVC concurrently for "", and receives two answers (the
> answer
> to the A query points to CDN A, while the answer to HTTPSSVC points to CDN
> B):
>      3600 IN CNAME cname.cdn-a.example
>     cname.cdn-a.example 3600 IN A
> and
>      3600 IN CNAME cname.cdn-b.example
>     cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..."
> My understanding is that in this case the client could end up connecting to
> (CDN A) with CDN B's ESNI config (or e.g. with the wrong ALPN).
> So if
> the server doesn't provide IP hints there would indeed be impact on
> performance
> because the client would just straight up fail to connect initially (e.g.
> maybe
> CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can use
> it,
> or just because of the wrong ESNI config).
> Long story short, I don't think the text should discourage setting
> ipv4hint and
> ipv6hint here. I get that it's SHOULD NOT and not MUST NOT, but it's pretty
> confusing nevertheless.

I don't think the hints are intended for this problem.  I think the general
design idea is that A/AAAA are the definitive address results for a given
name, and clients can just optionally shortcut querying A/AAAA if given

In your example, I believe the "." HTTPSSVC entry indicates that the A/AAAA
addresses for "cname.cdn-b.example" should be used, so it doesn't seem like
there is a multi-CDN problem.  The correct addresses for the correct CDN
are used.

But I think this might point out a potential problem with skipping hints
for "." results.  If the HTTPSSVC result passes through a CNAME, a
non-HTTPSSVC-supporting recurssive will handle the CNAME, but not lookup
A/AAAA for the HTTPSSVC.  So the client gets an HTTPSSVC result
for cname.cdn-b.example but only queried A/AAAA for, so
without hints, the client will have to do an extra set of A/AAAA queries
for cname.cdn-b.example.

> 9. Speaking of multi-CDN, AFAICT the problem is mentioned only once in the
> whole
> draft and only in relation to ESNI. However this is not ESNI-specific and
> also
> affects e.g. HTTP/3 as per the example above. So I think it would be
> useful to
> go into a little more detail on this.
> 10. Section B.2: s/pther/other/
> Cheers
> [0]
> _______________________________________________
> DNSOP mailing list