Subject: Re: more thoughts on a set of TXT record clones

From: John Levine <[email-masked]>
Date: 11 Jun 2005 02:00:36 -0000

>I was thinking a little more about my proposal to create a set of TXT
>record clones that use magic numbers.  I think two things would help.

After thinking about it for a while, I've come to the conclusion that
although your proposal isn't horrible, it involves about 90% of the
work involved in fixing the RR type problem for about 30% of the
result.

A large part of the problem is software that doesn't handle any new RR
types at all.  For the most part, it's as easy to fix it to handle all
possible types as to add one or two more.  Sure, it's more code, but
writing and debugging the new version is about 2% of the work, and
getting it installed everywhere is 98% of the work.

So if you're going to upgrade programs like bind and dig and nslookup
and tinydns-data (from djbdns) to encode and decode a few new faux
text types, why not do something like my XML trick so they can handle
any new types and solve the problem once and for all?

--
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: Douglas Otis <[email-masked]>
Date: Sat, 11 Jun 2005 08:00:54 -0700

On Fri, 2005-06-10 at 18:43 -0500, wayne wrote:
> 
> First, the magic number should be restricted to be exactly the first
> substring in the TXT record.  The TXT clone record could have any
> number of strings, but the first is reserved for being the magic
> number.
> 
> Secondly, instead of letting people choose which TXT clone to use, we
> should hash the magic number down into the set size.  This would
> reduce the chances of many people picking "easy to remember" numbers,
> and would reduce the amount of information that people have to enter.

Without different prefixes, collisions will risk exceeding a response
size.  This would be more of a problem for SPF or any new key scheme
with typically large RRs.  Overloading is less of a problem when the RR
is small.  The idea of using XML increases the size of the RR type for
SPF by another 20%, making size more of an issue.

When dealing with large RRs, get a number for the application.  Nothing
is gained by encouraging use of potentially large overlaid RRs.  To
reduce the size, it also makes sense to convert text to a binary
definition.  For SPF, some have suggested compression.

The problem faced in MARID concerning new RRs was push-back by Microsoft
claiming they use pre-canned RPC to their firewall for DNS.  A new RR
type must be compelling enough to be accepted in service release.
Lumping together new TXT records (to codify wasteful text) would be less
useful than finding a solution where Microsoft uses RFC3597 in their
scheme.  

-Doug