North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: rDNS naming conventions (was: Re: SORBS Contact)

  • From: Edward Lewis
  • Date: Thu Aug 10 12:26:03 2006

At 15:47 +0000 8/10/06, [email protected] wrote:
On Thu, Aug 10, 2006 at 10:21:45AM -0400, Steven Champeon wrote:
on Thu, Aug 10, 2006 at 01:11:50AM -0700, william(at)elan.net wrote:
> >>On Aug 9, 2006, at 1:06 PM, Matthew Sullivan wrote:
> >>> <http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-naming-schemes-00.txt>
>
> The reason I do not like RDNS naming scheme is because it forces
> one particular policy as part of the name.

 Fair enough. FWIW, I've seen a wide variety of naming schemes (I've
 got a project that collects these as an antispam/anti-botnet measure,
 and so far we've got around 16K conventions documented for 11K domains).


	first...  as a draft, it carries ZERO weight. -IF- it becomes an
	RFC, its targeted status in INFORMATIONAL, e.g no standard of any kind.
	So no one is going to -force- you to implement it.

	hum...  why does this draft remind me of the (in)famous WKS RR?
	what is WKS?  you know, that RR type that specified  the "well known
	services" running on/at the particular lable.

	WKS was depricated, in part due to the fact that "black hats" would
	use WKS to groom thair attack profiles.  Use of the conventions
	outlined in this draft would be very useful in building targeted
	attacks.  To paraphrase Randy Bush, "I encourage all my competition to
	implement these guidelines."

Piling on here ...

The effort is to infer the intent of a packet based on ancillary data. The twin dangers here are inference of intent and exposure of the ancillary data.

The first part is like asking "would I want to have security research done by a company on Glenwood Road or on Shady Lane?" (Ya, know "shady" in security.) Legend has it that one research company moved it's location because of this, or maybe it was a joke that came afterwards.

The second part is what ancillary data is exposed. You can require, you can request, or you can assume you won't get the data you need. Sometimes you won't get it because the giver doesn't want the headache of providing it or because the giver is afraid of the ancillary data going to nefarious uses.

My point is that inferring intent based on incomplete data is faulty, but it seems to be useable in real life. However, once heuristics get encoded in deterministic algorithms, the results generally are not so good - mostly because the encoding of the heuristics fails. The answer is to include things like RFC 3514, (Note the pub date.) or ancillary data. But the solution of adding ancillary data maybe worse than the disease. This is just one of the hard problems.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.