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

[Edward Lewis <Ed.Lewis () neustar biz>]

At 15:47 +0000 8/10/06, bmanning () vacation karoshi com 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.