Subject: Re: concerned - RE: TXT records, are they alive?

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Apr 2003 17:23:18 +0000

> Why do the application writers of this software opt to use an existing RR
> in a manner not intended?  Why are they unwilling to define a new RR?

the biggest single reason is that bind was broken for many years in its
handling of unknown resource record types.  on the one hand we couldn't
transfer or cache them if we didn't know their interior structure, and
on another hand we compressed the interior structure in variance with the
dictates of rfc1035.  this pretty much made new rr types impossible to
roll out, and although several did make it through, it took a decade for
them to be widely usable.

now that bind isn't broken in this way, and now that there are other widely
deployed implementations (both open source and not), it's reasonable to
consider putting more rrtypes into the field.  however, institutional memory
means we have some cultural inertia to overcome before this can happen.

--------

another reason, which you aluded to, is that the ietf makes new rrtypes
hard.  again this is cultural -- our work is done in an environment where
any single loudmouth bozo can so polarize the debate on any given issue
that there will be no clear consensus.

since ietf is open to all comers, there's apparently no fix for this other
than to wait for people to move on to some other area.

(this isn't iesg's fault, they'll approve anything that's technically
reasonable and has WG consensus... and remember that our area director
found some embarrassing glitches in the last thing he was asked to approve,
and it became clear that not very many of us had actually read the thing
that we claimed to have come to consensus on.)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Apr 2003 17:34:49 +0000

> Even if the IETF were a rubber stamp and the code writers were
> infinitely fast, people don't upgrade their server software very often. 

upgrades of that kind for this reason are no longer nec'y.  the need was
due to errors in old versions of bind, which are no longer the majority
and need not be coddled.  current bind8 and bind9, and as far as i know
current djbdns and mswin, are all capable of both caching and transferring
rrtypes which were unknown at the time of the software's release, and all
of them avoid compressing any rdata which was did not exist before rfc2181
(even though by law, this should apply to all rdatas after rfc1035.)

> So you'd put new adopters of your application in the position of asking
> their DNS administrators to take a software upgrade and add records of a
> type they don't understand.

not any more.  and for bind's part in having made it once so, i apologize.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 21 Apr 2003 16:47:18 -0700

The problem with TXT record is simply a result of an age old problem, how to
support experimental deployment in a way that can transition to a permanent
solution?

Look at the number of X-Headers end up in use that should be commonly agreed
standards. It is the same issue.

The IETF has been burned both ways. In the past it would hand out numbers,
they would get used and then there would be a need to fix something, only
the existing deployment would be a fait acompli.

The opposite problem is when the OID never gets assigned because someone is
playing games fillibustering for three or four years so the draft never gets
to RFC, the code points are never assigned.

I don't think there is an ideal answer to the problem. At the moment the
IETF is operating in fear of the unknown mode, its proceedures simply take
too long for any viable product plan to depend on them. I have been waiting
several years now for the OID for logotypes in certs to be assigned.

TXT records do have deployment advantages, they also have major limitations,
you cannot query for particular types of TXT record. They are perfectly
adequate for proof of concept however.

		Phill

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 22 Apr 2003 11:29:16 +0200 (CEST)

On 21 Apr 2003, D. J. Bernstein wrote:

> Greg Hudson writes:
> > And they don't use a more generic RR type, like TXT or UNSPEC, because
> > you'd have to parse a DNS packet to do so, which is a lot harder than
> > calling gethostbyname() and comparing to a few IP addresses.
>
> Actually, the RBLs provided TXT records from the beginning (although the
> big ones that use BIND have dropped the TXT records to avoid some BIND
> performance problems), and most of the initial client implementations
> used those records.

Its worth noting that these RBL-client implementations merely checked for
the existence of a record at the appropriate spot, and if it was a TXT
record, quoted said TXT record in the rejection message.  They didn't
actually parse the TXT record that I'm aware of.

This is more ontopic for spamtools or spam-L though, not namedroppers.

--==--
Bruce.