Bind with RPZ acts weirdly if a subdomain is used aside a wildcard

Question

Bind with RPZ acts weirdly if a subdomain is used aside a wildcard

I’m unsure if I found a bug in bind. I’ve setup a simple dns server on debian 12.

in named.conf.options

zone "rpz-test" {
    type master;
    file "/etc/bind/rpz-test.zone";
    check-names ignore;
}

in rpz-test.zone

;RPZ
$TTL 604800
@   IN SOA rpz.zone. rpz.zone. (
                2; serial
            604800; refresh
            86400; retry
            2419200; expire
            604800; minimum
)
        IN      NS      localhost.

*.com A 127.0.0.1

sub.domain.com A 127.0.0.1

Now… If I use dig to check the configuration once bind9 is started…

This is what happens:

dig whatever.com @localhost -p 53
-> replies 127.0.0.1

dig sub.domain.com @localhost -p 53
-> replies 127.0.0.1

dig domain.com @localhost -p 53
-> breaks the wildcard and is resolved

Practically if there’s a subdomain of a domain declared, the main is resolved externally!
Very weird, wasn’t the wildcard able to overcome the subsequent declarations?

Probably the problem is in my configuration, not sure if is a bug however the versions I’m using are:

debian 12.2
bind 9.18.19~deb12u1

Asked By: user3450548

||

Source

Answer 1

According to RFC 1034, this is the expected behaviour:

Wildcard RRs do not apply
When the query name or a name between the wildcard domain
and the query name is known to exist. For example, if a
wildcard RR has an owner name of "*.X", and the zone also
contains RRs attached to B.X, the wildcards would apply to
queries for name Z.X (presuming there is no explicit
information for Z.X), but not to B.X, A.B.X, or X.

If you find this unclear, you are not alone, to the extent that they wrote RFC 4592 to clarify the usage of wildcards. To sum it up: as soon as you add an RR entry for sub.domain.com., you are defining two domains sub.domain.com. and domain.com. to which your wildcard *.com. does not apply.

Answered By: xhienne