# Various issues with RFCs ## RFC 3597 - "Handling of Unknown DNS Resource Record (RR) Types" [Section 5](https://tools.ietf.org/html/rfc3597#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 `\# ` format can also be a valid known representation it is a bad idea to mix them (the obvious example being `TXT`). 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 `TYPE...` representation must always be followed by the generic representation of RDATA. ## RFC 4034 [Section 3.2](https://tools.ietf.org/html/rfc4034#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 [Section 3.1](https://tools.ietf.org/html/rfc6895#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. > > [A-Z][A-Z0-9\-]*[A-Z0-9] > but not > (TYPE|CLASS)[0-9]* TYPE 255 doesn't have a clear mnemonic though; usually `ANY` is used, but the official name is `*`. Now: - `*` doesn't match the required format - `ANY` conflicts with CLASS `ANY` (255) - but a mnemonic is required because the TYPE is allocated RFC 6895 indicates that `*` means `(ALL/ANY)`, so one might read it suggests using `ALL` as mnemonic for TYPE 255. Side note: RFC 1035 doesn't specify a mnemonic for (Q)CLASS 255 either, but the registry put `ANY` between `(`..`)`, 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. See also: - Re: [dnsext] WGLC: RFC6195bis IANA guidance (https://mailarchive.ietf.org/arch/msg/dnsext/kKBfBhQIJmRDQ-xb_iJD-A4EeZE) ### Proposal Given the common use of `ANY` for TYPE 255, it should be marked as the official mnemonic. Since QCLASS `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. See also: - [dnsext] rfc6195bis draft : thoughts on CLASS sub-registry (https://mailarchive.ietf.org/arch/msg/dnsext/fA086yr5V3QrVkmxF7HcuBIX92A)