Cannot resolve a DnsApi EventID-11163 to an unknown 10.1.1.1 DNS S

pbrill1

unread,

Jan 12, 2006, 2:06:05 PM1/12/06

to

Problem: I have received this error recently, and do not know how to resolve
it. The key part of the error message (slightly modified form shown below),
is that it is attempting to send information to a 10.1.1.1 DNS server that is
not on our network.

The DHCP server and DNS server have both been checked. The DNS server
points to itself, and the DHCP server entries contain the entries shown on
the DNS Server List below...none of which are 10.1.1.1.

I have not found anything in Technet or Microsoft ...or Google
searches....that seem to address the 11163 error sufficiently.

Any suggestions on how to resolve/remove this ghost 10.1.1.1 server that is
causing these errors would be appreciated.

--------------------------
Source: DnsApi
Category:None
Type:Warning
EventID: 11163

The system failed to register host (A) resource records (RRs) for network
adapter
with settings:

Adapter Name : {DXXXXXXC-8XXG-6XX7-5555-555555X555X5}
Host Name : CLIENT129
Primary Domain Suffix : company.net
DNS server list :
10.0.0.21, 206.141.192.60, 65.43.19.26
Sent update to server : 10.1.1.1
IP Address(es) :
10.0.0.105

The reason the system could not register these RRs was because the DNS
server failed the update request. The most likely cause of this is that the
authoritative DNS server required to process this update request has a lock
in place on the zone, probably because a zone transfer is in progress.

You can manually retry DNS registration of the network adapter and its
settings by typing "ipconfig /registerdns" at the command prompt. If problems
still persist, contact your DNS server or network systems administrator.

--
pbrill1

Kevin D. Goodknecht Sr. [MVP]

unread,

Jan 12, 2006, 9:27:03 PM1/12/06

to

Assuming this is a member of an Active Directory domain and 206.141.192.60 &
65.43.19.26 are your ISP's DNS, you need to remove your ISP's DNS from
TCP/IP properties. Do not use an ISP or other external DNS on any member of
an AD domain.

Run netdiag /test:dns /v in a command prompt and post the results, Netdiag
is on the installation CD for the OS you are using starting with Win2k.
Win2k won't work on XP or Win2k3 or vice-versa, use the version for the OS
you are using.

--
Best regards,
Kevin D. Goodknecht Sr. [MVP]
Hope This Helps
===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
http://support.wftx.us/
https://secure.lsaol.com/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oehelp.com/OEBackup/Default.aspx
===================================

Neobyte

unread,

Jan 13, 2006, 4:22:35 AM1/13/06

to

Just to let you know that I am trying to resolve the exact same
problem. I have a:

A.B.x.x subnet environment, and my clients for some reasons are sending
their updates (and failing, obviously) to:

A.1.1.1

This is configured nowhere on my network and is driving me up the wall!
Any help greatly appreciated.

pbrill1

unread,

Jan 13, 2006, 6:43:57 PM1/13/06

to

Kevin,

Thank you for the reply. I have a few more questions on both items that you
mentioned, though.
1) It makes sense (at least for security) to eliminate the external DNS
servers for AD users. These external DNS servers ARE required entries for
our INTERNAL DNS servers, though (right?). Is there a best procedure on how
to link internal DNS servers to our external DNS (ISP) servers?

2) I tried loading the netdiag on an XP machine that has the error that I
sent originally, and upon running netdiag /test:dns /v at the command line,
I get the following error:

"The procedure entry point DnsNetworkInformation_CreateFromFAZ could not be
located in the dynamic link library DNSAPI.dll"

I do have a DNSAPI.dll file on the hard drive, but am unsure on how (or if)
to check the contents of the DLL file.

Further suggestions would be greatly appreciated.

--
pbrill1

Kevin D. Goodknecht Sr. [MVP]

unread,

Jan 13, 2006, 8:43:12 PM1/13/06

to

