1

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

8
  • 1
    Are you sure you've not missed a trailing dot off those definitions? Otherwise *.com should actually be *.com.rpz-test, etc. Commented Nov 1, 2023 at 22:08
  • Oh. And if you're using rpz-test as your domain, please don't show examples with domain.com; they don't match and we can't tell what your actual tests are Commented Nov 1, 2023 at 22:09
  • Furthermore, domain.com and whatever.com are real registered domains. Please do not use them for examples unless you really are using them in your tests Commented Nov 1, 2023 at 22:11
  • 1
    @ChrisDavies not sure what you mean about trailing dot, I'm using this as a sort of dns firewall. The real file is full of entries of various domains to block but I discovered that if a wildcard is on and for some reason there's a definition of a subdomain of third level the second level became available and not blocked anymore. I don't want to post the real domains, but could have used google or apple as examples if this suits better. Not sure what kind of domains can be posted as example nowadays they are all registered! Commented Nov 1, 2023 at 22:43
  • 1
    @ChrisDavies I tested that configuration, and it produces that result I was talking above. I just simplified the files to the bare minimum in order to reproduce the problem. Commented Nov 1, 2023 at 22:47

1 Answer 1

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.

3
  • I see, thank you very much. So there's a special syntax that I can use to make the wildcard go over the specified domains below or the last scenario is remove all the specific domains below when a .com extension is found via an additional script ? Commented Nov 2, 2023 at 8:51
  • I'm not sure to understand your question. If you want to make your dig domain.com work, you have to explicitely add an A RR entry for that domain. And you probably want to add a wildcard A entry for *.domain.com and *.sub.domain.com Commented Nov 2, 2023 at 11:59
  • I was asking if there's an alternate syntax for making the configuration not work as RFC 4592 but the way I want, but I guess that weren't so I wrote a script to check for wildcards, and if there were some rewrite the rpz file without any domain ending with that wildcard. Commented Nov 2, 2023 at 19:08

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.