pfSense DHCP + Windows DNS, Reverse Lookup Problems, No PTR Records Being Created
-
Not a straight forward setup:
pfSense runs DHCP. Pi-Hole for DNS, but also Windows DNS for local active directory (Pi-Hole conditional forwarder).This all works fine. A records are created for clients in Windows DNS, but no PTR records are created, so reverse lookups fail.
Can anyone think why this might be?
-
To fix your immediate problem, try the suggestion here: https://serverfault.com/questions/639398/reverse-dns-records-not-registered-when-using-dhcp.
However, the better way to do this would be to just let the Windows AD server handle everything (DHCP, DNS and of course the AD Domain Controller Role). Configure DNS on the AD Controller to forward to Pi-Hole for non-local lookups where the AD DNS is not authoritative. Pass out the Windows AD DNS Server to clients via the DHCP options.
-
@bmeeks Thanks, based on that article I am looking at group policy settings to set Windows clients and servers to register PTR records more forcibly, I will see how I get on.
However, my reasons for not wanting to use the setup you mention are numerous:
Windows DHCP is really poor, reliability is bad, poor management abilities, exporting, UI for management, PowerShell functionality is average. It runs on a massively bloated OS that due to its size and complexity and due to needing regular patching its more at risk, more down time etc. DHCP on pfSense is totally solid, and has all the features I need.
Forwarding Pi-Hole queries from Windows DNS means EVERY query comes from the same IP which makes reporting non-existent and whitelisting or blacklisting extremely difficult.
Any finally, because I don't have to - Everything works perfectly as it is now, with the exception of Pi-Hole reverse lookups. Worst case scenario I export the DHCP table from pfSense and batch created PTR records using PowerShell.
-
@mikhailcompo said in pfSense DHCP + Windows DNS, Reverse Lookup Problems, No PTR Records Being Created:
Windows DHCP is really poor, reliability is bad, poor management abilities, e
Sorry but BS! plain and simple... There are huge companies that run HUGE networks off dhcp servers off MS.. MS has made drastic improvements in their dhcp and dns over the years.. Yeah dhcp and dns back in the days of windows for workgroups 3.11 was shit ;)
But current implementations are feature rich and stable.. dhcp and dns of pfsense is fine for some small branch office or ma and pop shop without AD. But if your a MS shop and not running dhcp and dns off your AD - sorry but your just doing it freaking wrong, and there is no way by any stretch of the imagination running it off pfsense would be better choice..
Forwarding Pi-Hole queries from Windows DNS means EVERY query comes from the same IP which makes reporting non-existent a
Doing it wrong then is all - have your clients query pihole first, then pihole forward to your AD dns.. Which has nothing to do with dhcp registration of client in your AD dns which is done to the SOA of the domain, etc. etc.
-
I suggested the Windows DHCP route because you stated you already had DNS running on Windows for AD, and that implies a Domain Controller as well (for the AD). So adding DHCP is just one more role (or service) running on the Domain Controller (assuming that's where you put the DNS server).
I assume that you instead have all of your clients pointing to the Pi-Hole server for DNS, and then on Pi-Hole have configured your local domain (the AD domain) to point to your Windows DNS server as the authoritative NS for that domain. Otherwise, your clients would not be able to do all of their AD-related lookups.
That setup will work as well if you have specific logging and/or client identification requirements. But in general cases, with Windows AD in the mix, it is better to let the AD side handle all of the stuff for the local domain, and then conditionally forward to something like Pi-Hole if you are trying to either block ads or restrict access to certain domains (adult content, for example).
Folks post here with widely differing skill levels, so it can be hard to tailor the perfect answer to each question. So my original answer was not to imply that your setup would not work, but just to state the more general case where it is sometimes easier/better to just let Windows AD do all the DHCP and DNS stuff in a Windows Domain. But specific needs can override the general case, and so long as the admin understands what needs to be done, more customized setups are fine.
-
@bmeeks said in pfSense DHCP + Windows DNS, Reverse Lookup Problems, No PTR Records Being Created:
To fix your immediate problem, try the suggestion here: https://serverfault.com/questions/639398/reverse-dns-records-not-registered-when-using-dhcp.
However, the better way to do this would be to just let the Windows AD server handle everything (DHCP, DNS and of course the AD Domain Controller Role). Configure DNS on the AD Controller to forward to Pi-Hole for non-local lookups where the AD DNS is not authoritative. Pass out the Windows AD DNS Server to clients via the DHCP options.
So I created the following GPO and deployed to all clients and servers:
I then proceeded to perform a GPupdate on test clients and servers, then performed a release renew, DNS registration, with mixed results.......(typically Windows......).
My Windows 10 workstation immediately registered a dynamic PTR record, very clearly the GPO has had an impact on that machine...
login-to-viewBut no other windows servers or client machines are doing so for some reason.
Ironically, my Canon printer has been merely creating PTR and A records the whole time, it just behaves itself...
Windows has not been doing so, but perhaps some settings can cause this to happen.
All Android devices, and smart TVs etc. are all failing to create PTR records.....
Frustrating.
-
@bmeeks said in pfSense DHCP + Windows DNS, Reverse Lookup Problems, No PTR Records Being Created:
I assume that you instead have all of your clients pointing to the Pi-Hole server for DNS, and then on Pi-Hole have configured your local domain (the AD domain) to point to your Windows DNS server as the authoritative NS for that domain. Otherwise, your clients would not be able to do all of their AD-related lookups.
Yes, I use conditional forwarding to my two DCs in my /23 network.
Folks post here with widely differing skill levels, so it can be hard to tailor the perfect answer to each question. So my original answer was not to imply that your setup would not work, but just to state the more general case where it is sometimes easier/better to just let Windows AD do all the DHCP and DNS stuff in a Windows Domain. But specific needs can override the general case, and so long as the admin understands what needs to be done, more customized setups are fine.
Yes I apprecaite there are many ways to set this up, and each technology seems to have an expectation of 'what is right' and particularly the Microsoft approach and to a similar extent Pi-Hole, the expectation is 'my way or the highway' which makes it feel like any alternative configuration is something of a hack.....
I'll get there eventually! Thanks for your help, very much appreciated.
-
Amended my GPO and now I am seeing more registrations coming in from clients and servers....
-
Here is another link to some Microsoft documentation. I think you are going to have potential issues by using the DHCP Server on pfSense (or really almost any non-Windows DHCP Server) instead of using the Windows DHCP Server.
Some parts of the DNS registration are done by the host acquiring the DHCP address, but frequently the PTR records are expected to be created by the DHCP Server. Here is the pertinent quote from the Microsoft literature:
- When DHCP is implemented, by default the PTR Records are registered to DNS by DHCP Server, whereas the Host (A) records are registered by DHCP client. This is due to the fact that client is the source of the hostname and DHCP is the source of the IP address.
And here is another Microsoft article explaining how DNS dynamic updates work in Windows: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-dns-dynamic-updates-windows-server-2003.
And finally, I will agree with @johnpoz that the DHCP Server in Windows today is quite robust. It even offers failover in the latest Windows versions if I recall. It certainly is more robust than the DHCP Server bolted onto pfSense.
With your Group Policy settings, you may be able to influence how Windows clients that accept and process group policies behave with regards to dynamic DNS updates, but that won't impact your non-Windows clients who don't speak "group policy". That's why I think using the Windows DHCP server would work better for you. It will automatically take care of all the dynamic DNS updates for you (in the Windows AD DNS server).
-
@bmeeks said in pfSense DHCP + Windows DNS, Reverse Lookup Problems, No PTR Records Being Created:
And finally, I will agree with @johnpoz that the DHCP Server in Windows today is quite robust. It even offers failover in the latest Windows versions if I recall. It certainly is more robust than the DHCP Server bolted onto pfSense.
I think you are analysing the DHCP service in isolation, and ignoring the fact that it sits on a Windows operating system - if the kernel has issues, when a poorly implemented update is relapsed that breaks things, when a new feature you do not want is pushed whether you like it or not, or when a vulnerability is patched and disables a feature without prior warning as a workaround rather than a fix, these are all recent Windows server failings......
pfSense is simpler and more reliable, coming from a Microsoft Certified Professional Windows client and server engineer with 15 years in the industry....
I like Windows, I use it every day, but it's not for critical infra for me thanks.
-
@bmeeks said in pfSense DHCP + Windows DNS, Reverse Lookup Problems, No PTR Records Being Created:
When DHCP is implemented, by default the PTR Records are registered to DNS by DHCP Server, whereas the Host (A) records are registered by DHCP client. This is due to the fact that client is the source of the hostname and DHCP is the source of the IP address.
This is interesting, but I have enabled client PTR registration in all Windows machines, so that is resolved.
All other clients are non-Windows and therefore non-Active Directory so not an issue. Despite that, I have exported the host list from DHCP to DNS and created PTR records for my non-Windows clients such as my Android phone, watch, kindle etc.
Everything is working fine now. Its all sorted............
Thanks