1

Not sure if this is safe to delete. I have read that these AD domain name records are created by netlogon service, and/or others, and not changeable. I have two domain controllers, each showing correctly in AD DNS, but there's a third record with an IP of 192.168.203.0 ??? I don't know where that came from. Is it safe to delete?

I ask because this seems to be causing some issues with Exchange Autodiscover internally. dcdiag (with no args) returns all ok, and there's no errors in Event Logs regarding replication or AD. If I run dcdiag with /test:dns I get all kinds of errors with all the hosts on the network tested as DC's.

Just a little background. We are currently in the process of migrating from 2003 to 2010 Exchange server and have setup a new 2012 R2 DC. The old DC is 03 with Exchange. (I know, not good, but was setup 10 years ago by someone else!). I have a lab setup with the same servers (from images taken before migration) and there's no IP with .0 in the root of the domain there. So this showed up on the production systems since upgrades started recently. The 03 server will be decommissioned in the next week or so, so maybe it will go away in that process?

I appreciate any advice. Thank you!

Here's an nslookup on the domain for reference, you can see the .0 record.

    C:\>nslookup
Default Server:  UnKnown
Address:  fdcc:12e5:12e5:cb::2

> server 192.168.203.222
Default Server:  bert.yourdomain.org
Address:  192.168.203.222

> set type=any
> yourdomain.org
Server:  bert.yourdomain.org
Address:  192.168.203.222

yourdomain.org   internet address = 192.168.203.4
yourdomain.org   internet address = 192.168.203.0
yourdomain.org   internet address = 192.168.203.222
yourdomain.org   nameserver = mail.yourdomain.org
yourdomain.org   nameserver = bert.yourdomain.org
yourdomain.org
        primary name server = bert.yourdomain.org
        responsible mail addr = hostmaster.yourdomain.org
        serial  = 15137
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)
yourdomain.org   text =

        "v=spf1 ip4:192.168.203.4 ~all"
yourdomain.org   AAAA IPv6 address = fdcc:12e5:12e5:cb:3c2e:de4c:9d70:25b5
yourdomain.org   AAAA IPv6 address = fdcc:12e5:12e5:cb::2
mail.yourdomain.org      internet address = 192.168.203.4
bert.yourdomain.org      internet address = 192.168.203.222
bert.yourdomain.org      AAAA IPv6 address = fdcc:12e5:12e5:cb:3c2e:de4c:9d70:25b5
bert.yourdomain.org      AAAA IPv6 address = fdcc:12e5:12e5:cb::2
>

I can provide the standard dcdiag output if you would like, but here's the /test:dns output, just a snippet (its long). All tests pass on a standard dcdiag. But with test:dns, it runs through all IP's on the network, and doesn't even show a test for the actual DC's, and of course they all fail.

    C:\Windows\system32>dcdiag /test:dns

Directory Server Diagnosis

Performing initial setup:
   Trying to find home server...
   Home Server = BERT
   * Identified AD Forest.
   Done gathering initial info.

Doing initial required tests

   Testing server: Default-First-Site-Name\BERT
      Starting test: Connectivity
         ......................... BERT passed test Connectivity

Doing primary tests

   Testing server: Default-First-Site-Name\BERT

      Starting test: DNS

         DNS Tests are running and not hung. Please wait a few minutes...
         ......................... BERT passed test DNS

   Running partition tests on : ForestDnsZones

   Running partition tests on : DomainDnsZones

   Running partition tests on : Schema

   Running partition tests on : Configuration

   Running partition tests on : yourdomain

   Running enterprise tests on : yourdomain.org
      Starting test: DNS
         Summary of test results for DNS servers used by the above domain controllers:

            DNS server: 192.168.203.100 (yourdomain.org.)
               1 test failure on this DNS server

            DNS server: 192.168.203.101 (yourdomain.org.)
               1 test failure on this DNS server

            DNS server: 192.168.203.103 (yourdomain.org.)
               1 test failure on this DNS server

            DNS server: 192.168.203.16 (yourdomain.org.)
               1 test failure on this DNS server
               PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.168.203.16
            DNS server: 192.168.203.19 (yourdomain.org.)
               1 test failure on this DNS server
               PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.168.203.19
            DNS server: 192.168.203.20 (yourdomain.org.)
               1 test failure on this DNS server
10
  • Out of curiosity, why do you have an SPF record in your AD DNS zone?
    – joeqwerty
    Commented Jul 22, 2015 at 20:15
  • As for the PTR record failure, Windows DNS servers create the following zones by default so as to prevent recursive queries for these zones should a DNS client query these zones. AFAIK, there's no real harm if they don't exist other than the potential for your DNS server attempting to recursively query these zones should a client request it. That being said, if these zones don't exist you should look at creating them: 0.in-addr.arpa. - 127.in-addr.arpa. - 255.in-addr.arpa
    – joeqwerty
    Commented Jul 22, 2015 at 20:21
  • Good question on the SPF. That's a left over from way back. Its not harming anything internally, but I'll remove it. For the reverse zones, I've never added them on my client networks, never had an issue without them. But I suppose, if it helps, I'll just add them. Thanks for the input! Commented Jul 22, 2015 at 20:48
  • The creation of those zones can be disabled in the registry. Maybe the previous person(s) did that for some reason. - technet.microsoft.com/en-us/library/cc940772.aspx
    – joeqwerty
    Commented Jul 22, 2015 at 20:55
  • Is there something running on 192.168.203.0? Commented Jul 22, 2015 at 21:58

0

You must log in to answer this question.