Re: [DNSOP] HTTPS and SVBC key names.

[Ben Schwartz <[e-mail]>]

On Mon, Jul 20, 2020 at 2:39 PM Dick Franks <[e-mail]> wrote:

>
> On Thu, 16 Jul 2020 at 21:17, Ben Schwartz <[e-mail]> wrote:
>
>
>> The presentation format is optimized for humans and the wire format is
>>>> optimized for machines. In particular, when using the named keys it's not
>>>> obvious what the numeric ordering is, so keeping them in order when editing
>>>> a zone file by hand would be hard.
>>>>
>>>
>   blog.cloudflare.com. 300 IN HTTPS ( 1  .
>
> key1=\005\104\051\045\050\057\005\104\051\045\050\056\005\104\051\045\050\055\002\104\050
>      key4=\104\018\026\046\104\018\027\046
>
> key6=\038\006\071\000\000\000\000\000\000\000\000\000\104\018\026\046\038\006\071\000\000\000\000\000\000\000\000\000\104\018\027\046
>      )
>
> "optimized" is not the word which springs to this human's mind.
>

The unknown-key format is designed more for authoring than reading.  As an
author, it works somewhat better than your example.  For instance, your
key1 could be written as

key1=\005h3-29\005h3-28\005h3-27\002h2

That seems more intelligible than hex or base64.

Also, your key4 here pretty clearly shows the IPv4 addresses 104.18.26.46
and 104.18.27.46.

In short, the unknown-key format is fairly usable for authoring fields
whose values are plain text or numeric octets, since a human author can
choose escape codes or ASCII characters as appropriate.  A renderer (by
definition) has no idea what the contents mean, so it can work well for
plain text or numeric octets but not both.

IMHO, tarted up RFC3597 format is easier to read.
>

With the addition of comments for the recognized keys and fields, I think
you're probably right.  However, when authoring a zone file I would hate to
have to use RFC 3597 hex for the whole record just to add one key that my
parser doesn't support yet.  Also, if most future keys turn out to have
ASCII plaintext values (e.g. URLs), an unknown key renderer that uses ASCII
symbols where possible might turn out to work quite well.

Example:
>
>     use Net::DNS;
>
>     my $rr = new Net::DNS::RR <<'END';
>     example.net.        300     IN      HTTPS   1 target.example.net.
>         mandatory=key0,key1,alpn,no-default-alpn,key99  ; with
> duplications and other sins
>         alpn=h3-29,h3-28,h3-27,h2
>         no-default-alpn
>         port=1234
>         ipv4hint=192.0.2.1,192.0.2.2
>         echconfig=base64string
>         ipv6hint=2001:DB8::1,2001:DB8::2
>     END
>
>     $rr->print;
>
> produces:
>
>     example.net.    300     IN      HTTPS   ( \# 126 0001
>         06746172676574076578616d706c6503 6e657400 ; target.example.net.
>         0000 0004 00010002
>         0001 0015 0568332d32390568332d32380568332d 3237026832
> <(323)%20702-6832>
>         0002 0000
>         0003 0002 04d2
>         0004 0008 c0000201c0000202
>         0005 0009 6dab1eeb8b2dae29e0
>         0006 0020 20010db8000000000000000000000001
> 20010db8000000000000000000000002
>         )
>
> Observations and complaints gratefully received.
>
> --Dick
>
>> _______________________________________________
>>>>>>
>>>>> DNSOP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>>>
>>>>