[RPZ] problems in the RPZ specification (was: Re: RPZ seen at MAAWG)

[Robert Edmonds]

Jeff Chan wrote:
> > #### 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?
> 
> Um, I was hoping *  *was* the superwildcard.  As Marc hints, I
> think it's definitely needed.
> 
> Actually a super wildcard that included the parent domain would
> be extremely handy.  If it existed, then the example above could
> be collapsed to:
> 
> *.mecom.ae.@ IN A .
> 
> which would halve the size of the zone file.  Vix indirectly
> commented on this privately.

the one issue (well, the one issue from which all my other issues stem
from) i have with the RPZ specification is the re-use of the DNS master
file format for RPZ's DNS filtering functionality.  the master file
format is not particularly well suited for implementing a DNS filtering
language.  a custom DNS filtering language should have been designed,
which shouldn't be too onerous if a DNS implementation independent
reference C-language implementation were written, given that besides
BIND (and perhaps microsoft DNS?) i can't think of a recursive DNS
server with a built-in zone transfer mechanism.

not having read the RPZ patch for BIND9, i'm unsure if RPZ re-uses both
the syntax and the semantics of the master file format, or if it re-uses
only the syntax.  some semantics have been weakened.  for example, the
apex NS RRset for an RPZ zone isn't used, but a dummy NS record is added
to satisfy the need for a zone to have an apex NS RRset.  the RPZ spec
doesn't mention if zone cuts (i.e., child domain names of type NS) are
also forbidden; i would assume so.  it's not clear to me if other
semantics have also been weakened.

the RPZ spec says:

   [...] 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.

and also

   4.1. Any existing data feed capable of producing an RHSBL can be
   trivially used to generate a DNS RPZ.  If the desired policy is to alias
   all e-crime domains to a local walled garden, then for each domain name,
   generate the following records, one for the name itself, and perhaps
   also one for its subdomains:

      bad_domain     CNAME     walled-garden.isp.net.
      *.bad_domain   CNAME     walled-garden.isp.net.

the text says both that wildcards are processed "according to the normal
rules", but it also claims that "*.bad_domain" matches any subdomains of
"bad_domain", which is a contradiction.  RFC 4592, "The Role of
Wildcards in the Domain Name System", states:

   The following responses would not be synthesized from any of the
   wildcards in the zone:

      [...]

      QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
           because *.example. exists

   The final example highlights one common misconception about
   wildcards.  A wildcard "blocks itself" in the sense that a wildcard
   does not match its own subdomains.  That is, "*.example."  does not
   match all names in the "example." zone; it fails to match the names
   below "*.example.". To cover names under "*.example.", another
   wildcard domain name is needed--"*.*.example."--which covers all but
   its own subdomains.

i.e., "reallybad.*.bad_domain" could evade the RPZ rules, depending on
how an implementer reads the RPZ specification.  and if you create a
"*.*.bad_domain" RPZ rule, then "extrabad.*.*.bad_domain" would evade
that one.

here's another example: unless you use "." for the name of the RPZ
policy zone, you cannot block all possible names.  the DNS has a
hard-coded 255 octet limit for domain names, which means that you can't
take a domain name like:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc.dddddddddddddddddddddddddddddddddddddddddddddddddddddddd.example.

and put it into an RPZ zone named "rpz.example.com", because that would
make the combined name:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc.dddddddddddddddddddddddddddddddddddddddddddddddddddddddd.example.rpz.example.com.

longer than 255 octets.  i admit this is difficult in practice to take
advantage of, since you could just block '*.example.rpz.example.com',
but i wonder about combinations of the wildcard problem and the owner
name length problem.

there are other problems that stem from the impedance mismatch of
attempting to build a DNS filtering language within the constraints of a
DNS zone, but this email is already too long.

-- 
Robert Edmonds
edmonds at isc.org