Re: [gnso-ff-pdp-may08] Information based solutions instead of policy based solutions

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Dave mentioned:

#The scenario I think about when we talk about a free-format field like TXT
#is the following:
#
#Community A says "Let's use TXT in the following way: dotted quad followed
#by 3 space separated fields."
#
#Community B says "Let's use TXT in the following way: dotted quad followed
#by 1 field."
#
#How does a DNS client know whether the TXT record it receives has been 
#populated by a name server attempting to comply with Community A or B? 

It doesn't know, and doesn't/shouldn't care. TXT records are not meant to 
be "interpreted" by the DNS client, anymore than a web browser is meant to
"know" (or care) that a page with a table of numbers represents 
shots-on-goal per year for the Stanley Cup or the number of Volvos per
year which have needed suspension repair work.

The entity requesting and consuming the data retains *interpetive*
responsibility, whether for the data received in a DNS TXT record, or 
the contents of a table in a web page. 

Interpretive context may be provided inline (via things like column and
row headings), or through external documentation, or potentially via 
instantiations coded into software or software libraries.

The server and client just provide buckets to carry that data, they don't
look at what's inside the bucket as long as it fits. 

#What if a name server must comply with both communities?

RFC1035 3.3.14 says "TXT RRs are used to hold descriptive text. The 
semantics of the text depends on the domain where it is found."]

This is precisely the case here. Marc's TXT records from one synthetic
subdomain might have dates, while another one might have name server 
flux counts, and a third might have the name of the registrar who 
registered a given domain, or he might choose to combine the whole
shooting match into one TXT record.

No one should arbritrarily retrieve a TXT record and expect to have
any guarantee that they'll know what they get means. They may see
something they recognize (like an SPF record), or the might get
a snippet of base64 encoded WAV file. You just don't know. This is
just like touching a web page. You might get a blog posting, or
you might get a list of MVS abend error codes

#Now, look at your SpamHaus example. You've gone beyond just saying "hey 
#let's use TXT" to "hey, let's use TXT in a manner consistent with a 
#standard".

They actually return A's, not TXT's, but let's not get hung up on
details. :-)

And unfortunately, while they may adhere to standards in the sense
that they're returning A's in 127.0.0.0/8 space, the *meaning* of the
coded A's they return mean nothing unless you (or software you use)
know how to interpret a given code from the 127.0.0.0/8 space. 

A 127.0.0.11 (or whatever) from Spamhaus may not be the same as 
a 127.0.0.11 from Joe's Bait Shop's Blacklist.

You need the magic decoder ring to know what the returned value means.

#In other words, to achieve what you want, you could use the 127.0.0.0/8 
#space as a community/policy identifier for Marc's purpose.

Let's consider that -- assume Marc wanted to have the date of domain 
creation returned. I suppose he could do:

127.0yy.0mm.0dd

to encode a year/month/day of the month date into an A record, but I 
don't see that as being as clean as just returning a TXT record of the 
form

yyyymmdd

and what if decides that he really wants the date AND the time a domain
was created?

yyyymmdd hhmmss 

sure seems like a natural for a text record, although I suppose I could
pack all that into a dotted quad through some sort of complex encoding
scheme. 

True, we could quibble about the relative length of the payload, 
or the cost of encoding numeric values into ASCII and back out, but
given so much other stuff that's encrusted with material overhead, it is
hard to get really rev'd up about byte economy any more (although things
like Puppy and other small Linux distros for machines with limited memory
space may give me hope that people still do really pay attention to 
byte counts)

Regards,

Joe

Disclaimer: all opinions strictly my own.