pbrill1 <pbr...@discussions.microsoft.com> wrote:
> Kevin,
>
> Thank you for the reply. I have a few more questions on both items
> that you mentioned, though.
> 1) It makes sense (at least for security) to eliminate the external
> DNS servers for AD users. These external DNS servers ARE required
> entries for our INTERNAL DNS servers, though (right?). Is there a
> best procedure on how to link internal DNS servers to our external
> DNS (ISP) servers?

Only as forwarders, never in TCP/IP properties, it is not so much as a
security issue, as it is a functionality issue. Active Directory stores it
service location records in DNS, AD members look in DNS for these records.
If you have your ISP's DNS in TCP/IP properties, then the members will be
looking in your ISP's DNS server for records that are only in your internal
DNS.

> 2) I tried loading the netdiag on an XP machine that has the error
> that I sent originally, and upon running netdiag /test:dns /v at the
> command line, I get the following error:
>
> "The procedure entry point DnsNetworkInformation_CreateFromFAZ could
> not be located in the dynamic link library DNSAPI.dll"

This sounds like you are not using Netdiag for XP or you do not have the
remote registry service running.

You should only use Netdiag from the XP CD on Windows XP.

Frequently asked questions about Windows 2000 DNS and Windows Server 2003
DNS
http://support.microsoft.com/default.aspx?scid=kb;en-us;291382

300202 - HOW TO: Configure DNS for Internet Access in Windows 2000
http://support.microsoft.com/?id=300202&sd=RMVP

825036 - Best practices for DNS client settings in Windows 2000 Server and
in Windows Server 2003
http://support.microsoft.com/default.aspx?scid=kb;en-us;825036&sd=RMVP

323380 - HOW TO: Configure DNS for Internet Access in Windows Server 2003
http://support.microsoft.com/default.aspx?scid=kb;en-us;323380&sd=RMVP

828263 - DNS query responses do not travel through a firewall in Windows
Server 2003:
http://support.microsoft.com/default.aspx?scid=kb;en-us;828263&sd=RMVP

pbrill1

unread,

Jan 16, 2006, 5:49:03 PM1/16/06

to

Kevin,

Thank you for your reply. I will review the links that you provided over
the next 2-3 days to see if I can resolve this DNS error. I'm sure that I'll
need to reply, with more info, at that point.

Thanks for your help, and for your quick and thorough replies.
--
pbrill1

Neobyte

unread,

Jan 18, 2006, 10:53:55 PM1/18/06

to

Pbrill1,

I managed to resolve my issue. It appeared to be related to my use of
the SetDNSServerSearchOrder() WMI function. I changed my scripts to
using a shell call to NETSH and everything has resolved itself.

I'm thinking that what might have been happening is that, after DHCP
assigned the original DNS addresses, my call to
SetDNSServerSearchOrder() was changing the DNS server but somehow
breaking the underlying "update" server, which appears to have no
direct interface you can call. From then, my A.B.x.x clients kept
trying to send their DNS updates to A.1.1.1, even though they had the
DNS server A.B.C.D listed as the only DNS server in their
configuration.

I should mention here that I do not control the DHCP servers in my
organisation, and that the DNS servers returned by DHCP are not
directly aware of my domain, which is why I must point my clients at my
own DNS prior to connecting them to the domain.

It is possible that this issue could have been resolved by renewing the
DHCP lease *after* the call to SetDNSServerSearchOrder(). I base this
on an email I received from someone with a similar problem who
mentioned the problem appeared to disappear after a few days - that
sounds suspiciously like the DHCP lease renewal was fixing the problem
in that case. However I've got things working now and don't have time
for further study.

Cheers
Rich

Kevin D. Goodknecht Sr. [MVP]

unread,

Jan 19, 2006, 8:25:53 AM1/19/06

to

As I previously stated, all members of your AD domain must use only the DNS
servers that support the AD domain, ONLY. No external or ISP's DNS allowed
in any position on any interface. If your internal DNS is a little slow to
respond the alternate will be moved to the preferred DNS by the client, and
will not be returned to the default position, until TCP/IP is reset, or
until a reboot. That is why renewing the lease "seems" to fix it.
The actual fix, is to not use the external DNS.

