DNS Problem when Pi-hole is primary DNS in company environment

Hello,

we want to use our two Pi-holes as primary and secondary DNS Server in our company environment redirecting to the Windows DNS server for internal DNS queries.
Currently we're using the Windows DNS server as primary and secondary target forwarding to the Pi-holes. This configuration prevents us from receiving detailed information about the origin of DNS queries, unfortunately only the Windows DNS servers are resolved as the requesting device.

When using the two Pi-holes for internal DNS, we're expirieng the problem that switching between LAN and WLAN and vise versa is causing problems in resolving DNS requests for at least 15 minutes or until you restart the DNS resolver.
DNSMASQ is configured in /etc/dnsmasq.d/02-.conf

DNSMASQ:
rev-server=192.168.0.0/16,DC1-IP
rev-server=192.168.0.0/16,DC2-IP
rev-server=192.168.0.0/16,DC3-IP
server=/mydomain.dom/DC1-IP
server=/mydomain.dom/DC2-IP
server=/mydomain.dom/DC3-IP

Our Primary Pi-hole is processing nearly 800k queries per day and both run on virtual machines with 2 Cores and 2GB RAM.

Has anyone expirience with Pi-hole as primary DNS and fast resolving of internal ressources?

I wonder whether that's the configuration you are running?

Due to the trailing comma, your custom configuration file is invalid and wouldn't allow Pi-hole to start at all.
Also, there's no need to write each stanza 3 times, so your configuration could be shortened to:

rev-server=192.168.0.0/16
server=/mydomain.dom/

As Pi-hole is on the receiving end here and would either reply or not reply to requests, it is likely that the cause for that observation lies in your network/routing configuration.

Sorrry, there was a cut in the editing process, after the comma the DC IPs are set in our config:

rev-server=192.168.0.0/16,DC1-IP
rev-server=192.168.0.0/16,DC2-IP
rev-server=192.168.0.0/16,DC3-IP

Is it necessary to point to each DC within the configuration?
I'm not that familiar with Pi-hole, it's a project our CTO has implemented and managed over the last two years. In house documentation is not that good, I can't realy tell what else is changed.

The Pi-holes and Windows DNS server are part of the same IP Range, after switching to the Windows DNS the Name resolution Problem is gone, we therefore assume that the problem lies with the pi-holes.

Please let me know what information I can provide you with to better understand our configuration.

Now that your updated post has revealed that you try to forward to three distinctive DCs:

Commonly, no.

You'd configure a conditional forward to a specific DNS server because that DNS server would hold local definitions only itself is aware of.

If your DCs all have the same knowledge (which your current config suggests), it would be enough to point Pi-hole to one of them.

As you are forwarding the exact same range and name to each of your three DCs, is each of them capable of supplying the exact same DNS replies?

If not, you should adjust IP ranges and domains to match the DCs actual responsibilities, in which case each DNS server would be required, as long as it holds solitary local definitions exclusively.

FYI, for the forward lookup directive server= (name to IP):

