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 22:05:02 -0000

>> 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.
>
>Hex is not much easier for humans to read and write than binary.  

Uh, this is not news.

>> # 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
>
>Is this "scruffling around on the web" going to be done automatically?

Not on any system that I run.

>If not, I don't see any real advantages to just downloading updated
>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.

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

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

>How much do you really think is being saved by using binary encoded
>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: 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