asked on PTR record registration for IPv4 address [[10.42.1.5]] and FQDN SLP-10090.DomainName failed with error TIMEOUT.
This seems to have begun on May 2nd. Everything is working correctly, but this error keeps popping up.
Single domain, 5 DC's, 4 DHCP Servers, 1 is server 2016, 3 are server 2019 1 is server 20121 R2, all on different subnets and physically distanced, all connect in a hub and spoke configuration using Spectrum with State of Ohio ITC providing core services. Yes DHCP is running on all DC's set to always dynamically update DNS A and PTR records. Secure updates only, DNSUpdateProxy group only contains the DHCP server names, DHCP lease set to 48 hours, DNS scavenging set to 7 days only on 1 server, have run the dnscmd /config /OpenAclOnProxyUpdates 0. Once again everything seem to be working correctly, but the error message is making me crazy.
Single domain, 5 DC's, 4 DHCP Servers, 1 is server 2016, 3 are server 2019 1 is server 20121 R2, all on different subnets and physically distanced, all connect in a hub and spoke configuration using Spectrum with State of Ohio ITC providing core services. Yes DHCP is running on all DC's set to always dynamically update DNS A and PTR records. Secure updates only, DNSUpdateProxy group only contains the DHCP server names, DHCP lease set to 48 hours, DNS scavenging set to 7 days only on 1 server, have run the dnscmd /config /OpenAclOnProxyUpdates 0. Once again everything seem to be working correctly, but the error message is making me crazy.
DHCPDNS
Last Comment
arnold
1) does your DHCP server register the ip in DNS?
2) do you have record scavanging onthe DNS
3) is this error on the server DHCP, or the client
4) which name server are used on the DHCP server and in the clients
5) how many segments, is this a branch setup.. Are the paths to all DNS servers available? I.e. If multi-branch, are the branch layered such that devices, servers communicate with their local DNS server versus possibly reaching out to a remote DNS a connection to which is currently experiencing issues, VPN down.
2) do you have record scavanging onthe DNS
3) is this error on the server DHCP, or the client
4) which name server are used on the DHCP server and in the clients
5) how many segments, is this a branch setup.. Are the paths to all DNS servers available? I.e. If multi-branch, are the branch layered such that devices, servers communicate with their local DNS server versus possibly reaching out to a remote DNS a connection to which is currently experiencing issues, VPN down.
ASKER
Hi Bembi,
At one point after business hours on a Friday I deleted all the Forward and Reverse PTR's and let them rebuild over the weekend. Everything should have been fresh at that point, yet the errors persist. I am about at the point of running a Wireshark trace if I can get a spare hour.
At one point after business hours on a Friday I deleted all the Forward and Reverse PTR's and let them rebuild over the weekend. Everything should have been fresh at that point, yet the errors persist. I am about at the point of running a Wireshark trace if I can get a spare hour.
ASKER
Hi Arnold,
The IP does register in DNS.
Record scavenging is turned on only on 1 DNS server and set for 7 days.
Error shows on the server, perhaps I should check the client, dont know why I didnt think of that earlier myself.
Name servers point first to their local address and then the secondary is a remote DNS server and after that the request go to our state DNS servers.
All paths are available at all times.
The IP does register in DNS.
Record scavenging is turned on only on 1 DNS server and set for 7 days.
Error shows on the server, perhaps I should check the client, dont know why I didnt think of that earlier myself.
Name servers point first to their local address and then the secondary is a remote DNS server and after that the request go to our state DNS servers.
All paths are available at all times.
Hello,
Friday is not enough as your lease is only 48h. That means, all leases are overdue on monday.
So cleaning up all records belonging to this client all well as all records belonging to the error message and rebboting the client may be a bit more reliable.
Interesting is the timeout message, what would mean, the client doesn't get a response from DNS for registering the PTR.
As every dns zone has permission, I would also inspect the permission on every zone if there are differences. Keep in mind that also DHCP needs a user account to write into DNS.
If would expect a different error message, but just a point to check.
Following the timeout, also raising the DNS timeout may be just a try.
As you said, that your DCs are all on different locations, it may also be a point to check, if the client really takes the local DNS / DHCP or connects to a different one. As DHCP writes into DNS, the question is if all DHCP are doing this, or also just one, what may run into a replication issue.
Friday is not enough as your lease is only 48h. That means, all leases are overdue on monday.
So cleaning up all records belonging to this client all well as all records belonging to the error message and rebboting the client may be a bit more reliable.
Interesting is the timeout message, what would mean, the client doesn't get a response from DNS for registering the PTR.
As every dns zone has permission, I would also inspect the permission on every zone if there are differences. Keep in mind that also DHCP needs a user account to write into DNS.
If would expect a different error message, but just a point to check.
Following the timeout, also raising the DNS timeout may be just a try.
As you said, that your DCs are all on different locations, it may also be a point to check, if the client really takes the local DNS / DHCP or connects to a different one. As DHCP writes into DNS, the question is if all DHCP are doing this, or also just one, what may run into a replication issue.
Is the error coming from a domain joined system?
Best to have the DHCP register records when it issues the IP.
Double check the Settings on this host whether it uses the Full Domain name in the registration request.
The error should indicate which DNS server it was sending the registration request to.
Best to have the DHCP register records when it issues the IP.
Double check the Settings on this host whether it uses the Full Domain name in the registration request.
The error should indicate which DNS server it was sending the registration request to.
ASKER
Good idea, thank you.
matt
matt
ASKER
Follow up to my question.
If I turn DNS updates to secure or not secure the errors stop. This leads me to believe that an ACL is not correct. I am using my DHCPUpdateDNS user credentials here:
I even went into the DNS partition using ADSIEdit and added that user with full permissions. Still NADA.
Thoughts appreciated.
matt
If I turn DNS updates to secure or not secure the errors stop. This leads me to believe that an ACL is not correct. I am using my DHCPUpdateDNS user credentials here:
I even went into the DNS partition using ADSIEdit and added that user with full permissions. Still NADA.
Thoughts appreciated.
matt
Secure means, than only computers which are member of the AD domain are allowed to update their records.
So, it is first not user specific but computer specific.
If the computer is not member of the domain, secure can not work.
If the computer in member of the domain, than it should work, in that case it may be an option to remove the client from the domain, delete the computer object in AD and rejoin the client to the domain.
So, it is first not user specific but computer specific.
If the computer is not member of the domain, secure can not work.
If the computer in member of the domain, than it should work, in that case it may be an option to remove the client from the domain, delete the computer object in AD and rejoin the client to the domain.
Based on your comment, it indicates the Dynamic update option was set to NONE.
Does your DHCP server run on a windows member server?
Does your DHCP server run on a windows member server?
ASKER
Hi Arnold,
All four DHCP servers are on DC's. Hence my approach recommended by Microsoft and and Best Practices Analyzer.
All four DHCP servers are on DC's. Hence my approach recommended by Microsoft and and Best Practices Analyzer.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
That is exactly what I was attempting to do, having DHCP update the records. It does do it, but I still get the error. I'm still looking, it has to be a permission issue somewhere, because if I change to Secure/Non-Secure the errors stop.
I'm thinking that an ACE entry needs to be added to an ACL somewhere, I just have to figure out who and where.
I'm thinking that an ACE entry needs to be added to an ACL somewhere, I just have to figure out who and where.
The error as you posted is an update being attempted by the client, which is commonly active on the Network adapter dealing with registering the connection.
You should only have secure updates as explained earlier, this will authorize domain joined devices the ability to register records.
note you have two zone that could be updated
the forward zone. domain.com
and the IP reverse zone
1.42.10.in-addr.arpa
Depending on your IP range the above relies on a /24 254 host IP block. ..
You should only have secure updates as explained earlier, this will authorize domain joined devices the ability to register records.
note you have two zone that could be updated
the forward zone. domain.com
and the IP reverse zone
1.42.10.in-addr.arpa
Depending on your IP range the above relies on a /24 254 host IP block. ..
Maybe it was generated by a different device?
Usually a DHCP client keeps its IP as long as he renews the IP within the lease. But as DHCP has 2d and DNS has 7d, it may happen, that DHCP changes the IP, while DNS has it registerd to different device. They are usually simmilar according the times.
What I would do is just to delete the PRT record and to see, if the current device then registers correctly.