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

[Jan Včelák <[e-mail]>]

On Wed, Sep 25, 2019 at 7:17 PM Ben Schwartz wrote:
>> example.com.      7200  IN HTTPSSVC 0 svc.example.net. ""
>> svc.example.net.  7200  IN HTTPSSVC 2 svc3.example.net. "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 (https://tools.ietf.org/html/rfc3597#section-5) 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.

Jan