RFC 3597 defines a syntax for generically presenting RDATA of an unknown
type, but possibly (not my take) leaves some room for creative
differences:
https://tools.ietf.org/html/rfc3597#section-5
5. Text Representation
In the "type" field of a master file line, an unknown RR type is
represented by the word "TYPE" immediately followed by the decimal RR
type number, with no intervening whitespace. In the "class" field,
an unknown class is similarly represented as the word "CLASS"
immediately followed by the decimal class number.
...
---> An implementation MAY also choose to represent some RRs of known type
---> using the above generic representations for the type, class and/or
---> RDATA, which carries the benefit of making the resulting master file
---> portable to servers where these types are unknown. Using the generic
representation for the RDATA of an RR of known type can also be
useful in the case of an RR type where the text format varies
depending on a version, protocol, or similar field (or several)
embedded in the RDATA when such a field has a value for which no text
format is known, e.g., a LOC RR [RFC1876] with a VERSION other than 0.
---> Even though an RR of known type represented in the \# format is
---> effectively treated as an unknown type for the purpose of parsing the
---> RDATA text representation, all further processing by the server MUST
---> treat it as a known type and take into account any applicable type-
specific rules regarding compression, canonicalization, etc.
In particular the middle paragraph's *MAY* could appear to suggest that
the choice is not just one of output format, but that *on input* parsers
don't need to support the generic "\# <len> <hex nibbles>" form for
*known* types.
I don't read it that way, rather my reading is that the generic RDATA
format MAY be selected on *output* for portability reasons, but *should*
MUST be supported for all types, whether known or unknown, on input.
I was therefore surprised to find that BIND 9.14 refuses load zone files
with TXT records in the generic form, for example named-checkzone does
not accept:
example.org. IN TXT \# 4 deadbeef
but does accept:
example.org. IN MX \# 3 000000
example.org. IN TXT "\222\173\190\239"
Is this is a BIND feature or bug? It therefore seems that if one wants
to portably output the generic encoding, it is imperative to output the
rrtype as, e.g., TYPE16 rather than TXT, even when the type's standard
name is known, but the generic encoding is desirable for some reason.
The examples in the RFC do include combinations of known type, generic
data and vice versa:
e.example. IN A \# 4 0A000001
e.example. CLASS1 TYPE1 10.0.0.2
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
