draft-iab-dns-choices-02.txt comments

[wayne <wayne@schlitt.net>]

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 believe that that dns-choices flies in the face of decades of
successful Unix semantics about data storage in files.


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.


What the Unix philosophy about files is that there shouldn't be a
"file type" (RR number), most things should be put into flat text
files.  Files should be distinguished by "magic numbers", located
within the file.  These "magic numbers" do not need a central
authority to allocate them.

While text is often not as compact as binary formats and require
conversions/parsers, the advantages of being able to use standard
tools to edit and debug the files is huge.  Binary files are often not
significantly smaller, nor are the overhead of parsing is often
irrelevant.

Of course, the Unix philosophy of flat text files was developed back
in the 1970s when storage space and CPU cycles were far more expensive
than they are today, so these considerations are even less relevant 30
years later.



Reasonably long magic numbers are unlikely to collide, even globally.
When localized to particular application area, they are even less
likely to collide.  If one magic number is in widespread use, and
someone comes along and tries to re-use it, they will quickly discover
the collision and they, being the newer and less popular use, will
almost certainly back down.  Intelligent designers will do a survey of
the application area first to make sure there isn't a problem with
collisions.  Two unpopular systems that use the same magic number are
unlikely to collide because they are unpopular.

History has shown that collisions with Unix magic numbers is rare.  An
unofficial, first-come first-served registry of (TXTxx, magic number,
application area) tuples could make it even more rare.


By having, say, 100 TXT record clones to choose from, applications can
choose one that keeps the RR set small.  If there ever comes a day
when it looks like those 100 TXT RR clones are filling up, we can
allocate another 100, or even 1000 or 10,000 TXT RR clones.


The whole dns-choices I-D makes the assumption that TXT space is
limited, and instead of changing that assumption, it goes off claiming
that new, special purpose RRs should be used.


There are two conflicting problems with allocating new RRs.  First
off, the vast majority of ideas never take off, and if you allocate a
new RR type for every harebrained idea, we would run out of RR numbers
quickly and we would have a very long list of RRs that aren't used.
Secondly, if you try to do some sort of gate-keeping to make sure only 
"popular"/"useful" RRs get allocated, then that will be too much work
for people who want to just test an idea and they will go off and use
TXT RRs.  Of course, if that test proves successful, it will be too
late to change from a TXT.

Of course, right now we have a long list of RR numbers that have been
allocated, but hardly ever used, and the process of getting a new RR
number allocated is far too burdensome.


Let's take an example of Cisco's IIM email anti-forgery system.
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.  

And how am I supposed to look to see if these KR records exists with
dig?  Maybe there is a way, but I couldn't find it.  And how is this
stuff entered or displayed?  If you think that hex is as easy to read
as text, well, why aren't you reading this as hex now?  And since the
goal of IIM is to be used everywhere that email is used, every MTA,
every box that a mail admin uses, every DNS hosting service that lets
people create RRs will need to be updated with special code to deal
with KR records in a nice way.

Of course,Cisco's IIM system is defined by an I-D published on the
IETF website so it is easy to find.  How many other systems are there
that have gone and defined some other "easily typed" RR number that we
don't know about?


Dns-choices is doing nothing but tilting at windmills.  People will
continue to use TXT RRs because they are the best solution.  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.



-wayne


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