Infamous GUID & DNS RR set that ought to exist

  • Thread starter Thread starter Chris Largent
  • Start date Start date
C

Chris Largent

I've been all over the newsgroups and the Microsoft knowledgebase
researching this for days. There are many hits on GUID and DNS, but nothing
has helped with my scenario. I give up and plead for help!

Source: NETLOGON
Event ID: 5774
Description: Registration of the DNS record {DC
GUID}._msdcs.<zone/ActiveDirectory name>. 600 in CNAME <domain address>
failed with the following error: DNS RR set that ought to exist, does not
exist.

I have two W2K Domain Controllers, with one running a W2K Active
Directory-integrated DNS. The above error is occuring on the Domain
Controller that's NOT running the DNS (aka "non-DNS DC").

Key considerations:
- This is a non-public, internal DNS serving a typical "10-dot" network.
- Everything in our Active Directory domain SEEMS to be working 100%. All
domain services SEEM to be running like a charm, including the Exchange 2000
Server that is running on the non-DNS DC.
- This is the only relevant error showing up in the log on the non-DNS DC.
- I have allowed zone transfers to the non-DNS DC by virtue of explicitly
allowing its IP address in the DNS zone. (I did this so 'LS -A' would work
for NSLOOKUP on the non-DNS DC.)
- On the non-DNS DC, NSLOOKUP starts up as expected (normal), sees the
default DNS just fine (reverse lookup working just fine), & resolves the
above"GUID" domain name just fine.
- If I manually delete the "GUID" record from the DNS zone, then stop &
start the Netlogon service on the non-DNS DC, the GUID record is positively
registered in the DNS zone successfully, BUT the error is STILL logged!
- If I reboot the non-DNS DC, the error is NOT immediately logged. The last
time I rebooted, it took about 20 minutes before the error was logged!
- After the error is logged for the first time, it continues being logged
about every two hours.

This is crazy behavior and I'm stumped!
 
In
Chris Largent said:
I've been all over the newsgroups and the Microsoft knowledgebase
researching this for days. There are many hits on GUID and DNS, but
nothing has helped with my scenario. I give up and plead for help!

Source: NETLOGON
Event ID: 5774
Description: Registration of the DNS record {DC
GUID}._msdcs.<zone/ActiveDirectory name>. 600 in CNAME <domain
address> failed with the following error: DNS RR set that ought to
exist, does not exist.

I have two W2K Domain Controllers, with one running a W2K Active
Directory-integrated DNS. The above error is occuring on the Domain
Controller that's NOT running the DNS (aka "non-DNS DC").

Key considerations:
- This is a non-public, internal DNS serving a typical "10-dot"
network.
- Everything in our Active Directory domain SEEMS to be working 100%.
All domain services SEEM to be running like a charm, including the
Exchange 2000 Server that is running on the non-DNS DC.
- This is the only relevant error showing up in the log on the
non-DNS DC.
- I have allowed zone transfers to the non-DNS DC by virtue of
explicitly allowing its IP address in the DNS zone. (I did this so
'LS -A' would work for NSLOOKUP on the non-DNS DC.)
- On the non-DNS DC, NSLOOKUP starts up as expected (normal), sees the
default DNS just fine (reverse lookup working just fine), & resolves
the above"GUID" domain name just fine.
- If I manually delete the "GUID" record from the DNS zone, then stop
& start the Netlogon service on the non-DNS DC, the GUID record is
positively registered in the DNS zone successfully, BUT the error is
STILL logged! - If I reboot the non-DNS DC, the error is NOT
immediately logged. The last time I rebooted, it took about 20
minutes before the error was logged! - After the error is logged for
the first time, it continues being logged about every two hours.

This is crazy behavior and I'm stumped!
Click to expand...

More than likely, that comes down to the "infamous" use of your ISP's DNS
addresses in your IP properties. That error is common when this
configuration exists. It's due to AD requiring DNS, specifically it's own
DNS server so it can store all it;s info and records so others in the
domain, including itself, can "find" itself. Make sense? So when it asks DNS
"where's the LDAP service located on my domain?", it will respond with a
record, then it resolves that record and communication begins. If the ISP;'s
is in there, it will thwart this and cause *numerous* errors, too many to
list here, but yours is one of them.

Other errors that can cause this:
INcorrect spelling of or missing zone in DNS.
Zone in DNS is not set to Yes for updates.
Incorrect or missing Primary DNS Suffix

If you do have the ISP's addresses in your IP properties, (this goes for ALL
machines, clients, member servers and DCs), they should be removed and only
use your internal DNS so AD will function properly. To get Internet access,
use a Forwarder. If the option is grayed out, delete the Root zone. These
methods and how-tos are shown here:
http://support.microsoft.com/?id=300202

Here's a little FAQ on AD and DNS:
http://support.microsoft.com/?id=291382

