On 1/30/25 20:40, Paul Hoffman wrote:
Title: DNS Update with JSON
Status: https://datatracker.ietf.org/doc/draft-hoffman-duj
Ad version: 03
After the discussion in dnsop session today about escaping and doing
DUJ64 only, and reading through all the discussions on list to date, I
think we should adopt proposal by Robert Edmonds here:
https://mailarchive.ietf.org/arch/msg/dnsop/8mW0o9JOkAkjgZTSP3SqLiLO8QA
Namely the mandatory RFC3597 syntax.
Using RFC3597 for RDATA portion of the record-data (which would get
Base64 encoded anyway) will avoid lots of trouble with encoding and
decoding.
I have seen (and wrote myself) too many parsers which choked on specific
RR types in presentation format because of various quirks or simply lack
of updates.
Prime example to cover them all is RFC 7218:
Adding Acronyms to Simplify Conversations about DNS-Based Authentication
of Named Entities (DANE)
The DUJ generator has no way of knowing if receiver understands this,
even if TLSA RRs are supported. The same problem applies to all types
which allow extension, or generally are not present in RFC1034.
I personally argue even simple TXT RR with esoteric <character-string>
handling is so prone to mis-interpretation in the layers above DNS
library that shipping bytes is just safer!
If a receiver does not want to take in specific RR type it's not a
problem - the RR type number is easily accessible even without decoding
the RFC3597 blob.
Shipping bytes is lesson we learned with AXFR, and it served as well.
If UI wants to display the data then of course presentation format
should be used. But not for transfer.
BTW Paul, have you received some feedback from people who implement the
receiving end?
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
