Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

Jan Včelák <> Thu, 26 September 2019 10:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C13A1208A1 for <>; Thu, 26 Sep 2019 03:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qcS6IMKVOo1h for <>; Thu, 26 Sep 2019 03:31:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28ED412089C for <>; Thu, 26 Sep 2019 03:31:05 -0700 (PDT)
Received: by with SMTP id q186so331693vkb.0 for <>; Thu, 26 Sep 2019 03:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x0GyLThKc+JMWeHy6MVVd0XMOg+N944MQ+k9WkLVeHM=; b=S9EPKzS8byX2roxEmuzSvGRmMOpPwaQtzvzlSFdMN94SWhNVpACIHUXmnCkXxGdkSh O0uZsWH7gdpt7akafmQVCJLgLgH0bYOFMHdOZdUK+7S+/dHx6tPG779bympSh/TticA2 NYdAk9e6dGlrAqoSJxh8t2dzCm12fWdlBGQK8=
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:content-transfer-encoding; bh=x0GyLThKc+JMWeHy6MVVd0XMOg+N944MQ+k9WkLVeHM=; b=LAuZLU8Z0yu1ovfpkqcJ36ycGKUQxOV7X00po0X1gbdqQN9eXRjijmy0lR0p0pukj2 O3i9qG4xbsMqmTzNFvu5D20FEiLwLhz/ESoRAcfaFgJ2QMfvorJDrEw+RSytN2kcBuTX JXPXeQoN+JKytm5XyR7dueCcUO7ivVPY5UNp3mxP9eTvn42ys1bcl1FZmXTL0YRpk0cc UYptir0re2C9xL4u+6GpwcCE4QHy5EXNSP2ODA+zhCOAmGMKJ1qNaLVpa7RX/jwUv2NE r2eeFKdT3JLFcT+P+i0bApT0E5q11faM6f2Fupg4kXGKfRSz30Re/ho9TOjmePbiM/Cr 7hEQ==
X-Gm-Message-State: APjAAAVTw+tqyae8ofasxPcFyVAceAgKpjlbgN9gyneQrl34gau5f1WK QLiA9M4EU75mYxROmGiawZTADZn+10/ojiiXSgGIJg==
X-Google-Smtp-Source: APXvYqzsADNpKykE7VhFS3sxS8VZfQ+zeDB/J6DfkNoyY/wREyqRdY06KRvYtEBnQF4nIrVLirG0gtO9i77mLwJt2AU=
X-Received: by 2002:a1f:b4c2:: with SMTP id d185mr1259231vkf.29.1569493864744; Thu, 26 Sep 2019 03:31:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= <>
Date: Thu, 26 Sep 2019 12:30:53 +0200
Message-ID: <>
To: Ben Schwartz <>
Cc: dnsop WG <>, Erik Nygren <>, Mike Bishop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
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: Thu, 26 Sep 2019 10:31:09 -0000

On Wed, Sep 25, 2019 at 7:17 PM Ben Schwartz wrote:
>>      7200  IN HTTPSSVC 0 ""
>>  7200  IN HTTPSSVC 2 "alpn=h3
>> port=8003 esnikeys=\"ABC...\""
> The original proposal used a text encoding similar to your description.  We changed to a key-specific encoding due to complaints about the inefficiency of base64-encoding ESNI keys.  I think the inefficiency of base64 encoding is tolerable, but we adopted the feedback in favor of a binary encoding.

This is a fair point. I don't have a strong opinion.

> The current draft attempts to minimize complexity for implementers by offering a fully generic encoding for unknown key types.  For example, "alpn=h3" can also be expressed as "key1=h3", and "port=8003" can also be expressed as "key2=\031\067".  This encoding may not be convenient, but hopefully it will reduce the burden of supporting new parameter types.

I agree we need generic encoding. There is a way to express unknown
record types ( and the
syntax used there is more compact than what you propose. It uses hex
strings instead of escaped decimal values. However its clumsy to work
with records in that syntax and you proposal is better in that sense.

I think this may become the most complex record type we have in DNS so
far. None of the existing registered record types contain a list of
key-value pairs of arbitrary length. Given that there is also a
registry for key types involved it will be fun to implement the
encoder/decoder. But we will have to deal with it. I'm interested in
what others in this working group think.

Thanks, Ben.