You can set the DNS server list by group policy to XP clients once the
machine is joined to the domain.

pbrill1

unread,

Jan 19, 2006, 12:02:02 PM1/19/06

to

Kevin,

The links to the DNS articles (especially the "Best Practices" article) were
VERY helpful. As noted, we incorrectly use the ISP's DNS (it was pushed to
clients through DHCP). We have since corrected this issue - and I'll need to
wait-and-see if this addresses the 10.1.1.1 issue.

When reviewing these articles and 'cleaning up' our DNS practices, I had
just a few more questions that the kb's I read did not cover.
1) The 'best practice' article gives detail to the TCP/IP's DNS tab settings
for a DC's DNS configuration. My questions are:
a) In the "For resolution of unqualified names" choice, is it better to
use (what appears to be the default) "Append primary and connection specific
DNS suffixes" with the "Append parent suffixes of the primary DNS suffix"
checked, or specify our domain in the "Append these suffixes (in order)"
(NOTE: We have a W2K3 Native AD-integrated Single Domain model, with 2 DC's
that have DNS, with each pointing to themselves as primary, and the other as
secondary).

b) For member servers (and a few specific static IP clients), should their -
-Register this connection’s address in DNS
-Use this connections DNS suffix in DNS registration
also BOTH be checked (the former looks to be checked by default, but the
latter does not).

Hopefully, fixing such DNS settings may be enough to address the current
issue - and I will continue to look into the
--
pbrill1

pbrill1

unread,

Jan 19, 2006, 1:27:02 PM1/19/06

to

Kevin,

I ran the "netdiag /test:dns /v" on our local DC - results below.
I noticed a few unusual things:
- the LOCAL-DC server's DNS SRV record ends with a ".", while the REMOTE-DC
doesn't
- the LOCAL-DC doesn't show the REMOTE-DC SRV record, but REMOTE-DC does
show the LOCAL-DC SRV record (although I SEE both in the LOCAL-DC server's
DNS Forward lookup zone and DNS Adv Tab!)

I'm a bit unsure about where to go next with this...or if I need to worry
about it at all.

Log (with certain items xxx'ed out, and initial "passes", and some info at
the end, removed to keep to the 30000 char max!) below:
----
Per interface results:

Adapter : Local Area Connection
Adapter ID . . . . . . . . : {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}

Netcard queries test . . . : Passed

Global results:

Domain membership test . . . . . . : Passed
Machine is a . . . . . . . . . : Primary Domain Controller Emulator
Netbios Domain name. . . . . . : OURCOMPANY_NT
Dns domain name. . . . . . . . : company.net
Dns forest name. . . . . . . . : company.net
Domain Guid. . . . . . . . . . : {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
Domain Sid . . . . . . . . . . : S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx
Logon User . . . . . . . . . . : administrator
Logon Domain . . . . . . . . . : OURCOMPANY_NT

NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
1 NetBt transport currently configured.

DNS test . . . . . . . . . . . . . : Passed
Interface {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
DNS Domain:
DNS Servers: 10.0.0.100 10.0.1.100
IP Address: Expected registration with PDN (primary DNS
domain name):
Hostname: local-dc.company.net.
Authoritative zone: company.net.
Primary DNS server: local-dc.company.net 10.0.0.100
Authoritative NS:10.0.1.100 10.0.0.100
Check the DNS registration for DCs entries on DNS server '10.0.0.100'
The Record is different on DNS server '10.0.0.100'.
DNS server has more than one entries for this name, usually this means there
are multiple DCs for this domain.
Your DC entry is one of them on DNS server '10.0.0.100', no need to
re-register.

+------------------------------------------------------+
The record on your DC is:
DNS NAME = company.net.
DNS DATA =
A 10.0.0.100

The record on DNS server 10.0.0.100 is:
DNS NAME = company.net
DNS DATA =
A 10.0.0.100
A 10.0.1.100
+------------------------------------------------------+