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

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

>it's because there will always be devices who hope for simplicity in what
>they have to receive and parse and store and forward.

Of course.  But it strikes me that we're only talking about the bits
of DNS software that translate between RR's and zone-file-ese and have
to display or read representations of arbitrary RR types.  The caches
and resolvers and most of the other stuff that's performance critical
don't parse zone files so they aren't affected.  The programs that use
the data in new RR types are going to have the format hard coded, just
like it is now, because they know what types they use.

And it's just syntactic sugar.  Any software that's going to handle
new RR's has to do what RFC3597 says and handle \# for RRs that don't
have any other format.  This just makes the new types easier for
humans to read or write.

>> dig download it in order to parse/print an new record type scares the
>> heck out of me.  It would be like activeX for DNS.

Ugh, that's not what I had in mind at all.  Think of it as font files
or stylesheets for bind and dig, e.g.

$ dig argle.bargle.com any

argle.bargle.com. IN TYPE497 \# 75 20390df02390a9d09d ...

^C

# oh, look, it's a FOOB record, scruffle around on the web, find a
# suitable 497-foob.xml file, stick it in the directory where dig and
# friends look for them

$ dig argle.bargle.com any

argle.bargle.com. IN FOOB 93 "sasquatch" 42 jingle.jangle.org.

My goal isn't to handle the semantics of every possible
Turing-complete monstrosity that might come out of DNSSEC and dynamic
updates and other stuff that extends the way that DNS works.  It's to
make it easier to add record types for new kinds of data for non-DNS
applications that publish data in the DNS.

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: wayne <[email-masked]>
Date: Sat, 11 Jun 2005 08:33:27 -0500

> have any other format.  This just makes the new types easier for

Hex is not much easier for humans to read and write than binary.  

> or stylesheets for bind and dig, e.g.

Yes, I know what you had in mind, it still gives me the willies.

> # suitable 497-foob.xml file, stick it in the directory where dig and

Is this "scruffling around on the web" going to be done automatically?
If not, I don't see any real advantages to just downloading updated
version of dig and friends.  And by "friends", you are going to have
to include a heck of a lot of GUIs and webforms.  If not, then you are
asking for automatically downloading description languages without
user intervention.

In either case, you have now opened up the wonderful world of record
descriptions that either intentionally, or accidentally, trigger bugs
in dig and friend.

No.  This is a complex solution for a simple problem.

Again, one of the Unix file philosophies is that text files aren't
really that much worse than binary files and the advantages of plain
text greatly outweighs the disadvantages.

How much do you really think is being saved by using binary encoded
DNS records?  Remember to include all the overhead of UDP/DNS packets
in your calculations.

SPF records have one most complex record formats of any DNS records,
and they can also be very large.  When I wrote the libspf2
implementation of SPF, I worked hard to create a compact, portable
binary format for SPF records.  The result, after a lot of study, is
that in the vast majority of cases, there is no practical advantage of
using binary encoded SPF records over plain text.

Wow.  I just rediscovered the same insight that the Ken, Brian, et al,
figured out 30 years ago with Unix.

What DNS records *really* need to be encoded in binary?  Thirty years
after Unix was created, what situation is parsing a text record *so*
time critical that a binary encoding is justified?

Even though binary records *really* don't decrease the size of the DNS
packets significantly, if want to reduce the size of DNS packets,
figure out a way of gzipping them the way you can gzip html files.

Things should be kept as simple as possible, but no simpler.[*]

-wayne

[*] Yes, I think SPF is pretty close to being as simple as possible.
Seriously.  I understand that many people might find it ironic that I,
an SPF proponent, am arguing for TXT records, while John, a FSV
proponent, is arguing for arbitrary complex description languages.

---

From: David MacQuigg <[email-masked]>
Date: Sat, 11 Jun 2005 03:54:08 -0700

[ Moderators note: This post needed manual approval.

   Either it was posted by a non-subscribed address, or the posting
   was too large ( > 20000bytes ) for this list.

   With the massive amount of spam, it is easy to miss and therefore
   delete posts that need manual approval.

   Please use your subscribed address to post, or shorten your
   postings by using links instead of attachments. ]

At 07:00 AM 6/11/2005 +0000, John Levine wrote:

>to display or read representations of arbitrary RR types.

Exactly.  Maybe we could even define a default format for these displays - 
similar to what is used in bvi, hex on the left, ASCII on the right.  This 
would involve no special-purpose activeX plugins.

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