Since setting up this domain, I have had our DC provide DNS only, and left DHCP on the SonicWALL. This has caused a number of headaches since switching to Spiceworks, as I could not get the reverse lookup zone to update dynamically, and Spiceworks lost its head about who had what IP address a week later. Today I turned off DHCP on the router and enabled it on the DC. I was quite frustrated to find that neither the clients nor the DHCP server (which is on the same box as AD and DNS) were unable to update the reverse lookup zone. After some digging I found that I needed to provide the DHCP server with credentials to do so, and finally got the dynamic, secure updates working. To make sure DNS was always accurate, I told DHCP to update the A and PRT records even if the client does not ask for that. The problem is that, when any computer is added to the LAN, it gets an A and a PTR record in DNS.
Ideally, I want to force all domain computers to always update all records in DNS - while also preventing non-domain computers from updating anything in DNS. Is there a way to tell Microsoft's DHCP server to always update records, but only for domain-joined PCs?
Or possibly more ideally: why can't domain-joined PCs update the reverse lookup zone by default, and how do I make THEM do it and not just the DHCP server? As long as I have been running this domain they have only been updating their A records. It is just a forward lookup zone mostly with static DNS entries for printers, etc. Anyways, I just checked and it seems to have started working, for some reason I can't figure out.Anyways, never mind, I think I figured it out. Under my SOA, the primary server was just 'myserver.' I read somewhere that it doesn't like it without a FQDN. So I changed it to 'myserver.domain.home' and it seems to be working.
The server will automatically recognize your new IP address,.
It is not on a domain but it does have a DNS suffix that I append to it and that seems to have fixed it! Thanks to everyone who was helping out, but I think I got it! Yes, it is functioning normally, but that is not how I want it to function ideally. I want the DHCP server to lease the IP to everyone on the network, regardless of whether or not they are joined to the domain.
If the client device is on the domain, I want the device to update its own A and PTR records. If the device is not on the domain, they won't have permission to update their records, and therefore will have an IP address only and will not have a hostname. That is what I am trying to achieve. The problem is that the clients are not updating their PTR records - they have only ever been able to update their own A records, and I couldn't fix that by changing permissions on the reverse lookup zone. The only way I have gotten the reverse lookup zone to work dynamically is to add credentials for the DHCP server to do the update itself.
What that means is that if somebody makes a VM in VirtualBox or plugs in their personal laptop, their device could be 'official-server-name02.theactualdomain.company' for the next week without being joined to the domain. In your environment, does the DHCP server update the A and/or PTR records for the clients? Or is it the clients who update the records themselves? It seems to me that the best case would be for the clients to update both the A and PTR on their own. I think you're right about that, the DHCP service simply doesn't have that kind of flexibility. I got things working the right way and made the clients update their own PTR records.
I had to configure some settings in Group Policy which weren't letting it work right. I'm not sure exactly what policy change fixed it, but one of the Group Policy suggestions here did the trick:.
I also set the policies to always use secure updates, and always update the PTR even if updating the A fails. So in our setup now, DHCP clients are told to update their own A and PTR records. The DHCP server has been told not to update DNS for anyone, whether or not they ask it to. The DHCP server's credentials to do the updates have been taken away.
The result is that domain computers should keep themselves up to date in both the forward and reverse DNS lookup zones, and non-domain joined computers cannot update DNS, and therefore will not have a resolvable hostname on the network.
Dynamic DNS for the Asus RT-N16 Tomato v1.28Router Sceenshot tomato Basic: DDNS Tomato (beta) Version 1.28 Status Overview Device List Logs Bandwidth Tools Basic Network Identification Time DDNS Static DHCP Wireless Filter Advanced Port Forwarding Basic DMZ Triggered UPnP / NAT-PMP QoS Access Restriction USB and NAS VPN Tunneling Administration About Reboot. Logout tomato Dynamic DNS IP address Use WAN IP Address 192.168.1.97 (recommended) Use External IP Address Checker (every 10 minutes) Offline (0.0.0.0) Offline (1.1.1.1) Offline (10.1.1.1) Custom IP Address. Custom IP address Auto refresh every days (0 = disable) Dynamic DNS 1 Service None 3322 3322 - Static DNS Exit DNS-O-Matic DynDNS - Dynamic DynDNS - Static DynDNS - Custom DynDNS (https) - Dynamic DynDNS (https) - Static DynDNS (https) - Custom DyNS easyDNS easyDNS (https) EditDNS EveryDNS eNom FreeDNS (afraid.org) ieServer.net namecheap No-IP.com OpenDNS TZO ZoneEdit Custom URL URL. This service determines the IP address using its own method.
Comments are closed.
|
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |