[RPZ] RPZ / bind load bug?

[Vernon Schryver]

> From: Francis Turner <francis at threatstop.com>

> Content-Transfer-Encoding: quoted-printable

> paypal.com.uk.cmd.cgi-bin.4c6da88992553d0d43ff7d8dbe19c1133279c9a98f445fff9=
> e2de3dd9a35cd.535125ee83828ec61a1888291c588fd9dc096297a1e972d037a14b1566349=
> 8.806a02ea02f2846dd2aee0300a20dfe587e5ed4f8d3fdc281cb36a171f0178.umedial.de

> May 27 01:04:14 rpz named[29830]: general: error: dns_master_load: /srv/www=
> /bind/rpz/includes/desktop.rpz.threatstop.local.include.txt:4787: ran out o=
> f space
>
> The actual FQDN including the RPZ header is 253 bytes long (it's the above =
> plus desktop.rpz.threatstop.local) and so far as I can tell this is an enti=
> rely legit FQDN (less that 255 total, max 63 chars per section). Moreover t=
> he error 'out of space' isn't one that implies an illegal name.
>
> We're running Bind version: 9.8.4-P1 (version.bind/txt/ch disabled)
> compiled with the following options:

In other cases, the output of `named -v` could be important, because
it contains the entire version number including the version of the
RPZ patch, if any.

In this case I think there is no RPZ load bug and that the problem is
that name is too long when the root is included.  When I try to a
simple (not mentioned in a response-policy statement) "local" text
zone file containing $TTL, an SOA, and this line:

paypal.com.uk.cmd.cgi-bin.4c6da88992553d0d43ff7d8dbe19c1133279c9a98f445fff9e2de3dd9a35cd.535125ee83828ec61a1888291c588fd9dc096297a1e972d037a14b15663498.806a02ea02f2846dd2aee0300a20dfe587e5ed4f8d3fdc281cb36a171f0178.umedial.de.desktop.rpz.threatstop.local. A 6.6.6.0

dns_name_fromtext() in lib/dns/name.c fails near line 1260:

        if (!done) {
                if (nrem == 0)
                        return (ISC_R_NOSPACE);

dns_name_fromtext() does what its name suggests, converts from a text
representation of a domain name.  It works if I remove the last "8".


I would have guessed that 
    806a02ea02f2846dd2aee0300a20dfe587e5ed4f8d3fdc281cb36a171f0178.umedial.de
and all its subdomains are evil and so I would have expected two, shorter
response-policy triggers,
    806a02ea02f2846dd2aee0300a20dfe587e5ed4f8d3fdc281cb36a171f0178.umedial.de
    *.806a02ea02f2846dd2aee0300a20dfe587e5ed4f8d3fdc281cb36a171f0178.umedial.de


Vernon Schryver    vjs at rhyolite.com