When adding DNS records to pihole, I would expect to resolve the records IP address for its DNS name.
Good exemple
Adding DNS=my-domain.com | IP=1.2.3.4 resolves the correct IP address.
Bad exemple
Adding DNS=sub.my-domain.com | IP=1.2.3.4 resolves my routers public internet IP address.
It seems that i have to enter every single subdomain in pihole separately..?!
Thanks in advance.
Please explain more about your domain's relationship to your private network and what you're trying to achieve and where Pi-hole fits into the picture.
im running a server behind a dyndns (domain=my-domain.com) to provide some services to my self.
If i access some services from the outside/public internet (via my-domain.com) my router forwards the requests to my nginx.
But if I want to access these services from my local network, I want my pihole to redirect requests directly to my local nginx servers IP address.
If I use wget sub.my-domain.com the public IP address will be resolved instead of a local one.
Run from a client on your network (i.e. not from the machine hosting Pi-hole), please share the results of the following commands:
nslookup pi.hole
nslookup my-domain.com
nslookup sub.my-domain.com
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:
pihole -d
or do it through the Web interface:
Tools > Generate Debug Log
Here is the output, but it confuses me...
I was sure I have seen a local(!) IP on the nslookup my-domain.com command 
> nslookup pi.hole
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: pi.hole
Address: 0.0.0.0
> nslookup my-domain.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: my-domain.com
Address: 149.50.43.173
> nslookup sub.my-domain.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
sub.my-domain.com canonical name = my-domain.com.
Name: my-domain.com
Address: 149.50.43.173
FYI: I'm running pihole in a docker container with network_mode=host.
Debug token is https://tricorder.pi-hole.net/aN7cYAIM.
The client you ran that nslookup from is not using Pi-hole for DNS, but a stub resolver on that machine's 127.0.0.53.
That stub resolver in turn seems to use Pi-hole, at least in one of its upstream's resolution chain, but you want to verify that Pi-hole is its sole upstream, lest it would bypass Pi-hole via any alternate DNS servers.
Your dockered Pi-hole returns 0.0.0.0 as its address, which indicates that you haven't yet set FTLCONF_LOCAL_IPV4 for your Pi-hole container, see Recommended Variables.
Your debug log also shows two DHCP active servers:
* Received 349 bytes from ens160:192.168.0.62
Offered IP address: 192.168.0.63
DHCP options:
Message type: DHCPOFFER (2)
router: 192.168.0.1
dns-server: 192.168.0.1
* Received 548 bytes from ens160:192.168.0.1
Offered IP address: 192.168.0.63
DHCP options:
Message type: DHCPOFFER (2)
router: 192.168.0.1
dns-server: 192.168.0.1
Both distribute your router's 192.168.0.1 as DNS server, suggesting that router is configured to use Pi-hole as its upstream. Again, you'd want to verify that Pi-hole is its sole upstream.
Using Pi-hole as your router's upstream is a valid configuration, but note that you would not be able to attribute DNS requests to individual clients in Pi-hole's Query Log, as all requests are coming from your router.
To see individual clients, your router would have to be configured to propagate your Pi-hole host's IPs as local DNS server.
Your debug log also shows that you've enabled Pi-hole's Conditional Forwarding, but for a local domain name that matches neither of the two distinct domains as distributed by your DHCP server.
Unless you match the local domain name with one of those two domains, local FQDNs as known by the forwarding target would fail to resolve.
Also note that since your two DHCP servers distribute two different local/search domains, only one of those names would be able to resolve in your current configuration.
Unless you really require it, you should probably disable the second DHCP server in your network.
As for your issue:
I do not see any local DNS records shadowing my-domain.com or sub.my-domain.com configured in your Pi-hole.
It would thus be expected that respective requests would return public DNS records.
Note that if you'd only shadow my-domain.com in Pi-hole, requests for sub.my-domain.com would be forwarded to and answered by a public DNS server.
Thank you very much!
I've done another nslookup from the same machine and got IPv6 addresses!?
Don't know why?
marco@secretary:~$ nslookup my-domain.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: my-domain.com
Address: 192.168.0.63
Name: my-domain.com
Address: 2a00:4841:17:12af:de39:6fff:feac:4b80
Ok, will apply the FTLCONF_LOCAL_IPV4 variable.
I was not aware about having the routers DHCP server active 
I will disable the 2nd one.
The ens160:192.168.0.62 machine is my DHCP server and should propagate the pihole to my clients.
This would indicate that you have supplied a local A record for my-domain.com, but no AAAA.
It doesn't - according to your debug log, it distributes your router's 192.168.0.1.
And since you intend to use your .62 as your sole DHCP server:
I noticed that it handed out a rather short 10 minutes lease time, which would have the client starting to renew its lease every 5 minutes.
AAAA record:
I don't want to use IPv6 in my local network. I thought if no local client got IPv6 addresses, I don't need to care about AAAA records
DHCP:
Your right, I've fixed that. Pihole is really nice for debugging my network config! 
If you only shadow the public A record, then clients would be expected to receive the public DNS records as publically available, including AAAA ones.
Your my-domain.com is a public domain, and quite obviously, its authoritative DNS server has AAAA records for it.
If you cannot or do not want to provide local IPv6 addresses, you may want to regex block AAAA replies for that domain, see Pi-hole extensions - Pi-hole documentation.
Okay, I blocked now the AAAA replies.
Thank you, again! This realy saved my config 
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.