rust-dnsbox/RFC-nits.md

104 lines
3.6 KiB
Markdown
Raw Normal View History

2017-12-28 18:12:23 +00:00
# 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)