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

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Dave asked:

#I do not understand why TXT records [...]

DNS only knows about a finite number of "data types," so to speak, and
TXT records obviously have substantial ability to carry a wide variety
of fairly arbitrary text (or text-formatted) arbitrary data. 

My comfort with that lack of structure obviously reflects too much 
exposure to some ancient Fortran-based world where even CHARACTRER 
variables didn't exist, and Hollerith constants ruled 
(http://en.wikipedia.org/wiki/Hollerith_constant).

If you at least have CHARACTER variables, I mean TXT records, :-),
everything else is derivatively possible. :-)

Less historically, and more directly relevant, there are of course 
data delivery services which do data delivery by things like DNS-coded 
IP address values, one of the other "data types" supported by DNS.

These values are usually encoded in 127.0.0.0/8 space, consistent with 
the recommendations of the (draft) DNSBL BCP (see 
http://ietfreport.isoc.org/idref/draft-irtf-asrg-bcp-blacklists/ 
at section 3.5). 

For example, in the Spamhaus case, the codes they use are (see 
http://www.spamhaus.org/faq/answers.lasso?section=DNSBL%20Usage#200 ):

127.0.0.2       SBL     Spamhaus Maintained
127.0.0.3       ---     reserved for future use
127.0.0.4       XBL     CBL Detected Address
127.0.0.5       XBL     NJABL Proxies (customized)
127.0.0.6       XBL     reserved for future use
127.0.0.7       XBL     reserved for future use
127.0.0.8       XBL     reserved for future use
127.0.0.9       ---     reserved for future use
127.0.0.10      PBL     ISP Maintained
127.0.0.11      PBL     Spamhaus Maintained

But in some other cases you would need substanial gyrations to encode
the required data into just dotted quads. For example the Routeviews
AS Path zone returns data that looks like

% dig +short 35.32.223.128.aspath.routeviews.org TXT
"293 11537 4600 3582" "128.223.0.0" "16"

That would be fairly hard to cram into anything other than a TXT resource
record.

Anyhow, I guess the real answer to the "Why TXT records?" question
is a pragmatic "because they're there, and they would/do work." They
may not work *optimally,* but they really *are* a common choice. For
example consider use of TXT records to convey SPF/SenderID 
(see http://www.openspf.org/) preference data, e.g.:

% dig +short ietf.org TXT
"v=spf1 ip4:64.170.98.0/26 ip4:64.170.98.64/28 ip4:64.170.98.80/28 
ip4:64.170.98.96/29 ip4:208.66.40.224/27 ip6:2001:1890:1112:1::0/64 -all"

And before anyone says, "but that's SPF/SenderID, not DK/DKIM like the
cool kids use," let me add that DK/DKIM also avails itself of TXT 
records, so we need not add yet another thread for SPF/SenderID vs. 
DK/DKIM wars just to hash out relatively levels of badness when it
comes to DNS TXT record use. :-)

# [...] in the DNS protocol is the way to do it and no one has provided 
#a compelling argument why the using the DNS protocol in a non-standard 
#way is the preferred candidate. 

The reasons why DNS is the prefered way to do it are:

-- In today's increasingly filtered Internet, DNS is one of the few
   ubiquitously available protocols (the others arguably being HTTP
   and SMTP, but everything is increasingly subject to a loss of 
   end-to-end transparency)

-- DNS has an architecture which scales well, and which can deliver 
   truly amazing performance (e.g., it has managed to keep up with
   anti-spam-related uses)

-- It is a protocol which is already familiar to application and
   security software coders, because it is already widely used for
   things like DNSBLs

-- There's also a sort of satisfying symmetry to using DNS to fix
   what is fundamentally a DNS problem :-)

#If the information is simply arbitrarily constructed ASCII, you could 
#use other protocols. 

Absolutely true, but <insert protocol name here> either is less ubiquitous,
has more overhead, is less familiar to programmers or simply would tip 
over well before reaching the sort of performance levels DNS can deliver
as a distributed database.

Do you have a particular protocol in mind here, BTW?

