[DNSOP] Re: [Ext] Re: �^�`�GRRTYPE Application: UTXO (Data RR)

[Ben Schwartz <[e-mail]>]

On Fri, Oct 30, 2026 at 4:22 PM Robert Edmonds <[e-mail]> wrote:
> I'm not sure what is reductive about Ray's argument. Actually, I have
> the same question. Would the "DNS layer" be expected to validate the
> CBOR content of the record data in a hypothetical CBOR RR? Specifically,
> would a primary nameserver need to verify that the CBOR RR's data is
> valid, well-formed CBOR data when loading RR's from a data source, such
> as a zone file?

I would say "parse, don't validate".

DNS record types serve a few different purposes.  One of them is to
support authoring and inspection in a natural form.  Having zone files
and "dig" output be human-readable (to the extent possible) is
extremely valuable for ordinary operations.  So ideally, a
hypothetical CBOR RR type would have a human-readable presentation
format, which needs to be parsed by the primary nameserver.  (For
CBOR, I think this would be the "diagnostic notation"
(http://rfc-editor.org/info/rfc8949/#section-6).)

> Would secondary nameservers need to verify that CBOR RR
> data in an incoming zone transfer consists of valid, well-formed CBOR
> data (and what would they do with the zone transfer if it fails such a
> check)? Would recursive resolvers need to parse CBOR RR data that they
> receive from an authoritative nameserver to ensure that it is valid,
> well-formed CBOR data before passing it on to a client?

No.  Optional and probably discouraged.  Same goes for pretty much any RR type.

For SVCB parameters, after some debate in DNSOP, we declared that
"resolvers SHOULD limit validation to specified constraints" (if they
validate at all, which is optional).

...
> I notice that the IETF has standardized other data formats as well, for
> instance: XML, JSON. Do we need XML and JSON RRTYPEs as well?

TXT works well enough* for these, because they don't require any
presentation<->wire format transformation.  If we wanted to use a more
compact wire format, then we would indeed need a new RR type ... which
(for JSON) is pretty much this idea again.

--Ben

*Well, almost well enough.  The 255-character chunking thing is an
inconvenience.