Tell you what, if you can post an ipconfig /all, and state the actual domain
name of AD (the one that shows up in the ADUC), we can diagnose if there are
any other configuration problems for you.

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
 
This is why Ace has an MVP after his name! Ace, you are exactly correct and
this was the problem!

Yes, I had my ISP's DNS also listed in the IP configuration (lower priority
than my internal DNS, but listed nonetheless). Yep, this makes complete
sense now--my Domain Controller was attempting to register itself with ALL
those DNS, not just with my internal DNS. So the error was occuring when
the DC BEGAN the registration process against the ISP's DNS, which
apparently involves performing an assertion query before actually trying to
send an update to the DNS.

To resolve, I enabled forwarding on my internal DNS, and listed my ISP's DNS
there. I changed my DHCP server to no longer deal out the ISP's DNS; it now
only deals out my internal DNS. I removed my ISP's DNS from all static IP
configurations (servers).

Ace, while this makes sense, I'm still confused about one more thing. Only
the non-DNS DC was logging this error. Why didn't the other DC (running
DNS) log this error as well? It also had the ISP's DNS defined in its IP
configuration. Was this possibly a network latency/performance issue?

Thanks again!

Chris
 
It's not missing anymore, but it WAS missing on the non-DNS Domain
Controller. To fix it, I just filled in the 'DNS Suffix for this
connection' field with our domain name (via TCP/IP
Properties...Advanced...DNS.) Believe it or not, it's not a required field
when setting up a static IP configuration. I had simply forgotten to fill
in this field when I was configuring this new server.

....For the novice reader following this thread, the DNS suffix (e.g.,
"your-domain.com") is typically dealt out by a DHCP server in larger
networks. However, if you define your computer with a static IP
configuration (i.e., you disable the DHCP client...commonly done on
servers), then you need to manually define your DNS suffix when operating in
present day domains...

So my non-DNS DC still functioned, even with the screwed up configuration.
I guess this means that DCs don't rely solely on the DNS suffix to know what
domains they serve. In retrospect, I would have thought that the DCPROMO
process would have caught this configuration glitch, but it obviously
didn't.

So it was probably the combination of the two problems--ISP DNS & no DNS
suffix--that was ultimately causing the error to get logged on this one DC
only.
 
In
Chris Largent said:
It's not missing anymore, but it WAS missing on the non-DNS Domain
Controller. To fix it, I just filled in the 'DNS Suffix for this
connection' field with our domain name (via TCP/IP
Properties...Advanced...DNS.) Believe it or not, it's not a required
field when setting up a static IP configuration. I had simply
forgotten to fill in this field when I was configuring this new
server.

...For the novice reader following this thread, the DNS suffix (e.g.,
"your-domain.com") is typically dealt out by a DHCP server in larger
networks. However, if you define your computer with a static IP
configuration (i.e., you disable the DHCP client...commonly done on
servers), then you need to manually define your DNS suffix when
operating in present day domains...

So my non-DNS DC still functioned, even with the screwed up
configuration. I guess this means that DCs don't rely solely on the
DNS suffix to know what domains they serve. In retrospect, I would
have thought that the DCPROMO process would have caught this
configuration glitch, but it obviously didn't.

So it was probably the combination of the two problems--ISP DNS & no
DNS suffix--that was ultimately causing the error to get logged on
this one DC only.
Click to expand...


Actually the Primary DNS Suffix is configured in My Computer, Properties,
Network ID tab, properties, more. That can't be changed on a DC and requires
either registry changes or a script that I have to do it. What you did, if
my thoughts on this are correct, won't work.

Let me see an (unedited) ipconfig /all please. That shows what the Primary
DNS Suffix is. Also let me know that exact DNS domain name that AD believes
itself to be, as found in ADUC.

Thanks


--
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 would prefer not to post the IP configuration for security reasons.
However, this is enjoyable discussion, as it is forcing me to "peel back the
layers" and learn even more about this stuff!

I'm quite possibly wrong, but I believe we're talking about two different
things here (and this is what I'm learning more about on-the-fly!) I think
we're coming down to "Domain" versus "DNS Suffix". In a well-oiled
Microsoft network, yes, these typically are the same, but they don't HAVE to
be. You are correct that the "Network ID" configuration is where one
specifies the *Domain* that the computer (server) thinks it's in. Based on
this enlightenment, this must be why my DC was still working (i.e., still
generating the correct DNS 'SRV' records to register.)

However, I'm currently thinking that the Microsoft DC methods (code) rely on
the TCP/IP stack to determine which DNS server houses the zone that
corresponds to the Domain. Furthermore, I think the DC methods don't pass
the domain to the TCP/IP stack; the DC methods ASSUME that the TCP/IP stack
is configured correctly.

I know I could be wrong, but this really seems to explain the behavior I was
witnessing. I also did the following:

1) IPCONFIG/ALL. Note that the output specifically says,
"Connection-specific DNS Suffix".
2) I changed the static IP configuration so that the DNS suffix was now
"test.com".
3) IPCONFIG reflected the change. This means that the IP configuration
uses the DNS Suffix setting, and not the Domain setting.

