none
Problem w/Reverse Lookup Zone | Server 2008 Standard RRS feed

  • Question

  • I have a very strange issue. Had to delete our reverse lookup zone and recreate it due to some troubleshooting with network connectivity. DCDiag tests all pass fine and no errors in event log. Problem is any PTR record that gets created automatically or manually does not change the FQDN of the PTR. The zone is a standard primary active directory-integrated zone with the name 1.168.192.in-addr.arpa. Any PTR record that gets created will have the same FQDN regardless of the host IP address and Host name.

    For example:
    Host IP Address: 192.168.1.2
    FQDN: 1.168.192.in-addr.arpa (unable to edit) - it should be 2.1.168.192.in-addr.arpa
    Host name:myserver.mydomain.local (this is generic for the post)

    If I run NSLOOKUP on the server i get:
    Default server: myserver.mydomain.local
    Address: 192.168.1.2

    NSLOOKUP 192.168.1.2
    Server: [192.168.1.2]
    IP Address 192.168.1.2
    *** 192.168.1.2 can't find nslookup: Non-existent domain

    NSLOOKUP myserver
    Server: myserver.mydomain.local
    Address: 192.168.1.2
    *** myserver can't find nslookup: Non-existent domain

    NSLOOKUP myserver.mydomain.local
    Server: myserver.mydomain.local
    Address: 192.168.1.2
    *** myserver.mydomain.local can't find nslookup: Non-existent domain

    NSLOOKUP mydomain.local
    Server: mydomain.local
    Address: 192.168.1.2
    *** mydomain.local can't find nslookup: Non-existent domain

    Now I know the above is caused by the incorrect FQDN for the PTR record but I am unable to edit it so am at a loss as to how to resolve this.

    In addition, any client computer that gets a PTR record created automatically or manually also has the same read only FQDN of 1.168.192.in-addr.arpa (192.168.1.200 client should be 200.1.168.192.in-addr.arpa)

    I have searched for days for an answer to this but I can't find anyone that has had a similar problem. I don't know if this was caused by the recent problems with Windows updates or not over the past few months but its killing our network.

    Please help. Thank you.

    Friday, June 24, 2016 7:21 AM

