# 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 `\# <len> <hex>` 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)