104 lines
3.6 KiB
Markdown
104 lines
3.6 KiB
Markdown
|
# 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
|
||
|
|
||
|
[Sectoin 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)
|