Subject: Re: draft-iab-dns-choices-02.txt comments

From: John Levine <[email-masked]>
Date: 9 Jun 2005 02:17:55 -0000

>I believe that dns-choices is fundamentally flawed, it will be ignored
>by developers that decide to use TXT and does not provide an useful
>way forward.

I agree that the draft is fairly badly flawed, but I completely
disagree about what the problems are.

The first 2/3 is basically fine, the discussions about all of the ways
that one might add new data to the DNS and why most of them are bad
are fine.  But then section 5 waves its hands, and makes lame
arguments against the difficulty of adding new RR types.  The reality
is that adding new RR types is hard, and the honest thing to say is
yes, it's hard, there are barriers to doing so, but they're worth the
pain.  

The claim that most DNS servers and clients handle unknown RR types
is, unfortunately, just false.  One of the things we learned during
the MARID fiasco is that for some reason our pals in Redmond defined a
DNS API with a separate call for each RR type, and no escape for RR
types not in the API.  They then have built this API into a whole lot
of computers in use all over the world, and none of those computers
can handle new RR types at all, neither serve them nor look them up.
Yes, they should fix it, but getting them to do so and to get it
shipped to all the customers won't happen overnight.

It also understates the difficulty in assigning type numbers to RRs.
I am surely not the first person to note that the number of RR types
is the same as the number of TCP ports, and to wonder why assigning RR
numbers has been so much more of a problem than assigning TCP ports.

It also needs to address the issue of how front end and back end tools
will deal with hitherto unknown RR types beyond dumping them out in
hex.  It occurs to me that proposed RR types invariably consist of
sequences of a small set of basic data types, integers of various
lengths, IP addresses, strings, and names.  I would think it would be
easy to define a template language to describe new RRs, perhaps in
XML, so to upgrade our tools to handle new types we only need to
install an updated template, not a new version of the program.  (XML
bloat doesn't matter, this XML only goes into the DNS management
applications, not into the DNS itself.)

A more honest assessment of the current problems of new RR types and
some direction about solving those problems would make this document
a whole lot more persuasive.

R's,
John

--
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: David MacQuigg <[email-masked]>
Date: Thu, 09 Jun 2005 09:03:24 -0700

At 07:58 PM 6/8/2005 -0500, wayne wrote:

<...>

>I believe what needs to be done is to allocate say, 100 new DNS RRs as
>clones of TXT records (say, TXT0-TXT99).  There are tens of thousands
>of RR numbers sitting totally unused.

This seems like a halfway step, like the old DOS database I used in the 
late 80's to run my business.  It had a scripting language, but no 
variables!!  After enough users screamed, they gave us a small number of 
variables with fixed names, like the above.  It seems very odd that the 
design of DNS allowed records to have a "class" attribute, but not a much 
more useful "name" attribute.  I don't like forcing the "type" attribute to 
serve as a "name".

My current plans are to prepend the necessary record names to the domain 
name, like CSV is doing with _client._smtp.<domain>.  TXT type is adequate 
for anything I will need.  As I understand it, the only problem is that I 
can't use wildcards at the same time.  So I can't have 
_client._smtp.*.<domain>.  That is a limitation I can live with, but 
something that might be nice for a future extension of DNS.

<...>

>The only
>problem with TXT is that their space is limited, but that can be fixed
>as easily as it would take to create one single other new RR type.

Sorry for a dumb question, but what will it take to raise the 512-byte 
limit, without a fallback to TCP, which would negate the UDP speed 
advantage, and make me want to use the more versatile HTTP for general 
queries?  Even if we had to wait 10 years for some old machines to die, it 
would be a nice improvement in DNS.  Meanwhile, we can continue to use 
multiple queries to linked records for anything over 512 bytes, and when 
the Internet is ready, make a smooth transition to a single, more 
streamlined record.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 10 Jun 2005 09:49:40 -0400

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. Please fix your 
   subscription addresses. ]

On Jun 8, 2005, at 20:58, wayne wrote:

> Instead of using TXT, it is using a binary format called KR.  That's
> what dns-choices says to do, right?  So this is good, right?  Well,
> they have used used RR type number 1010 (decimal), which isn't in the
> range that RFC2929 says to use.  Ooops.  So now there are people out
> there deploying 1010 RR numbers and if IIM dies, that RR number will
> be polluted for many years to come.
>

What is the difference between this and pullute by having used  
TXT4711 for the same thing?

    paf

---

From: wayne <[email-masked]>
Date: Wed, 15 Jun 2005 10:32:57 -0500

> TXT4711 for the same thing?

The TXT4711 would hopefully have a magic number to allow us to
distinguish the different uses of the same RR number.  Right now, if
we assign RR number 1010 to someone else, and you get a query, you
have a binary glob that may or may not be the IIM KR record.

Ok, we can probably tell KR records from the other records by looking
at the size of the record and the format of the data.  But, that is
just a "really bad magic number".

-wayne