CNAME in local-data: is not resolved #976
Comments
|
Hi @vzuevsky, as per the documentation CNAME is not supported in local zones (https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-local-zone). If you would like to serve your own content with CNAME support you could use one of stub, forward or auth zone configuration options. The auth zone documentation specifically mentions the CNAME case (https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#authority-zone-options). |
@gthess, can you (or anyone else) go into more detail (or link to an example perhaps), as to how one would set that up? I am struggling with defining the right auth-zone files, and googling does not bring up anything useful (anymore). Say I want My understanding is that I would need to have these two records somewhere: Would I need a zonefile for Currently I have this setup:
With it, I still only get the CNAME (instead of CNAME and A records) in the reply for I have also tried various combinations of Any help is greatly appreciated! |
|
I am guessing you could be missing: in the configuration file. To tell the validator that these domains should be treated as insecure now that you are modifying their contents. |
|
Thanks for the quick reply, really appreciate it! 😄 I have added the two options (with values surrounded by quotes) like so: and also added The only change I saw (which I also saw yesterday) is, that with instead of the CNAME like so: I have also tried moving the auth-zone options to within server, with similar results. Does it matter where they are defined? If so, where is the "right" place for them? |
|
It does matter where they are defined because the config file can only be parsed one way. What happens when you say it doesn't work? What is Unbound logging for such a query (you can bump up |
|
Looking at your config, I decided to comment out my forward-zone, which looks (or looked) like this With it disabled, i get the intended result (see following). I didn't mention the forward-zone, since I thought it was unrelated -- Sorry for that.
I do. I'm using this docker image and am doing a up/down each time i change the config.
(Just to avoid confusion: Now talking about previous results with above mentioned forward zone enabled)
(Again, talking about with forward-zone enabled) and for subsequent queries it shows Note that I have other options defined (e.g. I'm using the respip module together with this blocklist in RPZ format have enabled DoT/DoH and have certain harden options enabled). However, I think the culprit is the forward-zone, as "CNAME resolution" works with it disabled. Let me know if you need the whole config though. So the new question I have is: How can I combine "CNAME resolution" with the forward-zone? Basically what I want to achieve is this:
|
|
I see that this currently does not work if you define a less specific forwarder (in this case '.'). |
|
@GamerBene19, #1221 should solve your current problem (configured auths and forwards). Would you be able to build and test from that branch or would you wait for a released version? |
Thanks for the quick fix!
I'm currently using this docker image, but I'll try to modify it's Dockerfile to build your branch. If that doesn't succeed I'll simply wait for the release to test it. |
|
Building the image was successful and I can confirm that CNAMEs now get resolved as expected. Thanks again for the quick fix! So for my use case
is fulfilled, but unfortunately it looks like
does not work. If I query |
|
I commented too soon...
and I'm not quite sure what "the internet" means in this case. Can you confirm my suspicion? If it is recursive: Is there a way to have it use the defined forward-zone instead? Thanks again for the help so far, I really appreciate it! |
|
If something does not exist in your local I suppose you are getting a DNSSEC failure probably, you can check the logs if you raise verbosity to 3 or higher. Is And btw, if you have configured an auth-zone, Unbound is authoritative for that zone with the contents provided. |
I thought so too and was confused about that. However, with fallback disabled, I get SERVFAIL for domains that do not exist in my local
I have defined dns-insecure for the relevant domains (foo.de and .bar) and the logs (see below) don't point towards DNSSEC (as far as I can tell)
It's a placeholder for my actual domain (which is currently registered to use Cloudflare DNS). However I also test with the digging where the log (with verbosity 3) show: but digging for and the logs show |
|
Which Unbound version is that? You can check with |
Still the version compiled from your branch. It shows Version 1.22.1 |
|
Maybe you are missing the SOA record for the zone? |
I did indeed not have one. After a bit of googling how it has to look, I now have one and get NXDOMAIN for domains that are not in my zonefile. Which, as far as my understanding goes, is what an authoritative server should answer. However, as outlined above, ideally I'd like unbound to (try to) resolve domains that are not defined in locally within it's zonefile. I suspect the "else case" is not something that If you prefer, we can also close this issue and open a new one for the "else case", since I think the actual issue here is solved. Again, thanks for all the help so far, really appreciate it! |
|
The auth zone cannot do what you describe, it is supposed to be the actual zone contents. Another approach would be to try and (ab)use RPZ for your filtering needs. The caveat is that you cannot use the RPZ problematic types as zone data (https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#autoid-9). Then you can configure it in Unbound like: Let me know if that solves your situation. |
Describe the bug
To reproduce
Steps to reproduce the behavior:
Expected behavior
A record corresponding to vv.my.net.
System:
Debian 4.19
Version 1.9.0
linked libs: libevent 2.1.8-stable (it uses epoll), OpenSSL 1.1.1n 15 Mar 2022
linked modules: dns64 python subnetcache respip validator iterator
The text was updated successfully, but these errors were encountered: