Various issues with RFCs
RFC 3597 - "Handling of Unknown DNS Resource Record (RR) Types"
Section 5 defines a generic (master file) format for unknown types, which can also be used for (partially) known types to be compatible with other software.
It also says:
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.
and provides examples:
e.example. IN A # 4 0A000001 e.example. CLASS1 TYPE1 10.0.0.2
I.e. it allows mixing unknown and known format.
Given that the
\# <len> <hex> format can also be a valid known
representation it is a bad idea to mix them (the obvious example being
It is acceptable to use the generic
CLASS... specifier with known and
unknown TYPEs, but the generic representation of RDATA must only be used
with the generic
TYPE... representation; and the generic
representation must always be followed by the generic representation of
Section 3.2 says:
The Signature Expiration Time and Inception Time field values MUST be represented either as an unsigned decimal integer indicating seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where:
- YYYY is the year (0001-9999, but see Section 3.1.5);
- MM is the month number (01-12);
- DD is the day of the month (01-31);
- HH is the hour, in 24 hour notation (00-23);
- mm is the minute (00-59); and
- SS is the second (00-59).
But in UTC the second sometimes might be
60 to handle leap seconds;
these value can't be represented in POSIX time (seconds since epoch
without leap seconds), so the
YYYYMMDDHHmmSS simply isn't exact UTC.
RFC 6895 - TYPE and CLASS 255, ALL/ANY and *
Section 3.1 says:
Allocated RRTYPEs have mnemonics that must be completely disjoint from the mnemonics used for CLASSes and that must match the regular expression below. In addition, the generic CLASS and RRTYPE names specified in Section 5 of [RFC3597] cannot be assigned as new RRTYPE mnemonics.
but not (TYPE|CLASS)[0-9]*
TYPE 255 doesn't have a clear mnemonic though; usually
ANY is used,
but the official name is
*doesn't match the required format
ANYconflicts with CLASS
- but a mnemonic is required because the TYPE is allocated
RFC 6895 indicates that
(ALL/ANY), so one might read it
ALL as mnemonic for TYPE 255.
Side note: RFC 1035 doesn't specify a mnemonic for (Q)CLASS 255 either,
but the registry put
), the same as it did for the
other mnemonic from RFC 1035.
The QCLASS 254 looks different again, but
NONE is probably a safe
mnemonic for it.
Given the common use of
ANY for TYPE 255, it should be marked as the
ANY is basically useless it could be obsoleted.
BCP 42 (currently RFC 6895) should be updated to say
ANY is a valid
mnemonic for both TYPE 255 and CLASS 255, and, if ambiguous, should be
interpreted as TYPE 255.