[RPZ] RPZ seen at MAAWG

Wed Oct 6 15:25:06 UTC 2010

Not sure what the short cut key is to send a message on gmail, but i
just did it.

4. If there could be some sort of reference that there are 3rd party
appeals processes that would help. For example, Stopbadware.org, just
cause that's who we use, but more importantly, they have a reasonable
process for dealing with false positives.

5. The examples of how ISP's should start using this technology is in
blocking command and control networks from infected machines where
there is no human involvement. Keep the focus of what the intention is
narrow intentionally so that you avoid the rat holes.  The key should
always be "preventing un-intentional harm to the end subscriber" and
avoiding at all costs blocking intentional traffic.   The minute
anyone starts talking about blocking anything remotely tied to the
recording industry or others - the ISP's will walk away (if not run
away).

6. Avoiding false positives is secret sauce that people deploying this
type of technology will always cause commercial unrest. We're doing a
lot in this space that I can and can not talk about. Simple things
like looking at the reputation of the name servers, history of the
domain, collateral domains associated to a malicious domain, whois
data, resolution IP, source IP requesting the domain (it's reputation)
... those are simple and have been solved for a while, generally will
hit over 50% of the domains needed to be blocked. The things I can't
talk about solve a lot more.

Hope that helps,

Jonathan

On Wed, Oct 6, 2010 at 11:12 AM, Jonathan Curtis <jcurtis11 at gmail.com> wrote:
> It was a great talk. (i just joined this list)
>
> To get the points across, I think more needs to be articulated on why
> it is important to protect subscribers.
>
> 1. The traditional voice on AV being dead, doesn't need to be beaten
> to death (no pun intended).
>
> 2. Something that graphically demonstrates how a domain is added (not
> command line) how it gets to a caching servers.
>
> 3. Sources of malicious domains should be listed (non-commercial ones that is)
>
>
> On Wed, Oct 6, 2010 at 10:54 AM, Eric Ziegast <ziegast at isc.org> wrote:
>> I gave a pretty good presentation at MAAWG for RPZ.  Jonathan thanked
>> me.  Ferg gave me a great intro.  A few people thought it was a really
>> good talk - even someone who thought he knew everything about RPZ
>> already told me that could not look down at his laptop when I talked.
>>  Unlike the DNSSEC talk, I was the expert here.  Here are a few things
>> that need to be addressed:
>>
>> #### Directing removals
>>
>>  $ dig www.SOMEDOMAIN.BAD a @nsa.vix.com
>>  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13342
>>  ;; QUESTION SECTION:
>>  ;www.SOMEDOMAIN.BAD.                  IN      A
>>
>>  ;; AUTHORITY SECTION:
>>  rpz.surbl.org. 180 IN SOA dev.null. zone.surbl.org. (
>>                                 1286371502 180 180 604800 180)
>>
>> Ok, so www.mecom.ae is in the SURBL RPZ.  If I were mecom.ae, how
>> would I get off?  Where do I go?  Knowing a DNS RFC about SOA racords,
>> you might email <zone at surbl.org>.  Should we create some other
>> standard? like have a TXT record at the base of the zone that people
>> can use to figure out where to go (website, phone number, etc.)?
>>
>> Best practices for DNSBL are being written in IETF's ASRG.  We should
>> probably have someone attend/present at the next IETF and make sure
>> they consider RPZ as part of their healthy breakfast.
>>
>>
>> #### ISC does not publish any RPZ or give perception of publishing
>>
>>  2.2. The remainder of the zone is expressions of DNS policy.
>>   The owner name of a Response Policy Zone resource record set
>>   (RRset) is the relativised name of the domain name about which
>>   policy is being expressed.  For example, in a policy zone called
>>   RPZ.ISC.ORG, an RRset at WWW.VIX.COM.RPZ.SIE.ISC.ORG would affect
>>   responses to lookups of WWW.VIX.COM.  DNS RPZ RRset owner names
>>   can be wildcarded according to normal rules, for example
>>   *.VIX.COM.RPZ.ISC.ORG would affect responses for any subdomain of
>>   VIX.COM.  This means that in order to affect both a domain and
>>   its subdomains, policy must be entered for both that domain and
>>   its wildcard subdomain.
>>
>> Let's find something else beside ISC.ORG.  With Jeff's blassing, maybe
>> we can use SURBL here or some other willing participant (eg: just
>> RPZ.VIX.COM or some other straw-man domain).
>>
>> #### SuperWildcard
>>
>> The limitation of wildcard records could be an issue.  I one lists:
>>   mecom.ae.@ IN A .
>>   *.mecom.ae.@ IN A .
>>
>> How does one take care of www.qatar.mecom.ae without specifically
>> listing *.qatar.mecom.ae in the zone?  Do we need a Super Wildcard
>> capability in zone file specifications that matches all sub-domains?
>> not just the current level?
>>
>> #### A website
>>
>> Directing people to the Vixie Blog just isn't scalable.  Perhaps I
>> should setup a sub-site off http://www.isc.org/solutions and include
>> presentation material?
>>
>> #### Who's implementing?
>>
>> I told someone that I will be speaking again at ISOI 8, and that I
>> will have a list of RPZs that advertise themselves on this mailing
>> list, and that I will have an update on software that supports RPZ or
>> has plans to support RPZ.  It would be great if everyone was willing
>> to implement RPZ technology into their products.  Once someone sees
>> the BIND source diffs and understand the specs, I expect that they'll
>> realize it's not hard.  Commercial DNS software might already have a
>> similar capability, and as long as they can import an RPZ zone and
>> make their product work similarly, they're part of the ecosystem.  If
>> some vendors choose not to participate, their lack of presence will be
>> "interesting" to those that provide RPZ-enabled services.
>>
>> If you plan on creating an RPZ, let the list know.  SURBL has a beta
>> for people to test.  We'd like to see more.
>>
>> If you plan to implement RPZ in your software (DNS recursive server or
>> integrate a product with a nearby recursive server), let the list know.
>>
>>
>> #### What's the timeline for the RDATA IP4/IP6/NS improvements?
>>
>> I presented an improved version of the WIDE slides.  It's good stuff.
>>  I'd like to see it implemented.  What's the time line?
>>
>> Is RPZ getting into BIND 9.7.3? and if so, is it the first RHSBL
>> technology? or the full RDATA functionality?
>>
>>
>>
>> --
>> Eric Ziegast
>> _______________________________________________
>> dnsrpz-interest mailing list
>> dnsrpz-interest at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dnsrpz-interest
>>
>
>
>
> --
> Jonathan Curtis
>

-- 
Jonathan Curtis