On Fri, 2004-06-11 at 12:39, Gordon Fecyk wrote:
There is an alternative to a hostile take-over of the TXT record as I
mentioned.
Use a token such as "MARID-1" and follow this with a CRC-32c checksum
(good Hamming distance and code used in SCTP) of the entire
record where
the checksum field is treated as zero. Such as "MARID-1[FD034A45]..."
or perhaps "FD034A45_MARID-1...". See RFC3309 for an example
of language and code.
No one's brought up RFC 1464 yet, which describes how to store unique and
arbitrary information in TXT records in DNS. SPF does this, DMP does this.
It avoids the TXT record collision problem by describing a unique attribute
name along with a value for the attribute.
How does ISC dhcpd store its host information in the TXT records? And how
does it tell the difference between its own records and something else's?
Doesn't it use a token like RFC 3309 or an attribute format like RFC 1464?
There are few problems depending upon RFC1464. Over the following
decade, it never established a token registry as it claims is needed
before this scheme is usable. It also assumes a simple format offers
protection from otherwise arbitrary text. It is also experimental and
never adopted as a standard.
The concern is with the possibility of those using an asterisk in what
would be defined as a unique label in 'fubar' standard to identify the
TXT record placed as if a sub-domain. The publisher's motivation would
be to allow this TXT record to cover many sub-domains. There needs to
be a safe method of being able to identify compliance with a format from
standard 'fubar' and standard 'snafu'. The 16 byte overhead as with the
example token and checksum field will provide assurance there was not a
mistake made even if there are random character generators creating text
strings. An assumption a label can be used to isolate TXT records seems
fatal. Just as with RFC1464, a registry must be created for the tokens.
-Doug