nslookup and ddns registration failures

  • Thread starter Thread starter DLBrum
  • Start date Start date
D

DLBrum

AD integrated dns difficulties: nslookup can't find the
domain, and dynamic dns registrations fail from clients.

Join domain works, dns name resolution works. All clients
point to this DNS server, very small one domain forest.

All of the tips in KB 317590 and 287156 have been checked.
DHCP client service running on server and clients, but all
machines have static IP addresses. Register client (IP
propery) and dynamic DNS server (allow registration yes)
check boxes checked.

Net logons work, everything else seems fine.

Member win2k3 server has a lengthy event log message that
says that security reasons prohibit the PTR updates, and
that I should see the sysadmin (that's me, of course).
This client evt log msg talks about inability to negotiate
credentials, or that the computer may not have perms to
register and update the specific DNS name for this adapter.

Only thing perhaps unusual about this setup is that I've
applied the ADPREP from win2k3 to this forest and domain
in preparation for bringing on a win2k3 DC.

Any thoughts would be appreciated.

dave
UF Gators !
 
What errors do you receive that makes you think registration fails? Are
you logging netlogon errors in the system log? When you say nslookup can't
find the domain, what test are you doing and what exactly is returned? You
might try running netdiag.exe from the support tools as it will ID which of
the DNS records there are problems with.

J.C. Hornbeck

This posting is provided "AS IS" with no warranties, and confers no rights.
 
the command ipconfig /registerdns results in the following
event log entry from LSASRV category SPNEGO (negotiator):

the security system conld not establish a secured
connection with the server DNS/net.health.ufl.edu.

My client is pointed to my internal DNS server named
ums.mgm.ufl.edu, and the domain is mgm.ufl.edu (as far as
AD is concerned, but not the rest of the world). So, it
sounds as though MY dns server is sending this client to
register with net.health.ufl.edu. THat's a unix box and
not the least interested in my ddns natterings. The
net.health box has my MX records, so that DNS is really
the authoritative one, not my little departmental guy.

NSLOOKUP returns: (from the XP client)
*** Can't find server name for address 159.178.xxx.xxx :
non-existent domain.

So, it looks like my little band of AD clients and servers
in what I named mgm.ufl.edu aren't able to update the
internal DNS server, even though it seems to have all the
right stuff (SOA, NS and host records).

It's not a single-lable AD, I named it mgm.ufl.edu But, in
real life, my internal DNS isn't really authoritative to
the outside. I just want him updated with my ad clients.

?
 
AS for the errors (are these your Event ID #'s you are receiving?):
Event IDs 40960 and 40961 in the System Event Log When You Restart Windows
Server 2003 After You Run Dcpromo.exe
http://support.microsoft.com/?id=823712

LSASRV Event IDs 40960 and 40961 When You Promote a Server to a Domain
Controller Role
http://support.microsoft.com/?id=824217


Some other stuff I found about this (may not apply to you):
http://lists.jammed.com/incidents/2002/09/0054.html
http://www.jsifaq.com/SUBO/tip7000/rh7089.htm


As for nslookup, nslookup is just trying to do you a favor by giving you the
name of your DNS server that you are using (that it winds up using) that is
in your IP properties. If there is no reverse zone for your IP range or
there is no PTR in the reverese zone for the DNS IP, then you get that
error, but nslookup still works on subsequent command entries once past
that. You can either create the zone or the PTR entry or just ignore the
error.

As for registration of your domain name, that's dictated by a ferw things:
Primary DNS Suffix of the DC must be set to the AD DNS Domain name and
spelled the exact same name as the zone name in DNS with updates set to at
least YES in it's properties.

You can also check the search suffix set. You can view it by doing an
ipconfig /all (which also shows the Primary DNS Suffix). That can be
fixed/adjusted in IP properties, Advanced, DNS Tab.

So there must be some relation going on, such as a delegation from the Unix
server to your server that is causing this behavior or you have a secondary
zone of the zone on the Unix box. I would eradicate the delagation and/or if
a secondary, make it a Primary or AD Integrated zone.

I would also set a forwarder to your Unix server. It won't forward any name
your departmental DNS server is authorative for (names that it hosts).

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
In
DLBrum said:
AD integrated dns difficulties: nslookup can't find the
domain, and dynamic dns registrations fail from clients.

Join domain works, dns name resolution works. All clients
point to this DNS server, very small one domain forest.

All of the tips in KB 317590 and 287156 have been checked.
DHCP client service running on server and clients, but all
machines have static IP addresses. Register client (IP
propery) and dynamic DNS server (allow registration yes)
check boxes checked.

Net logons work, everything else seems fine.

Member win2k3 server has a lengthy event log message that
says that security reasons prohibit the PTR updates, and
that I should see the sysadmin (that's me, of course).
This client evt log msg talks about inability to negotiate
credentials, or that the computer may not have perms to
register and update the specific DNS name for this adapter.

Only thing perhaps unusual about this setup is that I've
applied the ADPREP from win2k3 to this forest and domain
in preparation for bringing on a win2k3 DC.

Any thoughts would be appreciated.

dave
UF Gators !
Click to expand...

Check the security tab of your AD Zone that Domain Computers have proper
rights to read, create and delete child objects.
 
Thanks for the info. It seems as though the SPNEGO errors
I'm getting on my XP clients when I try to do
ipconfig /registerdns means that the local AD-integrated
DNS server, to which all the clients point, is not
returning it's own address for use in the registration
process with the client. It is set to "yes", and the
clients are set to "register this...in dns" It seems as
though the ad-dns is telling the client to go register
with the "real" (campus authoritative) dns.

My scenario is that my AD domain is not really
authoritative to any outside query: all of my "real" fqdn
mappings are done by the campus unix dns box (who owns
UFL.EDU). That is, the servers are registered in campus
DNS, but not the clients. I guess I'm cheating: but it
works since nobody needs to find my individual client
machines. I'm just tying up loose ends before promoting a
win2k3 member server to DC, and trying to understand why
the dynamic registration doesn't go: in case that would
cause DCPROMO to fail...
 
I'm going to make a wild stab at this one: since I don't
have a "." root in the forward zones, that means that the
dns is smart enough to know that it's a forwarder (even if
I'm not). So, it's telling clients to go to the "real"
authoritative DNS for registration, and not registering
them himself.

So, if he won't register clients himself, then they are
only registered when they join the domain with a static IP
address, and I could / should UNCHECK the register ddns
box for clients, since it won't work anyway for my
purpose.

I suppose that ddns registration is only important,
really, if you're using DHCP and variable addresses.

Thanks,
dave
 
In
dlbrum said:
I'm going to make a wild stab at this one: since I don't
have a "." root in the forward zones, that means that the
dns is smart enough to know that it's a forwarder (even if
I'm not). So, it's telling clients to go to the "real"
authoritative DNS for registration, and not registering
them himself.

So, if he won't register clients himself, then they are
only registered when they join the domain with a static IP
address, and I could / should UNCHECK the register ddns
box for clients, since it won't work anyway for my
purpose.

I suppose that ddns registration is only important,
really, if you're using DHCP and variable addresses.

Thanks,
dave
Click to expand...
Dave,

If your server is hosting a secondary zone of ufl.edu and the Master is the
Unix server, _OR_ the client machines are using the Unix server in their
IP properties, then the registration _WILL_ be sent to the Unix servers.
Otherwise, it wouldn't even know of the other server. Make sense?

Forwarders are configured under the forwarding tab under DNS properties.
Smart enough? Not exactly. However, it will use Root Hints if no forwarder
is configured. Forwarders are normally used for efficient non-authorative
queries (zones that your DNS does not have on it, such as Internet names).

If your clients and DCs are pointing ONLY to your MS DNS, and your MS DNS
hosts either a Primary or AD Integrated zone of your AD domain name (not a
secondary), then YOUR server will register the names. It doesn't matter if
ufl.edu is your AD name and the campus' name. They are, in this scenario,
two completely separate namespaces since they exist on different servers. If
you make the zone on your server a secondary zone, then obviously it looks
at the MNAME (the master name) and sends it to the Master server, which
apparently seems to be what's happening.

Provided that you follow AD;s requirements of pointing it to it's own DNS
server, as I mentioned above, then If you want to resolve campus names and
your server hosts the ufl.edu name, you'll have to make manual entries for
those records in your DNS server under your ufl.edu zone name.

Registration factors:
1. Point all DCs and clients to your own DNS ONLY (no ISP, or any others).
2. In your case, make the zone AD Integrated or Primary. Not a secondary of
your campus Unix BIND servers.
3. Make sure the client's and DC's Primary DNS Suffix is set to ufl.edu. The
netlogon service uses that name to find that same exact zone name's spelling
in DNS to register into as long as updates are allowed.
4. Make sure that AD's DNS Domain name is also ufl.edu.

If the above is followed, then it should just WORK out of the box. Any other
factors may complicate or will change this default behavior.

Hope that helps.

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
I've followed your post, and all is the way you suggest
should work except: the campus unix box does UFL.EDU,
and my AD integrated DNS, as well as the AD itself, is
concerned with/ named mgm.ufl.edu.

DNS shows SOA as ums.mgm.ufl.edu and it's correct address

Machines join mgm.ufl.edu domain and entries appear in DNS
on ums.mgm.ufl.edu

Clients point to the correct address for ums.mgm.ufl.edu
as do servers.

My client does not have the University unix box in it's
client ip config setup as a DNS server. But, when I run
ipconfig /registerdns, it tries to register with the U.
authoritative Unix box and do not register with
ums.mgm.ufl.edu (my integrated AD dns machine).

My server is forwarding registration requests of clients
upstream to the server that has my mgm.ufl.edu MX records,
and has the entries that the rest of the world uses to
find www.mgm.ufl.edu, and ums.mgm.ufl.edu.

Still wondering.

sigh..
dave
 
In
dlbrum said:
I've followed your post, and all is the way you suggest
should work except: the campus unix box does UFL.EDU,
and my AD integrated DNS, as well as the AD itself, is
concerned with/ named mgm.ufl.edu.

DNS shows SOA as ums.mgm.ufl.edu and it's correct address

Machines join mgm.ufl.edu domain and entries appear in DNS
on ums.mgm.ufl.edu

Clients point to the correct address for ums.mgm.ufl.edu
as do servers.

My client does not have the University unix box in it's
client ip config setup as a DNS server. But, when I run
ipconfig /registerdns, it tries to register with the U.
authoritative Unix box and do not register with
ums.mgm.ufl.edu (my integrated AD dns machine).

My server is forwarding registration requests of clients
upstream to the server that has my mgm.ufl.edu MX records,
and has the entries that the rest of the world uses to
find www.mgm.ufl.edu, and ums.mgm.ufl.edu.
Click to expand...

Do you have the correct primary and connection specific DNS suffixes? Should
be mgm.ufl.edu.
The DNS suffix must match the name of the zone it is supposed to register
in, if the suffix is not correct it will try to register in the zone name
that matches the suffix, even if it not pointing directly to the DNS the
zone belongs to.

An ipconfig /all will verify this.
 
Do you have the correct primary and connection specific DNS suffixes?
Should
be mgm.ufl.edu.
The DNS suffix must match the name of the zone it is supposed to register
in, if the suffix is not correct it will try to register in the zone name
that matches the suffix, even if it not pointing directly to the DNS the
zone belongs to.

An ipconfig /all will verify this.
Click to expand...


I was just going to say that. Primary DNS Suffix is the culprit. That's what
netlogon uses to register.
Yes, please let's see an ipconfig /all.

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
OK, here's the pasted ipconfig:

The address 128.227.128.24 (second search) is -not- the
machine that my client tries to do ddns with. The machine
that is authoritative for this subnet has a different IP
address, and that's not it. The registration target is a
unix box that has the registration for ums.mgm.ufl.edu, at
address .82, and our MX mail target, at address .80
(www.mgm.ufl.edu).....

Windows IP Configuration
Host Name . . . . . . . . . . . . : R2252MGM-DLBRUM

Primary Dns Suffix . . . . . . . : mgm.ufl.edu

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : mgm.ufl.edu

ufl.edu



Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : CNet PRO200WL
PCI Fast Ethernet Adapter

Physical Address. . . . . . . . . : 00-80-AD-75-35-
0A

Dhcp Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 159.178.62.84

Subnet Mask . . . . . . . . . . . : 255.255.254.0

Default Gateway . . . . . . . . . : 159.178.62.1

DNS Servers . . . . . . . . . . . : 159.178.62.82

128.227.128.24

NetBIOS over Tcpip. . . . . . . . : Disabled
 
In
dlbrum said:
OK, here's the pasted ipconfig:

The address 128.227.128.24 (second search) is -not- the
machine that my client tries to do ddns with. The machine
that is authoritative for this subnet has a different IP
address, and that's not it. The registration target is a
unix box that has the registration for ums.mgm.ufl.edu, at
address .82, and our MX mail target, at address .80
(www.mgm.ufl.edu).....

Windows IP Configuration
Host Name . . . . . . . . . . . . : R2252MGM-DLBRUM

Primary Dns Suffix . . . . . . . : mgm.ufl.edu

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : mgm.ufl.edu

ufl.edu



Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : CNet PRO200WL
PCI Fast Ethernet Adapter

Physical Address. . . . . . . . . : 00-80-AD-75-35-
0A

Dhcp Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 159.178.62.84

Subnet Mask . . . . . . . . . . . : 255.255.254.0

Default Gateway . . . . . . . . . : 159.178.62.1

DNS Servers . . . . . . . . . . . : 159.178.62.82

128.227.128.24
Click to expand...

You stated that the 159.178.62.82 is the machine that is authoritative for
mgm.ufl.edu, correct?
Does that DNS server accept Dynamic Registrations?
Does the mgm.ufl.edu FLZ on that DNS server have these AD subzones?
_msdcs
_sites
_tcp
_udp
These are the subzones that AD uses to locate Domain Controllers and global
catalog servers and is why you should only use your DC for the AD DNS.
I'll tell you the best fix for this have those subzones delegated back to
your DC then create an AD integrated FLZ for mgm.ufl.edu on your DC set it
to allow dynamic updates. After this is done it should work fine and the
University's DNS will not have to allow dynamic updates.

Remember my statement:
the zone name that matches the suffix, even if it is not pointing
directly to the DNS the zone belongs to.
Click to expand...
When this machine tries to register is addresses it will try to do it in all
DNS servers, I will bet that when this machine is registering in the
128.227.62.24 that DNS server is sending the request to the offended DNS you
are refering to. It is not necessary to have an alternate DNS server listed.
All DNS servers listed must accept DDNS.

I think the 128.227.128.24 DNS is the culprit here, remove that address and
put it in your DNS as a forwarder. Also in order to force your DNS to use
only this server instead of trying to use root hints, IMO You should check
the box "Do not use recursion" on the forwarder tab.
 
I've removed the "alternate" dns campus entry from the
client setup, but am still getting the same behavior.

I do see that IPCONFIG still has UFL.EDU as the second dns
search list entry, even though there's only the internal
DNS on the front and DNS pages of IP config.

I'll put replies inline below, marked by ???

(it's awfully nice of you to hang with me....!)

-----Original Message-----
In

You stated that the 159.178.62.82 is the machine that is authoritative for
mgm.ufl.edu, correct?
Click to expand...


??? If, by that you mean there is an SOA entry in this
machines DNS config, then yes. As far as the rest of the
world is concerned, NO. The machine to which my client is
trying to register is likely the internet authoritative
guy for my machines. The only "real (fqdn)" dns entries
that are visible to the internet are host and mx records
in the campus dns system that point to .81 (my mail
server), .80 (my www and smtp forwarder), and .82 (ad-dns,
fsmo master, etc.). ???


Does that DNS server accept Dynamic Registrations?
Click to expand...

???? set to yes
Does the mgm.ufl.edu FLZ on that DNS server have these AD subzones?
_msdcs
_sites
_tcp
_udp
These are the subzones that AD uses to locate Domain Controllers and global
catalog servers and is why you should only use your DC
Click to expand...
for the AD DNS.

???? yes, these are present. The AD dns works fine, users
find servers, machines can join the domain, and then they
appear.
????
 
In
dlbrum said:
I've removed the "alternate" dns campus entry from the
client setup, but am still getting the same behavior.

I do see that IPCONFIG still has UFL.EDU as the second dns
search list entry, even though there's only the internal
DNS on the front and DNS pages of IP config.

I'll put replies inline below, marked by ???

(it's awfully nice of you to hang with me....!)




??? If, by that you mean there is an SOA entry in this
machines DNS config, then yes. As far as the rest of the
world is concerned, NO. The machine to which my client is
trying to register is likely the internet authoritative
guy for my machines. The only "real (fqdn)" dns entries
that are visible to the internet are host and mx records
in the campus dns system that point to .81 (my mail
server), .80 (my www and smtp forwarder), and .82 (ad-dns,
fsmo master, etc.). ???




???? set to yes


???? yes, these are present. The AD dns works fine, users
find servers, machines can join the domain, and then they
appear.
????
Click to expand...
Hmm,
I went back thruogh this thread and reread the posts to make sure I'm on the
right track, now I'm unsure if I am :-)

Is it only the PTRs that are failing?

Please excuse my brain lapse.
 
I'm just trying to understand why the process of ddns
doesn't go. PTR records are not generated in my dns,
although everything else works fine. My concern, other
than curiosity, is that I ran this ddns attempt on a
member server that I want to make into a DC (it's a win2k3
machine) just to make sure that all was well, and this
little whatever it is worried me.

So, yes, it's just PTR creation, and the event log error
message about authentication with the campus (Real)
authoritative DNS server that's concerning me, when trying
to do ipconfig /registerdns. The client interactions with
dns and AD seem fine otherwise. The UNIX box doesn't know
anything about my little AD-integrated dns, and could care
less no doubt.

Not life/death, just trying to understand...

dave
 
In
dlbrum said:
I'm just trying to understand why the process of ddns
doesn't go. PTR records are not generated in my dns,
although everything else works fine. My concern, other
than curiosity, is that I ran this ddns attempt on a
member server that I want to make into a DC (it's a win2k3
machine) just to make sure that all was well, and this
little whatever it is worried me.

So, yes, it's just PTR creation, and the event log error
message about authentication with the campus (Real)
authoritative DNS server that's concerning me, when trying
to do ipconfig /registerdns. The client interactions with
dns and AD seem fine otherwise. The UNIX box doesn't know
anything about my little AD-integrated dns, and could care
less no doubt.

Not life/death, just trying to understand...

dave
Click to expand...
Then obviously, I was on the wrong track, sorry about that, in that case
then the reverse lookup zones on the DNS servers are not accepting dynamic
updates.
To be honest about it though, reverse lookups zones and PTRs are not
relevant unless it is a mail server looking for it. I'm also going to assume
it is a private IP it is trying to register even more irrelevant because if
a mail server did find it it would be useless because it would not be
routable. Besides, internal mail servers would not need a reverse lookup
from another internal mail server, you would just configure it to accept
mail from other internal mail servers without doing the reverse lookup.
Sound reasonable?
 
Just want to add, as long as that 128.227.128.24 server is removed from the
configuration and only points to your own 159.178.62.82 and dynamic updates
are allowed on the mgm.ufl.edu zone and on the reverse zone, then it should
just work. Now if the mgm.ufl.edu zone on is a secondary of the mgm.ufl.edu
zone on 128.227.128.24, then I can understand why it's still trying to reg
into that zone.

Is it a secondary? Then I can see why it's trying to still register into the
128.227.128.24 machine.

If the reverse zone is not of the correct subnet as the machine, then it
won't register.

The Search Suffixes won't have anything to do with registration, that's just
for search suffixing a single name ping, etc.

Did you remove that 128.227.128.24 from your client machines as well? ALL
your machines in AD should ONLY point to the 159.178.62.82 server. You can
forward to the 128.227.128.24 server if you like or just forward to the
ISP's DNS, since your machine will NOT forward a query to a zone that it is
authorative for (that means for any zones that exist on that machine). It
will just forward queries for zone that it doesn't have.


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
Yes, I removed all but the AD dns from the client config.

I think that the key is, my AD-integ DNS isn't really a
primary or secondary or whatnot. The rest of the world
can only find my servers because I registered those three
fqdns with the campus DNS box: and that box is the one
that clients are trying to register with (so do the
servers, by the way).

My little AD is just a little island of it own, not really
authoritative as far as the real DNS world is concerned.
It's just an internal dns, and registrations are being
forwarded. But it works fine to do AD chores internally.

I really do appreciate the insites !

dave
 
In
dlbrum said:
Yes, I removed all but the AD dns from the client config.

I think that the key is, my AD-integ DNS isn't really a
primary or secondary or whatnot. The rest of the world
can only find my servers because I registered those three
fqdns with the campus DNS box: and that box is the one
that clients are trying to register with (so do the
servers, by the way).
Click to expand...

Sounds like a delegation from the campus server to yours. Your server has
the nameservers of the parent. I would remove the registration from the
campus server and out of the nameservers tab from your servers. You want to
keep this totally private, even if you're part of the campus. AD functions
properly is an end result.
My little AD is just a little island of it own, not really
authoritative as far as the real DNS world is concerned.
It's just an internal dns, and registrations are being
forwarded. But it works fine to do AD chores internally.

I really do appreciate the insites !

dave
Click to expand...

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

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