Subject: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use

From: "Gordon Fecyk" <[email-masked]>
Date: Fri, 11 Jun 2004 14:39:49 -0500

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

-- 
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email-masked]>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 11 Jun 2004 22:11:57 +0200

> name along with a value for the attribute.

We used it for an early draft of MTAMARK (MTA=yes and MTA=no) and gave up
on it (after some helpful discussion with Arnt Gulbrandsen):
------------------------------------------------------------------------
   Storing arbitrary string attributes in the Domain Name System
   [RFC1464] is a technique described and used at least since 1993. One
   solution that we took into consideration has been to store string
   attributes like "MTA=1" or "MTA=0" at the same level as PTR records.

   However this method does not support specific queries and has a high
   overhead for parsing the responses, is prone to naming collisions and
   will trigger errors and problems in old implementations of DNS
   servers with the 512 byte size limit.
------------------------------------------------------------------------

With the above you would ask "gimme all your TXT records" and choose
which one suits you. Asking for e.g. _marid.example.org is an exact
and specific question with (if configured correctly) exactly one answer.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Douglas Otis <[email-masked]>
Date: Fri, 11 Jun 2004 16:27:10 -0700

> 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