I just managed to install pihole + unbound as containers on my Synology NAS.
Pihole properly blocks ads and sends lookups to unbounb.
In general unbound works in most cases but there are urls which can' be resolved by unbound.
However, when I use other DNSs like those from CloudFlare or Google, they can be resolved.
I first thought that it may needs more time to solve new requests so I set the cache_size for pihole to 0 which indeed solved some issues where new websites took 10-15 seconds to be resolved. But the original problem that some urls can't be resolved at all still remained.
When I had a look at the pihole logs thpse urls always reply with a nodata-ipv4 message.
The urls however are hold by my organization so I also thought about if it could be something related to proxies but from what I can see so far there are no proxy settings on my organization's laptop.
You will want to provide a debug log for the devs to look at. From the Webgui go to tools>generate debug log and post the token at the bottom of the report.
193 appears to be the container on which unbound is running. Your debug log shows that queries are being forwarded to this IP and replies are being recieved. This confirms that the unbound instance is answering queries from Pi-hole.
Nov 8 14:11:06 dnsmasq[10590]: query[A] clients.config.office.net from 192.168.178.40
Nov 8 14:11:06 dnsmasq[10590]: forwarded clients.config.office.net to 192.168.178.193
Nov 8 14:11:06 dnsmasq[10590]: reply clients.config.office.net is <CNAME>
Nov 8 14:11:06 dnsmasq[10590]: reply geo.clients.config.office.akadns.net is <CNAME>
Nov 8 14:11:06 dnsmasq[10590]: reply eudb.clients.config.office.akadns.net is <CNAME>
Nov 8 14:11:06 dnsmasq[10590]: reply eudbipv4.clients.config.office.akadns.net is 52.142.237.134
This isn't a solution to the problem.
Pi-hole works at the domain level, not the URL level. Please elaborate on your problem with additional details that show where a query is failing to resolve.
Your observation does not mean that unbound cannot resolve that domain.
On the contrary, your log results show that unbound is very well resolving airflow-prod.honey-pot-airflow.com, to NODATA-IPv4 and NODATA-IPv6 specifically.
This means that the authoritative DNS servers for airflow-prod.honey-pot-airflow.com do neither hold A nor AAAA records for that domain.
I can confirm, however, that some public resolvers currently do return at least an A record for that domain:
However, that is a private range IP, unreachable via public internet.
Since unbound is querying the authoritative DNS servers directly, I'd consider NODATA-IPv4 to be the -well- authoritative reply here. Returning a private IP would seem wrong in more than one way.
Is there a reason why you want such an A record returned for airflow-prod.honey-pot-airflow.com?
Arguably, private range IPs should not be served by public DNS.
10.76.125.4 is such a private IP.
It may or may not exist in your private network, and it may or may not be routable.
It may or may not run the services you'd associate with the domain name (if there would exist any such expectations to begin with).
Usually, a private IP being returned by a public DNS server would strongly suggest a DNS rebind attack.
Network equipment like routers may even suppress such answers by default, in order to prevent such an attack on your network, and so does unbound.
If despite all of above considerations, you'd still want that domain to resolve, you'd need to exempt it from unbound's DNS rebind protection.
Is that what you would require?
What is the reason you'd require that domain to resolve?
The name suggests it's some kind of honeypot, so you should probably not access it anyway.
If you do, you'd usually get contacted by your IP department, e.g. for having failed to comply with security guidelines that would have prevented you from sticking your finger in that honeypot if followed.
I just know that it runs an airflow instance that I usually work with from home (even before I installed unbound and pihole). That's why I meant that other public DNS servers could resolve it.
However, I don't want to do something insecure for my private network - what "exempt it from unbound 's DNS rebind protection" sounds like to be.
But then I ask myself which alternative do I have?
Your previous answer seemed to imply that your company network would somehow enforce resolution for airflow-prod.honey-pot-airflow.com to an IP.
Your current answer seems less confident.
You should approach your company's IT department and enquire if resolution of airflow-prod.honey-pot-airflow.com to a private IP would be a must or elsewhere required in your airflow process.
If it's not, then you can keep your current unbound configuration, and remain confident that it protects you from DNS rebind attacks.
If it would be required, then I could help you configure a respective exemption in unbound, for just that domain.
Alright, I asked them in the meantime, sorry for the delay.
From their perspective, it's necessary to resolve the domain to a private IP. I understood that the domain comes from an Azure DNS which should resolve airflow-prod.honey-pot-airflow.com to the IP of a load balancer in front of other resources. It hopefully makes sense. I'm not that deep involved in infra topics like these
I added the dir unbound.conf.d to the volume of unbound and inside created the file dns-rebind-exemptions.conf with the mentioned input.
I also checked the default conf + the newly created conf -> no errors.
However, after restarting unbound, the domain still does not resolve.
Did I do something wrong?
Here's the correct one:
