Client Addresses returned from NSLOOKUP on domain name

  • Thread starter Thread starter Mick
  • Start date Start date
M

Mick

Hi,

W2K, two DCs SP3/SP4 (going 2003 real soon).

If I do an NSLOOKUP of mydomain.com I get a whole heap of work station IPs
returned as well as my two DNS servers. When I look in DNS Console, Forward
Lookup Zones, MyDomain.com I see lots of

(same as parent folder) host workstationIP1
(same as parent folder) host workstationIP2
..... about 10 more
(same as parent folder) Name Server DC1.mydomain.com
(same as parent folder) Name Server DC2.mydomain.com
(same as parent folder) Start of Authority ...
(same as parent folder) WINS Lookup DC1_IP
then all the hosts / folders etc

My question is, why all these workstations IPs as (same as parent folder)
hosts ? How did they get there, can I get rid of them.

I got onto this as I was trying to work out why on my Ex2K server I get the
following logged every few hours

Windows cannot determine the user or computer name. Return value (1326).

Thanks in advance.
 
--
Herb Martin


Mick said:
W2K, two DCs SP3/SP4 (going 2003 real soon).

If I do an NSLOOKUP of mydomain.com I get a whole heap of work station IPs
returned as well as my two DNS servers. When I look in DNS Console, Forward
Lookup Zones, MyDomain.com I see lots of

(same as parent folder) host workstationIP1
(same as parent folder) host workstationIP2
.... about 10 more
(same as parent folder) Name Server DC1.mydomain.com
(same as parent folder) Name Server DC2.mydomain.com
(same as parent folder) Start of Authority ...
(same as parent folder) WINS Lookup DC1_IP
then all the hosts / folders etc

My question is, why all these workstations IPs as (same as parent folder)
hosts ? How did they get there, can I get rid of them.

Because if you zone is mydomain.com, those are records that
point to that same name (same as parent ZONE might make more
sense.

For instance, those DNS Server records are declaring DC1 and DC2
as Nameservers for mydomain.com (same as parent)
I got onto this as I was trying to work out why on my Ex2K server I get the
following logged every few hours

Windows cannot determine the user or computer name. Return value (1326).

This is entirely separate from the nslookup above.
 
In
Mick said:
Hi,

W2K, two DCs SP3/SP4 (going 2003 real soon).

If I do an NSLOOKUP of mydomain.com I get a whole heap of work
station IPs returned as well as my two DNS servers. When I look in
DNS Console, Forward Lookup Zones, MyDomain.com I see lots of

(same as parent folder) host workstationIP1
(same as parent folder) host workstationIP2
.... about 10 more
(same as parent folder) Name Server DC1.mydomain.com
(same as parent folder) Name Server DC2.mydomain.com
(same as parent folder) Start of Authority ...
(same as parent folder) WINS Lookup DC1_IP
then all the hosts / folders etc

My question is, why all these workstations IPs as (same as parent
folder) hosts ? How did they get there, can I get rid of them.

I got onto this as I was trying to work out why on my Ex2K server I
get the following logged every few hours

Windows cannot determine the user or computer name. Return value
(1326).

Are you getting the (same as parent folder) A records for the Domain
Controller IP?

If you delete the (same as parent folder) records for the workstations do
they come back?

If they do, I have seen this only one time before and I cannot explain how
it started. But, if this is the same thing going on these records are
created by the Netlogon service. DCs are the only machines that should
create these records, but I found in the previous instance that the
Workstations (XP in the previous instance) were creating the LDAP records by
the Netlogon service.

*Behavior* (and I hope some one at Microsoft is listening)
The Netlogon service should not create records on workstations, I want you
to take a look at these Workstations and go to the
%systemroot%\system32\config directory and see if you find netlogon.dns and
netlogon.dnb files.
*Resolution*
If they (netlogon.dns and netlogon.dnb) are there on the Workstations
(non-DCs) they should not be, delete those records and run ipconfig
/flushdns. Then restart the netlogon service and run ipconfig registerdns,
then see if the netlogon.dns and netlogon.dnb are recreated (they should not
be).

It took about a week to narrow this down in the previous instance, deleting
these two files resolved the problem, but didn't give me a clue as to how
they got there in the first place. In fact, previously, the two clients (XP)
were also creating SRV records, too.

As I said, I cannot explain this and was unable to find what caused the
behavior in the first place as only DCs are supposed to have netlogon
registrations.
 
In
Are you getting the (same as parent folder) A records for the Domain
Controller IP?

If you delete the (same as parent folder) records for the
workstations do they come back?

If they do, I have seen this only one time before and I cannot
explain how it started. But, if this is the same thing going on these
records are created by the Netlogon service. DCs are the only
machines that should create these records, but I found in the
previous instance that the Workstations (XP in the previous instance)
were creating the LDAP records by the Netlogon service.

*Behavior* (and I hope some one at Microsoft is listening)
The Netlogon service should not create records on workstations, I
want you to take a look at these Workstations and go to the
%systemroot%\system32\config directory and see if you find
netlogon.dns and netlogon.dnb files.
*Resolution*
If they (netlogon.dns and netlogon.dnb) are there on the Workstations
(non-DCs) they should not be, delete those records and run ipconfig
/flushdns. Then restart the netlogon service and run ipconfig
registerdns, then see if the netlogon.dns and netlogon.dnb are
recreated (they should not be).

It took about a week to narrow this down in the previous instance,
deleting these two files resolved the problem, but didn't give me a
clue as to how they got there in the first place. In fact,
previously, the two clients (XP) were also creating SRV records, too.

As I said, I cannot explain this and was unable to find what caused
the behavior in the first place as only DCs are supposed to have
netlogon registrations.

Interesting that these appear:
The others are normal, but not these. I'm curious as to if there's any
significant app running on these machines?

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit. This posting is provided "AS-IS" with no warranties and
confers no rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
In Mick in <mick377_1[remove]@hotmail.com> posted their thoughts, then I
offered mine
I got onto this as I was trying to work out why on my Ex2K server I
get the following logged every few hours

Windows cannot determine the user or computer name. Return value
(1326).

Thanks in advance.

This can occur if you're not using only your internal DNS servers. Can you
confirm you don't have your ISP's DNS in your IP properties?

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit. This posting is provided "AS-IS" with no warranties and
confers no rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
In Ace Fekay [MVP] <PleaseSubstituteMyActualFirstName&[email protected]>
posted a question
Then Kevin replied below:
Interesting that these appear:

The others are normal, but not these. I'm curious as to if there's any
significant app running on these machines?

I don't know if you remember a month or so ago I talked to you about an XP
client that was not only registering the LDAP records but it was also
creating SRV records?

I didn't get back with you to tell you what I found, it turned out those XP
clients were making Netlogon registrations and both had netlogon.dns and
netlogon.dnb files deleting those files stopped the netlogon registrations.
 
In
I don't know if you remember a month or so ago I talked to you about
an XP client that was not only registering the LDAP records but it
was also creating SRV records?

I didn't get back with you to tell you what I found, it turned out
those XP clients were making Netlogon registrations and both had
netlogon.dns and netlogon.dnb files deleting those files stopped the
netlogon registrations.

Yes!! I do remember now. Interesting that was the case. Wonder why?


--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit. This posting is provided "AS-IS" with no warranties and
confers no rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
In Ace Fekay [MVP] <PleaseSubstituteMyActualFirstName&[email protected]>
posted a question
Then Kevin replied below:
In

Yes!! I do remember now. Interesting that was the case. Wonder why?

I've asked myself the same question a lot, I went over everything I could
think of with the user. We couldn't come up with one scenario that would
cause an XP client to make netlogon registrations.
These two XP clients were also registering LDAP records so I'm wondering if
the same thing is not going on in this situation.
 
In
Kevin D. Goodknecht Sr. [MVP] in said:
I've asked myself the same question a lot, I went over everything I
could think of with the user. We couldn't come up with one scenario
that would cause an XP client to make netlogon registrations.
These two XP clients were also registering LDAP records so I'm
wondering if the same thing is not going on in this situation.

Mick hasn't replied yet. Don't know if he's monitoring the responses, but if
he reads this, hope he can let us know if what you're saying applies in his
scenario.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit. This posting is provided "AS-IS" with no warranties and
confers no rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
Kevin,

Thanks for the reply, answers inline below

Are you getting the (same as parent folder) A records for the Domain
Controller IP?

Sorry, yes I am getting (same as parent folder) host for DC1IP and DC2IP.
If you delete the (same as parent folder) records for the workstations do
they come back?

I've never tried deleting as I only just discovered them. I have now
though.
If they do, I have seen this only one time before and I cannot explain how
it started. But, if this is the same thing going on these records are
created by the Netlogon service. DCs are the only machines that should
create these records, but I found in the previous instance that the
Workstations (XP in the previous instance) were creating the LDAP records by
the Netlogon service.

*Behavior* (and I hope some one at Microsoft is listening)
The Netlogon service should not create records on workstations, I want you
to take a look at these Workstations and go to the
%systemroot%\system32\config directory and see if you find netlogon.dns and
netlogon.dnb files.
*Resolution*
If they (netlogon.dns and netlogon.dnb) are there on the Workstations
(non-DCs) they should not be, delete those records and run ipconfig
/flushdns. Then restart the netlogon service and run ipconfig registerdns,
then see if the netlogon.dns and netlogon.dnb are recreated (they should not
be).

I looked on a few of the machines and the system32\config folder is empty.

When I look further I can see entries for the <workstationXYZ>.mydomain.com
in

mydomain.com\_msdcs\dc\_tcp
mydomain.com\_msdcs\<long hex string>_tcp

I've asked our desktop person to let me know if there is any extra software
on these PCs that might be causing the issue.
 
In
Mick said:
Sorry, yes I am getting (same as parent folder) host for DC1IP and
DC2IP.

These are the only same as parent folder A records you should have, they are
the LDAP records and also resolve the domain DFS share at
\\ said:
I've never tried deleting as I only just discovered them. I have now
though.


Delete them to see if they come back, I am sure this is the reason for the
userenv errors you are getting. It is when the domain name does not resolve
to IP addresses on your DCs with file sharing enabled you get these errors.
Your machines are looking for the DFS share at
\\ said:
I looked on a few of the machines and the system32\config folder is
empty.

When I look further I can see entries for the
<workstationXYZ>.mydomain.com in

mydomain.com\_msdcs\dc\_tcp
mydomain.com\_msdcs\<long hex string>_tcp

I've asked our desktop person to let me know if there is any extra
software on these PCs that might be causing the issue.

Try this command:
nslookup
set type=srv
_ldap._tcp.dc._msdcs.mydomain.com

post the results
 
A whole heap of workstation details, I presume it is safe to manually remove
these and see if they come back ?
set type=srv
_ldap._tcp.dc._msdcs.mydomain.com
Server: dc1.mydomain.com
Address: 172.17.100.115

_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = xdxt581s.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc2.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = x4frs31s.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = x04019-1.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = xx2096219p.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = x7gxg61s.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = xaub3494447.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = xdrxr31s.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = x517c71s.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = xh37c71s.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = x2yld71s.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = x627c71s.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = xaub3473336.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc1.mydomain.com
_ldap._tcp.dc._msdcs.mydomain.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = xy1068376j.mydomain.com
xdxt581s.mydomain.com internet address = 172.17.25.116
dc2.mydomain.com internet address = 172.17.100.112
x4frs31s.mydomain.com internet address = 172.17.23.128
x04019-1.mydomain.com internet address = 172.17.14.113
xx2096219p.mydomain.com internet address = 172.17.32.115
x7gxg61s.mydomain.com internet address = 172.17.22.141
xaub3494447.mydomain.com internet address = 172.17.31.178
xdrxr31s.mydomain.com internet address = 172.17.13.124
x517c71s.mydomain.com internet address = 172.17.33.148
xh37c71s.mydomain.com internet address = 172.17.23.110
x2yld71s.mydomain.com internet address = 172.17.32.170
x627c71s.mydomain.com internet address = 172.17.23.109
xaub3473336.mydomain.com internet address = 172.17.31.175
dc1.mydomain.com internet address = 172.17.100.115
xy1068376j.mydomain.com internet address = 172.17.33.139
 
In
Mick said:
A whole heap of workstation details, I presume it is safe to manually
remove these and see if they come back ?

Yes do that, the DCs should be the only machines making these registrations.
These are all netlogon registrations delete the records and restart the
netlogon service to see if they come back.
IF they do you may have a problem.

Go to one of the machines that are not DCs and do a file search for
netlogon.dns if they are re-registered.
This is the exact same behavior I had back in mid-May, I don't know what
caused it, but those machines (a desktop and a laptop) both had
netlogon.dns and netlogon.dnb files, deleting them stopped it and I have not
heard from her since.
I don't know of any applications except Active Directory that should
register these.

If you find these files rename them to netlogon.dns.txt and netlogon.dnb.txt
so you can see what records they contain, then restart the netlogon service.
If the Netlogon service re-creates those two records then we need to find
out what is going on and if it is right or wrong.

I'm assuming that the machines marked with a <--- are all workstations, what
OS?
 
The entries as yet have not come back. Thanks for confirming that they
shouldn't exist. Mystery is why they were created.
 
In
Mick said:
The entries as yet have not come back. Thanks for
confirming that they shouldn't exist. Mystery is why
they were created.

Did you delete the SRV records I pointed out?
There may also be other records created that shouldn't exist, you can delete
these, too. Don't worry about deleting records for your DCs, if you
accidentally delete your DCs SRV records, simply restart the netlogon
service on the DCs and run ipconfig /registerdns thay'll come right back.
 
Back
Top