Am I way off base here?
 
In
Chris Largent said:
I would prefer not to post the IP configuration for security reasons.
However, this is enjoyable discussion, as it is forcing me to "peel
back the layers" and learn even more about this stuff!

I'm quite possibly wrong, but I believe we're talking about two
different things here (and this is what I'm learning more about
on-the-fly!) I think we're coming down to "Domain" versus "DNS
Suffix". In a well-oiled Microsoft network, yes, these typically are
the same, but they don't HAVE to be. You are correct that the
"Network ID" configuration is where one specifies the *Domain* that
the computer (server) thinks it's in. Based on this enlightenment,
this must be why my DC was still working (i.e., still generating the
correct DNS 'SRV' records to register.)

However, I'm currently thinking that the Microsoft DC methods (code)
rely on the TCP/IP stack to determine which DNS server houses the
zone that corresponds to the Domain. Furthermore, I think the DC
methods don't pass the domain to the TCP/IP stack; the DC methods
ASSUME that the TCP/IP stack is configured correctly.
Click to expand...

Good assumption. Yes, it relies on the network subsystem to be configured
properly.
I know I could be wrong, but this really seems to explain the
behavior I was witnessing. I also did the following:

1) IPCONFIG/ALL. Note that the output specifically says,
"Connection-specific DNS Suffix".
Click to expand...

That is not specifically the Primary DNS Suffix, but rather what domain the
machine is supposedly sitting on. Usually it's the same as the Primary,
which is also default to be the Search Suffix (when you ping a single name,
it suffixes the Search Suffix). But the Primary needs to be straightened
out.
2) I changed the static IP configuration so that the DNS suffix was
now "test.com".
Click to expand...

The Primary DNS Suffix?
3) IPCONFIG reflected the change. This means that the IP
configuration uses the DNS Suffix setting, and not the Domain setting.

Am I way off base here?
Click to expand...

Well, close. The netlogon service uses the Primary DNS Suffix to know what
zone to register AD's services and their locations into in the form of SRV
record. It's highly important. I actually needed to see the ipconfig /all
output to determine if this script I have will fix it for you. IF AD is
correct in it's DNS domain name (such as domain.com and not simply "domain")
then it will work, if not, it won't.

It is fixable...


--
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 think we have some miscommunication Ace. Everything is working peachy
now...you're original suggestion to remove the ISP's DNS fixed the problem.
During this, I also noticed a missing 'Connection-specific DNS suffix' on
the one DC, and I fixed that as well. There is nothing to fix now. This
sub-thread is simply a continuation of my wondering why only one DC was
originally generating the error and not the other (i.e., past tense...back
when things weren't fixed.)

....

....Ahhh! I think I completely understand you now! (I have been overlooking
the top portion of the IPCONFIG/all output since it scrolls off the
screen...I have paid attention to it now!) No, my test only changed the
'Connection-specific DNS suffix'. It did not change the 'Primary DNS
suffix' (which is simply a reflection of the Domain.) As you have pointed
out, one cannot change the Primary DNS suffix of a Domain Controller.

I am now convinced that this is why only the one DC was generating the
error: (1) overall, because I had my ISP's DNS listed, and (2) because the
one DC was missing its Connection-specific DNS suffix.

Thanks again Ace for your excellent help!
 
In
Chris Largent said:
I think we have some miscommunication Ace. Everything is working
peachy now...you're original suggestion to remove the ISP's DNS fixed
the problem. During this, I also noticed a missing
'Connection-specific DNS suffix' on the one DC, and I fixed that as
well. There is nothing to fix now. This sub-thread is simply a
continuation of my wondering why only one DC was originally
generating the error and not the other (i.e., past tense...back when
things weren't fixed.)

...

...Ahhh! I think I completely understand you now! (I have been
overlooking the top portion of the IPCONFIG/all output since it
scrolls off the screen...I have paid attention to it now!) No, my
test only changed the 'Connection-specific DNS suffix'. It did not
change the 'Primary DNS suffix' (which is simply a reflection of the
Domain.) As you have pointed out, one cannot change the Primary DNS
suffix of a Domain Controller.

I am now convinced that this is why only the one DC was generating the
error: (1) overall, because I had my ISP's DNS listed, and (2)
because the one DC was missing its Connection-specific DNS suffix.

Thanks again Ace for your excellent help!
Click to expand...

No problem Chris. Glad things are working.

btw- The Primary DNS Suffix CAN be changed. I have a script that will do it.
Keep that in mind for future problems, if you ever have any more and it
deals with it.

Cheers and enjoy your weekend!


--
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