Section 5 shows examples of how to mix and match mnemonics with unknown format rdata. -- Mark Andrews
> On 24 Oct 2025, at 00:07, Mark Andrews <[email protected]> wrote: > > No that is a malformed unknown record. > > MX \\# 18 000a02…O7…03…00 > > as I’m on my phone I’ll leave you to do the hex encoding of the domain name. > -- > Mark Andrews > >> On 23 Oct 2025, at 18:41, Miek Gieben <[email protected]> wrote: >> >> [ Quoting <[email protected]> in "Re: [DNSOP] subtyping for fun and p..." ] >>>> For RRs we fixed this by allowing unknown RRs, which have a presentation >>>> format and a >>>> wireformat, so all is good. But we never did that for unknown rdata fields. >>> >>> Actually we have. UNKNOWN format handles records where the presentation >>> format is subtype >>> dependent and you don’t know what that format is. If you can’t display the >>> record with a >>> subtype specific format you just display it in UNKNOWN format. BIND has >>> been doing this >>> since UNKNOWN format was proposed. ATMA, APL, ATMRELAY, IPSECKEY, and LOC >>> all fallback to >>> UNKNOWN format for unknown subtypes. >> >> interesting, so BIND parses: `example.org. IN MX \\# 2 0A mx.example.org.` >> just fine? My >> library certainly doesn't and 3597 didn't give me the impression this should >> be allowed. >> >> This is certainly something that might be worthwhile to document explicitly, >> and figure >> out how this would play out with SVCB and friends. >> >> Cheers, >> Miek >> >> _______________________________________________ >> DNSOP mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