#Maybe I'm too much of a protocol purist, but if I have a specific kind 
#of resource I want to the DNS to return, then I think the correct way 
#to design a protocol is to identify a new query and record type, not 
#to say, "in this ICANN policy and context, we are using TXT records 
#constructed in this fashion for this purpose".

Again, absolutely true. But a lot of bailing wire and duct tape and 
kludges and hacks are being widely used in the ugly modern era. 

For example, for some reason I'm reminded of layering applications on 
top of HTTP, and RFC3205 ("On the use of HTTP as a Substrate", 
February 2002). :-;

#Someone's got to write the DNS server code to populate TXT records 
#in this specific way.

Most DNS-delivered services either use a standard DNS implementation
(such as BIND), or RBLDNSD, and the DNS information service zone 
files themselves are pretty easily constructed using simple shell 
script filters (at least for stuff that's based on 
dotted-quad-to-something or domain-name-to-something mappings). 

#Is this all custom code? 

I don't think any custom code would be required (beyond the simple
shell script filters to build the specialized zone files). 

#Do you want ISC, Nominum, NSD/Unbound, etc. to include this in 
#libraries. 

No DNS software vendor action would be required (assuming TXT records
are all that's used)

#I also have no real sense yet what "scale" you are talking about. The 
#notion that every client PC is asking for TXT records from TLD name 
#servers is, well, quite a large scale.

... offset by things like caching, local mirrors of special DNS zones,
etc. A tremendous volume of special DNS traffic is already routinely
occuring in the war on spam... 

And when it comes to TLD name servers, I don't think the TLD name 
servers would need to be substantively involved, any more than they
are in things like the Spamhaus lists, or the SURBL, or the URIBL, 
say. In fact...

I don't believe Marc's proposal would require much of anything from
ICANN or anyone else, except perhaps (controlled) access to a list of
name servers, and perhaps (controlled) access to a list of domains
with their associated dates of creation, but if even that's too much, 
he could actually get what he needs from the operator of any large 
recursive resolver.

And heck, if he can't get that, he could *probably* build a list of
FF domains just by testing all the domains listed on something like
the SURBL or URIBL.

#If you are going to take this route for FF spam/email, what about 
#the next thorny problem that exploits DNS? More TXT record requests 
#from SIP Clients each to decide if the NAPTR records is suspicious?

[Odd you should mention SIP. It is funny how little application 
security work is going on in the VoIP space, as far as I can tell.

When I looked at this recently, I was shocked to see the defacto 
security paradigm defaulting substantially to network partitioning/
traffic isolation (much like many SCADA (control system protocol) 
deployments).]

#I know, I know. I'm ranting a bit here.

Passion is a good thing, as long as it doesn't give you high blood
pressure/an aneurysm. :-) 

#But I agree with Mike that we ought to clearly describe the problem 
#we are trying to solve.

How about:

"Context:

<insert definition of fastflux hosting here>

"Miscreants are using fastflux hosting to support their criminal 
activities when more conventional hosting is unavailable or 
undesirable.

"Fastflux hosting is based on the systematic abuse and surreptitious
exploitation of 3rd party systems and network resources without the 
informed consent of the owner of those resources.

"The software that enables fastflux hosting is surreptitiously 
installed on consumer systems because if users or their ISPs were
aware of what was being done to them, and through the use of their 
PCs, they would do their best to stop it.

"In most cases, however, only the domain name registrar or 
registration service provider can cause a fastflux domain to be 
taken down.

"Questions:

"What, if anything, can ICANN or the operational community do
in response to this phenomena? *Should* ICANN take on this 
issue, or should ICANN and the registrar community do nothing
in response to the fastflux problem, leaving any response to
national regulators or local/national/international law 
enforcement agencies?

"Can effective technical steps be taken to prevent criminal 
exploitation of fastflux approaches while not foreclosing 
operationally important and non-criminal uses of short TTLs
and other adaptive/less-traditional DNS-based techniques?"

Regards,

Joe

Disclaimer: all opinions strictly my own