All replies

  • Hi,

    Are there any error messages on the event logs?

    Did you try to repair the DNS?

    https://support.microsoft.com/en-us/kb/305967

    FrenchITGuy.com

    Friday, June 24, 2016 8:14 AM
  • Hello. I do not see any errors in the server's event log though on client computers they have a range of errors like Event ID 1054, 1030, 1096, 50 etc. All because of the incorrect PTR FQDN.

    I have not tried to do a repair since I was hoping I wouldn't have too. Never done it before so I'm a bit nervous about doing it.

    Friday, June 24, 2016 6:36 PM
  • Well I did the repair and the reverse zone still is not working. Any PTR still has 1.168.192.in-addr.arpa as the FDQN for any Host A record.

    I even tried deleting the zones and creating new ones from DNS files from a working server which I edited. Still nothing fixed it.

    I then uninstalled DNS, rebooted, reinstalled DNS and the same thing occurred. I am at a total loss why the reverse zone will not include the correct FDQN name for any IP address that has a PTR record.

    Monday, June 27, 2016 2:16 AM
  • Hi  GAVEN_t,

    1.Have you running any anti-virus software or third-party applications, if yes, please turn them off and test.

    2. Please show us an example of your issue, please create a standalone zone such as "test.com", then created a reverse zone "11.12.13.in-addr.arpa", then add an A record in test.com: a.test.com 13.12.11.10, and check registry PTR record in reverse lookup zone. Then in cmd, please show us the screenshot of nslookup a.test.com and nslookup 13.12.11.10.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.


    Monday, June 27, 2016 3:14 AM
    Moderator
  • Link to images http://imgur.com/a/0s89D

    Sorry the site is not letting me insert pictures. Says my account is not verified though I verified recently to start this original post.

    As you can see in the last image the FQDN is incorrect. It should be 10.11.12.13.in-addr.arpa. DNS is cutting off the 10 just like my other reverse zone.

    • Edited by GAVEN_t Monday, June 27, 2016 5:58 AM
    Monday, June 27, 2016 5:53 AM
  • Hi GAVEN_t,

    Strange things, the DNS resolution is correct while the GUI is actually incorrectly.

    Have you checked third-party applications?

    Besides, could you Remote to the DNS console, if remote to it can show correctly, then it seems the issue is related with DNS GUI.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, June 27, 2016 6:20 AM
    Moderator
  • I don't have any anti-virus programs installed on the server. The server does host some applications for the client computers and I cannot disable them at this time though the server has had no issues for over 6 years until the last couple of months due to this DNS issue. It seems that one of the Windows Updates affected this but cannot find any information that others have experienced this same thing.

    The only thing I do see that also odd is on the name server tabs. When I resolve myserver.mydomain.local it resolves to 192.168.1.2 but also lists ::1

    I don't have IPV6 enabled on the NIC so not sure where DNS is getting the ::1

    Monday, June 27, 2016 6:41 AM
  • Hi GAVEN_t,

    > It seems that one of the Windows Updates affected this but cannot find any information that others have experienced this same thing.

    Updates might be possible, could you uninstall the latest updates?

    >I don't have IPV6 enabled on the NIC so not sure where DNS is getting the ::1

    Please uncheck "TCP/IPv6" on NIC properties.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, June 27, 2016 6:47 AM
    Moderator
  • It's already been unchecked. It's been unchecked for years.

    I can uninstall the updates but it will take a lot of time and I'm worried that it could make things worse.

    • Edited by GAVEN_t Monday, June 27, 2016 7:19 AM
    Monday, June 27, 2016 6:49 AM
  • Please check for registry corruption.

    HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\DNS Server\Zones

    Monday, June 27, 2016 11:16 PM
    Owner
  • Hi Gaven_t,

    I'm going to go right back to your first post here as there's something I just can't reconcile.

    Did you copy that output verbatim? The only way I could reproduce the behaviour and hence the results you've posted is to:

    1. Run nslookup from the command line without parameters - much as you have described in your third paragraph.
    2. Proceed to literally run from within the nslookup session your subsequent queries, for example "nslookup 192.168.1.2".

    Based on these two steps, the output results you've obtained are 100% to be expected, as breaking down the actions of step 2:

    1. By typing "nslookup" first, you're actually trying to find a host named "nslookup".
    2. By typing "192.168.1.2" second, you're instructing the DNS client to use the DNS server of address "192.168.1.2" to try and resolve the host name of "nslookup".

    In other words, the first parameter is the host you want to try and resolve while the second parameter nominates a particular server with which to attempt the name resolution.

    Honestly, I think this has just been an accident with nslookup which is why nothing is being reported as erroneous within dcdiag (you could always run "dcdiag /test:dns" if you want to specifically target just the DNS environment).

    As for the image you've posted of the reverse lookup record, that looks "fine". I say fine loosely as really, the FQDN should include the host component, not just constantly reflect the zone name. However, this behaviour appears to be consistent across the DNS Management MMC at this point in time, as I am seeing this across multiple Server 2012 R2 environments. Regardless, it has no bearing whatsoever on the DNS client and server behaviour and is just a user interface anomaly.

    It's important to keep in mind that when you launch nslookup without parameters, it selects the default name server as specified in the output of "ipconfig /all" and then immediately performs a reverse nslookup on that specific IP address. If you had any issues at all, that would have failed, but in your output you can clearly see it's resolved. The section of your output I'm referring to here is:

    Default server: myserver.mydomain.local
    Address: 192.168.1.2

    Bringing this full circle, I think all you accidentally missed is typing exit after your first nslookup command.

    Cheers,
    Lain

    Monday, June 27, 2016 11:46 PM
  • Please check for registry corruption.

    HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\DNS Server\Zones


    I'm not seeing any corruption.
    Tuesday, June 28, 2016 7:59 AM
  • How is the zone represented here?  Does it look like what is below?

    Also in the windows\system32\dns directory if you review the contents of the file that is pointed to by the "DatabaseFile" entry in the registry, which is 11.12.13.in-addr.arpa.dns in this example, do the contents look similar to what is below?

    ;
    ;  Database file 11.12.13.in-addr.arpa.dns for Default zone scope in zone 11.12.13.in-addr.arpa.
    ;      Zone version:  2
    ;

    @                       IN  SOA dns1.phx.gbl. hostmaster.phx.gbl. (
                              2            ; serial number
                              900          ; refresh
                              600          ; retry
                              86400        ; expire
                              3600       ) ; default TTL

    ;
    ;  Zone NS records
    ;

    @                       NS dns1.phx.gbl.

    ;
    ;  Zone records
    ;

    10                      PTR test.com.

    Tuesday, June 28, 2016 8:29 AM
    Owner
  • Greg,

    Outside of the misuse of nslookup in the original post and the cosmetic issue from the MMC not prepending the host value, there's actually nothing to show anything being wrong with DNS in this post. In fact, the comment about dcdiag along with the successful reverse lookup from the imgur.com only serve to suggest everything is fine with the reverse lookup zones.

    If there's a reason for the networking being "killed" (paraphrased), then it wouldn't appear thus far that DNS is the reason at all.

    Gaven_t, so far, there's no evidence there's an issue with DNS. What exactly do you mean by the network is being "killed"?

    Cheers,
    Lain

    Tuesday, June 28, 2016 8:41 AM
  • Lain you are correct about the NSLOOKUP results. I did this very late and forgot to exit. My apologies to all. Below are the NSLOOKUP results individually.

    However, this still doesn't resolve how/when/why the PTR records stopped dropping the host component of the FQDN because it seems that ever since this all of my domain computers get frequent network connection drops and events like the following which cause network shares to have a red x and server host applications to stop working. it's brief disconnect and if you click on the network share red x goes away. But trying to run applications on the client computers that connect to databases on the server causes a lot of problems when the program crashes since the client can't find the server for a moment. It could be a coincidence and I really am starting to think it must be a Windows Update that is causing this problem.

    Event: 1054 The processing of Group Policy failed. Windows could not obtain the name of a domain controller.
    Event: 1055 The processing of Group Policy failed. Windows could not resolve the computer name.
    Event: 1058 The processing of Group Policy failed. Windows attempted to read the file...
    Event: 5719 No Domain Controller is available for domain

    Problems started at the beginning of May 2016. I have replaced network switches, network adapters, network cables, unjoined/rejoined computers to domain, flushed dns, registered dns, etc. I'm just at a loss. Looks like the next step will have to be uninstalling the updates to the server over the past 2 months.

    I've also done pretty much every resolution found by Microsoft and others for these types of events but nothing has stopped the disconnects. Right now I am monitoring the changes I made to the Group Policy Refresh Interval and Background Group Policy Refresh when computer in use. Hoping this will stop it for a while.

    Thanks.

    Here are the NSLOOKUP results individually.

    NSLOOKUP
    Default server: myserver.mydomain.local
    Address: 192.168.1.2

    ----------

    NSLOOKUP 192.168.1.2
    Default server: myserver.mydomain.local
    Address: 192.168.1.2

    Name: myserver.mydomain.local
    Address: 192.168.1.2

    ----------

    NSLOOKUP myserver
    Server: myserver.mydomain.local
    Address: 192.168.1.2

    Name: myserver.mydomain.local
    Address: 192.168.1.2

    ----------

    NSLOOKUP myserver.mydomain.local
    Server: myserver.mydomain.local
    Address: 192.168.1.2

    Name: myserver.mydomain.local
    Address: 192.168.1.2

    ----------

    NSLOOKUP mydomain.local
    Server: myserver.mydomain.local
    Address: 192.168.1.2

    Name: mydomain.local
    Address: 192.168.1.2

    ----------

    NSLOOKUP mydomain (without .local)
    Server: myserver.mydomain.local
    Address: 192.168.1.2

    *** myserver.mydomain.local can't find mydomain: Non-existent domain



    • Edited by GAVEN_t Tuesday, June 28, 2016 8:53 AM
    Tuesday, June 28, 2016 8:41 AM
  • Greg I will get you that information hopefully tomorrow. It's very late again working on this issue so I must go. Thanks everyone for helping me troubleshoot.
    Tuesday, June 28, 2016 8:56 AM
  • Hi Gaven_t,

    Thanks for the clarification.

    Firstly, don't worry about the missing host component from the DNS MMC as I've validated that is a cosmetic UI issue in all the Windows Server 2012 R2 environments I manage, too. I know when things are going wrong it's stressful but this isn't indicative of having a DNS issue. The only test you need to concern yourself with is the DNS server provides the correct responses, which based on your updated feedback above, it does, so you can breathe easy on that front.

    You can also ignore that final nslookup failure above as it's not going to resolve the NetBIOS domain name. You're essentially requesting the DNS equivalent of mydomain.mydomain.com which quite likely isn't a valid DNS domain namespace.

    Are you pulling those group policy failure events from the System event log, per chance? If so, you might want to also check for any warnings related to the network interface dropping and coming back up.

    Given your issues seem to span more than just group policy usage, I don't think delving into the group policy-specific event log is going to yield results as I believe that's just a symptom from the real issue.

    Is there anything you can do that can reliably reproduce the error condition?

    Have you checked the event logs on the DNS servers themselves to see if there's any issues?

    Are you able to provide an "ipconfig /all" from the domain controller, myserver.mydomain.local? (192.168.1.2) Are you also able to provide an "ipconfig /all" from the client you're testing from?

    When you run nslookup from a client, does the response feel snappy or is there a delay of a second or so?

    Cheers,
    Lain

    Tuesday, June 28, 2016 8:59 AM
  • Since I've extended the gp refresh interval and disabled the gp background refresh while computer in use most of these if not all errors have gone away but the client computers are still disconnecting a few times a day. I'm still reviewing the client computer logs but on our xray pc that is connected to our xray machine the pc lost connection today and threw up errors while trying to transfer the pan/ceph xrays from the machine to the pc which writes to our server:

    EVENT ID 139 {Delayed Write Failed} Windows was unable to save all the data for the file \\MYSERVER\Tigerview\Data\tvdata.mdb;

    EVENT ID 50 {Delayed Write Failed} Windows was unable to save all the data for the file \Data\tvdata.mdb.

    Many times today we would click Start, Computer and see if the network shares had red x's and they frequently had them. if we clicked on the red x on the network shares they go away and we can see the contents. have tried net config server /autodisconnect:-1 on server and pc but still happens.

    Problem is only with Window 7 Pro computers connected to our domain. I have a few Windows 10 computers configured as workgroup which do not have these problems.

    I'm waiting on some new Windows 10 Pro computers to come in which I will test hopefully next week if the same thing occurs.

    --------------------

    SERVER IP CONFIG /ALL

    Windows IP Configuration

       Host Name . . . . . . . . . . . . : MYSERVER
       Primary Dns Suffix  . . . . . . . : mydomain.local
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : mydomain.local

    Ethernet adapter Local Area Connection:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Broadcom BCM5708C NetXtreme II GigE (NDIS VBD Client) #1
       Physical Address. . . . . . . . . : 00-22-19-B5-34-3A
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 192.168.1.2(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 192.168.1.1
       DNS Servers . . . . . . . . . . . : 192.168.1.2
       NetBIOS over Tcpip. . . . . . . . : Enabled

    -----------------------

    XRAY PC IP CONFIG /ALL

    Windows IP Configuration

       Host Name . . . . . . . . . . . . : PANMACHINE
       Primary Dns Suffix  . . . . . . . : mydomain.local
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : mydomain.local

    Ethernet adapter Local Area Connection 1:

       Connection-specific DNS Suffix  . : mydomain.local
       Description . . . . . . . . . . . : Gigabit PCI Express Network Adapter
       Physical Address. . . . . . . . . : EC-08-6B-03-5D-8B
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 192.168.1.13(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Lease Obtained. . . . . . . . . . : Tuesday, June 28, 2016 2:29:37 AM
       Lease Expires . . . . . . . . . . : Tuesday, July 19, 2016 2:29:37 AM
       Default Gateway . . . . . . . . . : 192.168.1.1
       DHCP Server . . . . . . . . . . . : 192.168.1.2
       DNS Servers . . . . . . . . . . . : 192.168.1.2
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Ethernet adapter Local Area Connection 2: (THIS CONNECTS TO XRAY MACHINE)

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : D-Link DFE-530TX+ PCI Fast Ethernet Adapter (rev.F)
       Physical Address. . . . . . . . . : BC-F6-85-03-DA-11
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 192.168.240.1(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . :
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter isatap.{D4C53D2D-50D2-4DD1-B760-4EC203983E99}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter isatap.mydomain.local:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : mydomain.local
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes


    • Edited by GAVEN_t Wednesday, June 29, 2016 5:09 AM
    Wednesday, June 29, 2016 5:06 AM
  • Hi Gaven_t,

    Did you get a chance to check the System event log to see if there are any events from the network interface driver indicating link state changes? You could check this event log on both the server and the client to be thorough.

    Is "MYSERVER" running Server 2008 R2 by any chance? If so, you might want to have a read of this article, specifically "scenario 2", as it may be relevant to the behaviour you're seeing. Similarly, is offline files used within the environment?

    Another setting you can check is whether or not the network card is allowed to be disabled by power management. Typically, you'll find this setting under Device Manager -> Network Adapters -> adapter -> Properties. From here it can be under areas such as the Advanced tab or Power Management, if you've got it. You'll have to have a look around but the point is to disable the setting if it exists.

    Of course, external to this is whether or not the switching and/or routing infrastructure is having issues. I'm not sure if you have the access and ability to check the uptime of the relevant switches, etc. but it remains an option that can be checked.

    Cheers,
    Lain

    Wednesday, June 29, 2016 5:48 AM
  • I apologize for the delay. I have been out with a family emergency.

    Forgot to respond to your other question. When I run NSLOOKUP from any client it is fast and snappy so no delays there.

    Not seeing any network link state changes in the event logs on the server and client. I downloaded wireshark on the server and have entered a filter to capture data for ldap, dns and dhcp but I'm not sure what exactly I am looking for in regards to errors. I'm researching this now to understand how to use wireshark.

    MYSERVER is running Windows Server 2008 Standard not R2. It's a very old server that will be replaced hopefully this year. All hardware have the latest drivers and firmware updates.

    All of the NICs on the server and client computers have the power management disabled. Just this year we replaced the SonicWall TZ215 and Gigabit 24-port Network Switches

    Since these network disconnects were happening many times during the day and the owner/staff started to complain I went ahead and disjoined all the computers from the domain and set them up as workgroup computers. As of yesterday when I did it we have not had a single issue. I have a few test computers still on the domain that I am monitoring and they are still experiencing the same problem. It has too be some type of Server 2008 corruption or side affect caused by Windows Updates on the Server that were installed in May.

    Once I get my Windows 10 Pro computers in I will set them up on the domain and report back. Thank you all for your assistance. It is much appreciated.

    Friday, July 1, 2016 6:28 PM
  • Greg I still can't insert pictures or include your quote to reply since it keeps saying by account needs to be verified which it already has or I wouldn't be able to post :/

    But to answer your question about the Registry:

    I do not have a DatabaseFile or IsKeyMaster in the registery for any of the zones. I have the other entries though. Not sure if its because I have the original Windows Server 2008 Standard and they changed something in 2008 R2 or Server 2012.

    Friday, July 1, 2016 6:44 PM
  • Hi,

    The IsKeyMaster entry was added to support DNSSEC in Server 2012, so you wouldn't have that. 

    I spun up a 2008 server to look at the DatabaseFile entry and determined this is only present if the zone is file-backed. If the zone is AD-integrated you won't have this. Instead, you'll have a "DirectoryPartition" string entry.

    -Greg

    P.S. Verification is different than signing in to TechNet.

    http://social.technet.microsoft.com/wiki/contents/articles/15960.how-to-verify-your-msdntechnet-forums-account-so-that-you-can-post-images-and-links.aspx

    Friday, July 1, 2016 8:36 PM
    Owner