$ man dnsmasq
[..]
       -S,            --local,            --server=[/[<domain>]/[do‐
       main/]][<ipaddr>[#<port>]][@<interface>][@<source-
       ip>[#<port>]]
              Specify  IP address of upstream servers directly. Set‐
              ting this flag does not suppress reading  of  /etc/re‐
              solv.conf,  use --no-resolv to do that. If one or more
              optional domains are given, that server is  used  only
              for  those domains and they are queried only using the
              specified server. This is intended for  private  name‐
              servers:  if  you  have  a  nameserver on your network
              which  deals  with  names  of  the   form   xxx.inter‐
              nal.thekelleys.org.uk  at 192.168.1.1 then giving  the
              flag  --server=/internal.thekelleys.org.uk/192.168.1.1
              will  send  all  queries for internal machines to that
              nameserver, everything else will go to the servers  in
              /etc/resolv.conf.  DNSSEC validation is turned off for
              such private nameservers, UNLESS a  --trust-anchor  is
              specified  for the domain in question. An empty domain
              specification, // has the special meaning of "unquali‐
              fied  names only" ie names without any dots in them. A
              non-standard port may be specified as part of  the  IP
              address  using  a # character.  More than one --server
              flag is allowed, with repeated domain or ipaddr  parts
              as required.

              More  specific  domains take precedence over less spe‐
              cific   domains,   so:    --server=/google.com/1.2.3.4
              --server=/www.google.com/2.3.4.5 will send queries for
              *.google.com to 1.2.3.4, except *www.google.com, which
              will go to 2.3.4.5

              The  special  server address '#' means, "use the stan‐
              dard   servers",    so    --server=/google.com/1.2.3.4
              --server=/www.google.com/#   will   send  queries  for
              *.google.com to 1.2.3.4, except *www.google.com  which
              will be forwarded as usual.

              Also  permitted  is a -S flag which gives a domain but
              no IP address; this tells dnsmasq that a domain is lo‐
              cal  and it may answer queries from /etc/hosts or DHCP
              but should never forward queries on that domain to any
              upstream  servers.   --local is a synonym for --server
              to make configuration files clearer in this case.

              IPv6 addresses may include an %interface scope-id,  eg
              fe80::202:a412:4512:7bbf%eth0.

              The  optional  string after the @ character tells dns‐
              masq how to set the source  of  the  queries  to  this
              nameserver.  It can either be an ip-address, an inter‐
              face name or both. The ip-address should belong to the
              machine  on  which  dnsmasq is running, otherwise this
              server line will be logged and then ignored. If an in‐
              terface name is given, then queries to the server will
              be forced via that  interface;  if  an  ip-address  is
              given  then  the source address of the queries will be
              set to that address; and if both are given then a com‐
              bination of ip-address and interface name will be used
              to steer requests to the server.  The query-port  flag
              is ignored for any servers which have a source address
              specified but the port may be  specified  directly  as
              part  of the source address. Forcing queries to an in‐
              terface is not implemented on all platforms  supported
              by dnsmasq.

Reverse lookups rev-server= (IP to name):

$ man dnsmasq
[..]
       --rev-server=<ip-address>/<prefix-
       len>[,<ipaddr>][#<port>][@<interface>][@<source-ip>[#<port>]]
              This is functionally the same as  --server,  but  pro‐
              vides some syntactic sugar to make specifying address-
              to-name   queries   easier.   For    example    --rev-
              server=1.2.3.0/24,192.168.0.1 is exactly equivalent to
              --server=/3.2.1.in-addr.arpa/192.168.0.1

For reference:

To tail the Pi-hole logs live to see whats forwarder to whom:

pihole -t

You can use the nslookup tool on a client in a particular segment for diagnosing.
Eg a forward lookup which will append the search/suffix domain to the query:

nslookup <SHORT_HOSTNAME>

Or specify the DNS server to query:

nslookup <SHORT_HOSTNAME> <DNS_SERVER_IP>

For a reverse lookup:

nslookup <IP_ADDRESS>

nslookup <IP_ADDRESS> <DNS_SERVER_IP>

Eg:

C:\>nslookup hakpc
Server:  pi.hole
Address:  10.0.0.4

Name:    hakpc.home.dehakkelaar.nl
Address:  10.0.0.11
C:\>nslookup 10.0.0.11
Server:  pi.hole
Address:  10.0.0.4

Name:    hakpc.home.dehakkelaar.nl
Address:  10.0.0.11
$ pihole -t
[..]
10:05:56: query[A] hakpc.home.dehakkelaar.nl from 10.0.0.11
10:05:56: forwarded hakpc.home.dehakkelaar.nl to 10.0.0.2
10:05:56: reply hakpc.home.dehakkelaar.nl is 10.0.0.11
[..]
10:10:42: query[PTR] 11.0.0.10.in-addr.arpa from 10.0.0.11
10:10:42: forwarded 11.0.0.10.in-addr.arpa to 10.0.0.2
10:10:42: reply 10.0.0.11 is hakpc.home.dehakkelaar.nl
$ cat /etc/dnsmasq.d/01-pihole.conf
[..]
rev-server=10.0.0.0/24,10.0.0.2
server=/home.dehakkelaar.nl/10.0.0.2

Oops sorry I forgot to answer above one.

Yes.

Its the same as supplying a client with three redundant DNS servers.
I believe queries are distributed according to below logic "Improve detection algorithm":

Thanks for all the fast response.
We're going to test this with one of our DHCP-Pools switching back to Pi-hole as primary DNS.

1 Like

I forgot to mention but also check if the Pi-hole "Conditional Forwarding" setting is enabled/configured:

http://pi.hole/admin/settings.php?tab=dns

That setting populated my 01-pihole.conf file with those directives:

$ rgrep server= /etc/dnsmasq.*
/etc/dnsmasq.d/06-rfc6761.conf:server=/test/
/etc/dnsmasq.d/06-rfc6761.conf:server=/localhost/
/etc/dnsmasq.d/06-rfc6761.conf:server=/invalid/
/etc/dnsmasq.d/06-rfc6761.conf:server=/bind/
/etc/dnsmasq.d/06-rfc6761.conf:server=/onion/
/etc/dnsmasq.d/01-pihole.conf:server=127.0.0.1#5335
/etc/dnsmasq.d/01-pihole.conf:rev-server=10.0.0.0/24,10.0.0.2
/etc/dnsmasq.d/01-pihole.conf:server=/home.dehakkelaar.nl/10.0.0.2

Hi,

I changed the configurationon the Pi-hole as suggested. We've changed the lookup zone sttings on our Windows DNS servers for TTL, update interval and repetition interval to 1 minute to check if that's the problem.

After changing the primary and secondary DNS for the zone my device is part of, resolving DNS names of devices switched between LAN and WLAN changed back to nearly 15 minutes.
On the same day I've created two virtual machines and resolvind the newly added DNS names also took a long time. I can't tell exactly how log, since I've restarted the DNS resolver service on the primary Pi-hole in between. As soon as the service has been restarted resolving the DNS was possible.

It has been ten years since I managed a windows network of around 750 desks across multiple sites. In those days it wasn't tracking and advertising sites we worried about but viruses. On my windows DNS servers I had dummy MX records and dummy A records with logging turned on. A machine on the corner of my desk recorded the IP of whoever accessed it. A web server home page declared the user was a winner of a case of beer, contact the IT department for delivery. I could guarantee any one with a virus was quickly tracked down.

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.