[RPZ] RPZ seen at MAAWG

[Jonathan Curtis]

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