Subject: more thoughts on a set of TXT record clones

From: wayne <[email-masked]>
Date: Fri, 10 Jun 2005 18:43:41 -0500

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.

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.

So, the records could look like this:

foo.com.    TEXT  "SPFv71" "some cross between APL and perl"
bar.com.    TEXT  "PGP"    "your favorate PGP key"

If we allocated a set of 32 TXT record clones, then the "SPFv71" and
"PGP" keys would be hashed down into the range of 0 to 31, and then
added to the base RR number for the set.

-wayne

--
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: John Levine <[email-masked]>
Date: 11 Jun 2005 02:00:36 -0000

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

---

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

---

From: wayne <[email-masked]>
Date: Fri, 10 Jun 2005 22:58:15 -0500

> any new types and solve the problem once and for all?

Well, as I mentioned in another post, I don't care if you use xml,
asn.1 or java for the record description language, having things like
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.

-wayne

---

From: Paul Vixie <[email-masked]>
Date: Sat, 11 Jun 2005 04:17:28 +0000

> > any new types and solve the problem once and for all?

the reason rdata isn't self-describing isn't because in 1980 nobody had
invented self-describing (ASN1-like or XML-like) data structures, nor is
it that pvm had never heard of doing stuff this way.

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

true then, true now.  probably true always.  you want xml?  stick an A RR
or AAAA RR or both in the dns, use it to open a tcp session, and go get it.

> heck out of me.  It would be like activeX for DNS.

yea, verily.

---

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

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

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

---

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

> 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

---

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

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

Uh, this is not news.

>Is this "scruffling around on the web" going to be done automatically?

Not on any system that I run.

>version of dig and friends.

The crucial difference is that updated versions of dig and friends do
not exist.

> And by "friends", you are going to have to include a heck of a lot
> of GUIs and webforms.

Yeah, that's my point.  The current situation where you have to patch
a vast list of programs each time you add a new RR means that in
practice the programs don't get patched and there's no new RRs.  That's
why I want a config file that doesn't require writing new C code.

>descriptions that either intentionally, or accidentally, trigger bugs

I think you are imagining a much more complex description language
than I am.  I'm thinking of something that can describe a fixed list
of fields of a small known set of types, perhaps with a special case
for repeated fields at the end.  That's it.  The description of an SPF
record would be that it's a repeated list of strings.  If you thought
that it would attempt to describe the syntax of the strings that are
allowed inside an SPF record, I agree that would be nuts.

XML is overkill for this kind of description by about two orders of
magnitude, but since there are widely deployed tools to publish and
parse XML already, I think it's easier to use them than to invent
yet another special purpose language.  (Well, actually, the special
purpose language would be described by a DTD.)

>DNS records?

In terms of record size, nothing.  In terms of code complexity in
clients, not enough to be a big deal.  The problem is the overloading
of multiple kinds of data into TXT, not the bit encoding within the
record.  I would have thought that was obvious from the previous
discussion on this topic.

>[*] Yes, I think SPF is pretty close to being as simple as possible.

We'll have to agree to disagree rather violently there, particularly
in view of the vast number of published SPF records that are just
plain wrong.

R's,
John

---

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

Uh, this is not news.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sun, 12 Jun 2005 11:44:32 -0700

> purpose language would be described by a DTD.)

RFC3597 standardizes a text representation handled by the various DNS
tools to bridge between the text entry of unknown structures into their
true binary form.  A token of '\#', followed by an unsigned decimal
integer byte length, declares the use of this convention.  It represents
a binary format with two hexadecimal characters for each actual byte.
This mirrors a very common convention of a binary Tag/Length/Value (TLV)
format.  As most problems occur with ill-formed data, adding a checksum
would also be good practice.

Defining a new RR type, that comprises a complex structure, should be a
matter of defining a byte Tag value list for this RR type.  This list
would enable an extensible TLV format by defining the content of each
tagged element.  The tools for this new RR type should generate text
compatible with RFC3597 text representations.  Cut and paste this
RFC3597 format between these tools that specifically generate or
interpret the binary information between the human friendly forms.

DNS is not well suited for XML.  The benefits derived from DNS relate
largely to speed and efficiency.  DNS is a translation between a human
friendly name into a machine friendly response.  By machine friendly,
this is largely a matter of size.  Speed depends upon this information
being cached in dynamic memory, rather than hard storage.  Here size
matters.

XML on the other hand is designed to be human friendly.  As we have
seen, humans make mistakes and need tools anyway when generating complex
structures.  It is going down a slippery slope to suggest there is
little difference between data structures suitable for web pages, and
that used for DNS RRs.  This strikes me as a bad idea, although I
concede your point about these text parsers being ubiquitous.  One
should still use generation tools which will result in the same cut and
paste operation.  TLV for binary structures does not represents an
obstacle at all, and why this method is so widely used.  XML allows far
greater complexity, but this is not warranted. 

The path registration scheme being utilized by SPF already demands a
minimum of more than one hundred subsequent references to other DNS
records.  This already creates a significant size concern.  Without
proficient use of often overly broad CIDR notation, path registration
can easily exceed even these limits.  Having a publication process made
easy, while ignoring the aspects of reading overlooks the value of DNS.
If the new RR type becomes popular, and people want to view the content
of these structures, conversion tools will merge with DNS utilities,
perhaps by way of simple scripts.

DNS should not be seen as a UDP version of HTTP.  As was the conclusion
of a lengthy debate in MARID, XML will add 20% in size to an already
overly large amount of data, from the perspective of DNS.  Of course,
this would not be true for HTTP.  The paradigms are vastly different,
hard storage caching of unlimited record sizes exchanged using TCP.  

-Doug

---

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

---

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

[ 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. ]