John,
please show how this would be used to parse a HTTPS record
without extending the format?
HTTPS:65 HTTPS Record
I2:SvcPriority
N:TargetName
Z[SvcParm,M0]:SvcParams
The problem with the draft is that you are hiding the complexity in
"Miscellaneous fields” section of the draft which would need to be
updated for many new RR types. SVCB/HTTPS is just a case in point.
Mark
> On 13 Apr 2021, at 11:49, John Levine <johnl@xxxxxxxxx> wrote:
>
> It appears that Michael Thomas <mike@xxxxxxxx> said:
>>> But DNS itself shouldn't have to change to implement new RR types,
>>> more than (perhaps) adding a line to a table that says RR type NN has
>>> ASCII name XX and the following types of parameters. And that table
>>> should be globally and securely accessible. Encode the table in DNS
>>> somehow, put it in the root zone or other zone managed by the root,
>>> give it a very long TTL, and sign it with DNSSEC.
>
> Hey, what a good idea. Oh, look someone wrote it up as an I-D starting ten years ago:
>
> https://datatracker.ietf.org/doc/draft-levine-dnsextlang/
>
> And here's a python library to implement it with encoder, decoder, and
> a dictionary of field types you can use to create and decode web forms:
>
> https://pypi.org/project/dnsextlang/
>
> For perl users, it's built into recent versions of Net::DNS.
>
>> Uh, think the long tail of UI's. Even $megacorps use them. And they
>> don't look kindly to monkey patches either.
>
> No kidding. You extend the UI once to use the extesion language to
> create and parse forms for rrtypes, then fetch the rrtype descriptions from the
> DNS. It really works, I use it in my own DNS provisioning crudware.
>
> But as far as I can tell, nobody else does.
>
> R's,
> John
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
