On 5/17/2004 6:34 AM, Patrik Fältström wrote:
I think it is important to have the working group consider the topic of
re-using TXT records or using a new record type. It is important for
the working group to come to a conclusion on this topic before
developing a syntax, as this may have specific implications on that
syntax.
TXT is fine for developmental purposes, and it's probably a good idea to
use TXT during development of the more complicated RRs with multiple
subordinate data-types. Any such RR should be made binary before it goes
to the RFC Editor, howeveer. Production RRs must not use TXT; they are
overly large and thus cause message overflow problems, but they also
collide with other uses of TXT, and therefore cause RRset overload
problems (there's no way to distinguish between regular TXT, SPF TXT, and
other experimental TXT RRs bound to the same owner name). On the first
point, storing something like a 32-bit IP address and a six-bit mask as
TXT usually requires 37 octets, but can be written as binary in 5 octets,
allowing for much more data. On the second point, a company I used to work
for stored excerpts from "Get Smart" in TXT RRs in their zone for
debugging purposes, and it would suck to get all of those when all you
wanted was the ~SPF data.
As input to the discussion, I am working on a document regarding adding
data to DNS for new applications, and the current version can be found
in draft-ymbk-dns-choices-00.txt which just was made available.
draft-hall-dns-data-04.txt is "Considerations for DNS Resource Records"
with a couple of years behind it. If you see anything missing from that,
let me know. I'll look at yours this afternoon too.
it is possible to define a new record type with a more bandwidth
efficient binary format or perhaps a tokenized or compressed form of a
more verbose text syntax. However, it should be noted that new DNS
record types cannot take advantage of the existing DNS label
compression.
Private compression mechanisms are certainly usable within the confines of
the RRData section but the rule is that they must not contain data which
needs to be expanded by intermediary [non-participating] systems. As far
as that goes, the 'existing compression mechanism' is merely one example
of a class of compression mechanisms which cannot be used with new RRs.
The specific rule here is that pointers and variables cannot be used
unless the data they reference is static for the current RRset, but beyond
that knock yourself out.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/