It takes very long for local subdomains to get resolved for the first time.
When I try to resolve a subdomain from my local dns server (next to pi-hole) for the first time it keeps failing. I am getting NXDOMAIN results for a very long time (like hours).
# testing local dns-server (bind)
$ dig @192.168.1.153 test-new.testdomain.local-net
... status: NOERROR ...
test-new.testdomain.local-net. 604800 IN A 192.168.1.76
...
# testing pi-hole:
$ dig @192.168.1.53 test-new.testdomain.local-net
... status: NXDOMAIN ...
Then all of a sudden it works and keeps working.
Details about my system:
I need wildcard subdomains because I constantly need temporary local domains to test some development state of some project. Since pi-hole sadly doesn't support those, I have a bind service running on another machine.
In pi-hole settings > DNS, I have selected OpenDNS (ECS, DNSSEC) from the list of suggested Upstream DNS Servers and entered my local dns server and it's backup at Custom 1 and 2. I haven't selected or configured any IPV6 dns servers.
What I have changed since installing Pi-hole:
It actually has been working until yesterday. But then my SD card broke, when I was running a software update. I couldn't recover any data and installed everything fresh today. I have no idea, what might have been different before. I didn't make any changes other than the dns settings today.
It's not quite clear to me what you try to achieve.
Could you give an example of how you intend your local domains to resolve?
Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Generally: I want pi-hole as my main dns server that resolves any remote request and I want my additional dns server to resolve names of local servers. Also I don't want that additional dns server to be bothered with caching anything else than the data of local servers.
edit:
So, not the most efficient but the most easy solution (that has been working fine for the last years) was, that pi-hole just asks the other dns server first. Then, almost every time, the other server would say: "I don't know that domain" and then pi-hole would ask it's remote dns servers.
Of course it would be a far better solution if pi-hole would acknowledge the other dns as the primary name server of my local domain and didn't even ask for anything else. But I didn't see a way to configure it that way and I needed a working solution and since it was working fine, I had no reason to complain.
Ah, that's not what I was after - I was trying to get a better understanding of:
That's what I asked some examples for, to check whether I would probably know of a way to coerce pihole-FTL/dnsmasq to meet your requirements, without having to maintain an additional DNS server.
As for your current resolution chain:
Your debug log shows that you have configured your Pi-hole to use a set of three upstreams: two public ones and your local bind.
Pi-hole may thus use any of those upstreams for any given request, preferring the fastest responding one for a certain time (EDIT: see also DNS resolver - Pi-hole documentation).
Mixing several upstreams here is generally not desirable, and can produce unexpected and unwanted results, particularly when mixing local and public DNS servers.
Your observation matches that configuration:
Depending on the upstream that Pi-hole has forwarded a given DNS request to, a DNS request for a local name will trigger either an NXDOMAIN from the publics or a local reply from your bind instance (and potentially vice versa for public domains, depending on what bind is doing with those).
You have two choices to reliably process local requests through your bind server:
a) Have Pi-hole use bind as its only upstream, and have bind forward all queries it cannot answer to public upstreams.
b) Remove bind from Pi-hole's Upstream DNS servers and instead point Pi-hole's Conditional forwarding to your local bind.
If you'd explain your local domain wildcard needs, I could see whether I can come up with a custom config covering those, potentially allowing you to ditch bind altogether.
Thank you very much for taking the time to analyse my logs and to write that detailed reply! I can now understand what the problem is.
I would be VERY interested in a solution where I don't have to maintain an additional DNS server.
Give me a minute to figure out what's really important to me. Some things are just workarounds I have accepted and became used to, but are not actually what I wanted in the first place.
I have several local test servers. They provide different setups, different operating systems and different architectures.
Each of the test servers has a number of projects on it, which should be accessible via subdomains. The subdomains never point to a different address than their domain. I quite often have to add new projects to any of those test servers and I mostly keep old projects on them. The number of domains (test-servers) in my network is increasing very slowly, but the number of subdomains (projects) is increasing so fast that I'd like to avoid effort for setting them up.
Do I need the local top level domain (.local-net)?
Only because the local tld is convenient for testing ssl connections without having the clients complain. I have created a root certificate and added it to my test clients. Whenever I add a new machine, I just need my CA to sign a new wildcard cert for it and I don't have to do any configuration on the test clients. The CA could issue certs for any domain name (not just that tld), but the wildcard-certs I am using are only allowed at subdomain level (cert for *.physical1 wouldn't work but *.physical1.local-net does).
I hope that explains what I am looking for. Please don't hesitate to ask if anything is unclear.
edit: changed label "Example" to "Current DNS configuration"
I've removed the local dns-server from pi-hole configuration. I stopped the bind9 (to be absolutely sure). Everything (even new subdomains I am making up) is resolved at once.
What bothers me a bit is that the title of this thread doesn't match it's content anymore - perhaps it never did. This very good solution might be hard to find for someone with the same problem.
