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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

I'm separating comments on TXT overloading from something else you mention 
later that is very important.

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? What is 
a name server must comply with both communities?

As an example of how this is handled in an IETF standard, several protocols 
have "vendor-specific" fields (DHCP, NHRP and X-AUTH come to mind). The vendor 
ID might be the 24 vendor/manufacture bits from an Ethernet MAC, or whatever is 
needed to make absolutely sure that the recipient of the protocol 
message/packet knows exactly how to process the message.

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

This is no longer overloading DNS TXT but structuring TXT in a standard manner. 
I am very OK with this in principle, and would hope that we would take such a 
proposal to the IETF as did the blacklisting folks.

Note that the blacklist folks are effectively created a new identifier, and 
that this list should eventually be maintained by IANA. Note also that if the 
DNSBL BCP is not approved, then the assumed structure disappears and you're 
back to having ambiguity.

On 7/13/08 9:17 PM, "Joe St Sauver" <joe@xxxxxxxxxxxxxxxxxx> wrote:

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