I use a virtual machine to isolate applications like email clients so its generating traffic inside the vm, the host machine uses pihole dns, the traffic of the vm can be detected in the Query Log of the pihole web interface with domains like:
both having PTR requests meaning the virtual machine asks for the name of the client IP.
192.168.122.1 is the default route and the DNS of the vm
192.168.1.254 is the default route of my modem/router
im using QEMU/KVM in a linux machine, the default network config is set to NAT, it cannot see other devices in the home network, the strange thing is that i can still send and receive emails, can retrieve websites when i search in the vm browser, but the ad blocking functionality fails, ads for youtube videos still show for example.
how the vm retrieve a website when the reply is NXDOMAIN?
the reason behind searching websites and still seeing ads inside vm is because its able to communicate with the router/modem but the pihole DNS not be able to intercept the package before delivery?
when i change the DNS of the vm to the pihole DNS, cant connect to any website due to the fact that the vm can't see other devices in home network being one of this devices the pihole dns (raspberrypi)
If your VMs are NATd to the Linux host, the VMs' traffic will be originating from the Linux host, as far as any other computers on the host network are concerned.
Therefore Pi-hole will see your VMs' query traffic as just more queries from the Linux host. The Linux host will take care of separating traffic intended for itself and traffic intended for the private NAT networks that it is hosting.
YouTube adverts are a bad metric because Pi-hole can't block those even when it's working correctly. Try running the commands below on both the Linux host and on the VM in question:
nslookup flurry.com
This will check if flurry.com is blocked, a domain which is blocked on the default blocklist installed. You should see this query in your Query Log in both cases
nslookup pi.hole
This will check that Pi-hole is the resolver in use. Pi-hole will recognise this domain, whereas another DNS server won't.
If things are working correctly you would expect to see the response of 0.0.0.0 for the first command, and the Pi-hole's IP for the second command, on both the Linux host and the VM. If the VM is using its own external DNS servers, or if the Linux host is in fact not properly using Pi-hole, you may see different results.
The QEMU or KVM config that gives the NATd VM its networking should be setting a DNS server which it manages, and then the Linux host will send that onwards to Pi-hole like any normal DNS traffic from that host. The commands above should shed some light.
nslookup flurry.com inside the VM shows address 0.0.0.0 in terminal nslookup pi.hole shows my pihole address correctly in the terminal of vm
. in the query log, flurry.com shows as blocked and displaying the domain address correctly
pi.hole appears as multiple queries in chronological order:
254.1.168.192.in-addr.arpa Reply: NXDOMAIN twice
1.122.168.192.in-addr.arpa Reply: NXDOMAIN twice
as i see it, the vm is using pihole dns, but as you said the kvm default config of NATd sets its own DNS server, also because its a close environment not being able to see other devices makes the domain in the queries appear as in-addr.arpa with nxdomain replies when in reality they arrive to the host and redirected to the vm.
is this assumption right?
This suggests that your VM's DNS requests ultimately do reach Pi-hole.
If Pi-hole answers NXDOMAIN, then this means that Pi-hole does not know a name to that IP.
If you want to associate a name with those IPs, you could consider to do so via Local DNS Records.
Alternatively, if you think that another DNS resolver in your network already has that knowledge, consider to enable Pi-hole's Conditional Forwarding via Settings | DNS and point your Pi-hole to the respective IP address in the know.
You may want to verify that a resolver at that IP actually can supply the expected answers by running a lookup against that IP address, e.g.
nslookup 192.168.122.1 192.168.1.254
will ask your router at 192.168.1.254 if it knows a name for 192.168.122.1.
