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

[Paul Hoffman <[e-mail]>]

On Oct 30, 2026, at 13:21, Robert Edmonds <[e-mail]> wrote:
> 
> Paul Hoffman wrote:
>> On Oct 28, 2026, at 09:28, Ray Bellis <[e-mail]> wrote:
>>> 
>>> On 28/10/2026 15:57, Ben Schwartz wrote:
>>> 
>>>> A BINARY type would lose this ability, and encourage arbitrary opaque
>>>> data in DNS.  Perhaps this is what we want, but it is a big change
>>>> with some obvious downsides related to debugging and inspection.
>>>> Personally, I would be more comfortable with a "CBOR" RR type or
>>>> similar, as this at least offers the possibility of human-readable
>>>> visualization and editing.
>>> 
>>> I can see no rationale for constructing an RRtype that can *only* be used for CBOR.  Would the DNS layer be expected to perform checks that the content is valid CBOR?
>> 
>> This argument seems reductive. The "DNS layer" is not responsible for checking that the fields in an SOA record are valid, and yet SOA (and MX and ...) were all defined in the original DNS specification.
>> 
>> A rationale for requiring the BLOB-esque type to be CBOR is you don't need to have any other subtyping. CBOR tags are first-class data items, and a tag inside the CBOR can define what the data object is.
> 
> 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?

No.

> 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? 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?

See above.

> I'm also not sure what you mean by saying that the "DNS layer" is not
> responsible for checking that the fields in an SOA record are valid.
> It is; SOA is a well-known record type that contains two compressible
> domain names (the MNAME and RNAME fields). Receiving servers must
> decompress those fields to ensure that they do not inadvertently
> generate an invalidly formatted response when passing the SOA record
> along.

I see nothing in RFC 1035 that says that. But closer to your questions above: would an authoritative server reading a zone from file be expected to ensure that the fields in a DNSKEY record make sense cryptographically? I believe the answer is "no": only the validator does that.

> 
>> The DNS community is allowed to ignore IETF data format standards (in this case, a full standard), but in this case I propose that it does not.
> 
> 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?

I didn't say that we "need" a CBOR RRtype, just that a BLOB type that has an identifier field and a contents field would be better off as CBOR because managing the identifier field will be a mess, and that mess has already been solved in CBOR. 

--Paul Hoffman