stbuehler/rust-dnsbox
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
2e5a46e1b1
rust-dnsbox/RFC-nits.md
Stefan Bühler 2e5a46e1b1 fix typo
2019-07-01 10:37:49 +02:00

3.6 KiB
Raw Blame History

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 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 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 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:

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: