Resolver issue

[Massimo]

I'm having some troubles with the Windows DNS resolver (the behaviour is the
same in Windows 2000, XP and 2003).
As stated in the document available at
http://www.microsoft.com/windows2000/techinfo/howitworks/communications/nameadrmgmt/w2kdns.asp
(section "Caching resolver", subsection "Unqualified Multi-Label Query"),
when a computer having a domain suffix of "domain.com" is trying to resolve
a name such as "anotherdomain.com", the resolver should first query the DNS
for "anotherdomain.com" and, if this fails, it should then resort to quering
"anotherdomain.com.domain.com".
Well, it seems to be not exactly like this. I ran some network traces using
Network Monitor, and I just watched Windows querying
"www.anotherdomain.com.domain.com" and, only when this failed, trying the
simpler (and correct) query "anotherdomain.com".

Let me explain the problem, and why do I care about this.

I'm the network administrator for a small italian I.T. company, where an
Exchange 2003 mailserver is running. The company LAN is a private network
(192.168.42.0/24), connected to the Internet through a NAT router. Inside
this LAN, I have two DCs which also are the LAN's DNS servers; they are
configured to resolve Internet names too. Everything works fine.

Let's assume the domain suffix for all LAN machines is "mydomain.com"
(sorry, I can't tell the true domain suffix).

When my Exchange server wanted to send e-mails to recipients at a popular
italian ISP called "Libero", whose domain suffix is "libero.it", it kept
logging errors about not being able to contact the recipient's mailserver.
So I tried manually running a MX query for the domain "libero.it", and I got
a very stange reply: a listing of the authoritative DNSs for "mydomain.com";
no wonder Exchange couldn't send e-mails to a domain whose MX record was
unreadable...

I tried many network configurations and DNS queries, trying to narrow down
the problem, and finally I discovered the two problems which, when combined,
cause the strange behaviour I witnessed.

The first problem is, Libero's DNS reacts very strangely when queried about
non-existant hosts or domains. Instead of replying with a "this host/domain
doesn't exist" answer, it lists the authoritative DNSs for the TLD of the
query text; I'm quite sure this is a very irregular behaviour for a public
DNS server.

The second problem, the one I'm addressing by writing here, is this: when
running on a machine with a configured domain suffix, Windows tries
resolving DNS queries first by appending the suffix to the query, and only
when this fails it re-runs the query "as is", without additional suffixes.

So, this is the result: when looking for Libero's mailserver, my Exchange
server queries my Windows 2003 DNS, which sends to Libero's DNS a MX query
for "libero.it.mydomain.com.". Libero's DNS, instead of replying "wrong
query, try again", lists the authoritative DNSs for "mydomain.com.". Having
got an answer (even if totally wrong), my DNS stops querying and retuns this
answer to the Exchange server... which, obviously, can't do much with it and
so stops sending that e-mail.

Now, I can't do anything about Libero's wrongly-behaving DNSs (although it's
a quite popular ISP here, their network administrators are quite known to be
a bunch of idiots). But I want to know why Windows resolves DNS queries this
way, even if this is in contrast with what is stated in that white paper.

Can anyone please help?

Thanks

Massimo

 

[Kevin D. Goodknecht Sr. [MVP]]

In

I'm having some troubles with the Windows DNS resolver
(the behaviour is the
same in Windows 2000, XP and 2003).
As stated in the document available at
http://www.microsoft.com/windows2000/techinfo/howitworks/communications/nameadrmgmt/w2kdns.asp
(section "Caching resolver", subsection "Unqualified
Multi-Label Query"),
when a computer having a domain suffix of "domain.com" is
trying to resolve
a name such as "anotherdomain.com", the resolver should
first query the DNS
for "anotherdomain.com" and, if this fails, it should
then resort to quering
"anotherdomain.com.domain.com".
Well, it seems to be not exactly like this. I ran some
network traces using
Network Monitor, and I just watched Windows querying
"www.anotherdomain.com.domain.com" and, only when this
failed, trying the
simpler (and correct) query "anotherdomain.com".

Let me explain the problem, and why do I care about this.

I'm the network administrator for a small italian I.T.
company, where an
Exchange 2003 mailserver is running. The company LAN is a
private network
(192.168.42.0/24), connected to the Internet through a
NAT router. Inside
this LAN, I have two DCs which also are the LAN's DNS
servers; they are
configured to resolve Internet names too. Everything
works fine.

Let's assume the domain suffix for all LAN machines is
"mydomain.com"
(sorry, I can't tell the true domain suffix).

When my Exchange server wanted to send e-mails to
recipients at a popular
italian ISP called "Libero", whose domain suffix is
"libero.it", it kept
logging errors about not being able to contact the
recipient's mailserver.
So I tried manually running a MX query for the domain
"libero.it", and I got
a very stange reply: a listing of the authoritative DNSs
for "mydomain.com";
no wonder Exchange couldn't send e-mails to a domain
whose MX record was
unreadable...

I tried many network configurations and DNS queries,
trying to narrow down
the problem, and finally I discovered the two problems
which, when combined,
cause the strange behaviour I witnessed.

The first problem is, Libero's DNS reacts very strangely
when queried about
non-existant hosts or domains. Instead of replying with a
"this host/domain
doesn't exist" answer, it lists the authoritative DNSs
for the TLD of the
query text; I'm quite sure this is a very irregular
behaviour for a public
DNS server.

The second problem, the one I'm addressing by writing
here, is this: when
running on a machine with a configured domain suffix,
Windows tries
resolving DNS queries first by appending the suffix to
the query, and only
when this fails it re-runs the query "as is", without
additional suffixes.

So, this is the result: when looking for Libero's
mailserver, my Exchange
server queries my Windows 2003 DNS, which sends to
Libero's DNS a MX query
for "libero.it.mydomain.com.". Libero's DNS, instead of
replying "wrong
query, try again", lists the authoritative DNSs for
"mydomain.com.". Having
got an answer (even if totally wrong), my DNS stops
querying and retuns this
answer to the Exchange server... which, obviously, can't
do much with it and
so stops sending that e-mail.

Now, I can't do anything about Libero's wrongly-behaving
DNSs (although it's
a quite popular ISP here, their network administrators
are quite known to be
a bunch of idiots). But I want to know why Windows
resolves DNS queries this
way, even if this is in contrast with what is stated in
that white paper.

This is done in the system DNS resolver to facilitate doing lookups on local
host names.

Your system DNS resolver shouldn't be querying your ISP's DNS anyway, in an
AD environment all machines must only use the local DNS server in TCP/IP
properties. (I know you have AD since you have Exchange 2003)

To configure Exchange to make queries to your ISP's DNS (without using the
system resolver and appending suffixes) use Exchange system manager, drill
down through Administrative Groups, First Administrative group, Servers,
<servername>, Protocols, SMTP. Click on the properties of your Virtual SMTP
server, Delivery tab, Advanced button, "Configure external DNS servers:"
click the "Configure" button then "Add" put your ISP's DNS in then OK your
way out.

 

[Ace Fekay [MVP]]

In

This is done in the system DNS resolver to facilitate doing lookups
on local host names.

Your system DNS resolver shouldn't be querying your ISP's DNS anyway,
in an AD environment all machines must only use the local DNS server
in TCP/IP properties. (I know you have AD since you have Exchange
2003)

To configure Exchange to make queries to your ISP's DNS (without
using the system resolver and appending suffixes) use Exchange system
manager, drill down through Administrative Groups, First
Administrative group, Servers, <servername>, Protocols, SMTP. Click
on the properties of your Virtual SMTP server, Delivery tab, Advanced
button, "Configure external DNS servers:" click the "Configure"
button then "Add" put your ISP's DNS in then OK your way out.

--
Best regards,
Kevin D4 Dad Goodknecht Sr. [MVP]
Hope This Helps
============================

I agree it appears that the ISP's servers are in IP properties for it to
behave this way. An ipconfig /all can help clear it up. If this is the case,
maybe we don't have to configure the STMP virtual server to use an external.
Usually this is done to offload DNS lookups from the internal DNS,
especially if Exchange is in the DMZ.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

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

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

 

[William Stacey [MVP]]

The local behavior (IIRC) for a non-fqdn (i.e. no dot at end) is:
1) Append dot and try that.
2) Append primary suffix and use devolution.
3) Append other suffixes.
4) fail.

If you append the dot to make fully qualified, you should get the
www.anotherdomain.com. answer. If not, need to see more output.

 

[Massimo]

This is done in the system DNS resolver to facilitate doing lookups on
local host names.

Yes, I'm sure someone at Microsoft tought it was useful; but then why is the
DNS white paper saying it shouldn't?

Your system DNS resolver shouldn't be querying your ISP's DNS anyway, in
an AD environment all machines must only use the local DNS server in
TCP/IP properties. (I know you have AD since you have Exchange 2003)

All the machines on my network are using the local DNS server, and that
server resolves external names using standard recursive queries. But, since
(as it seems) even the Windows DNS server uses the system resolver, the
clients are getting wrong answers anyway.

To configure Exchange to make queries to your ISP's DNS (without using the
system resolver and appending suffixes) use Exchange system manager, drill
down through Administrative Groups, First Administrative group, Servers,
<servername>, Protocols, SMTP. Click on the properties of your Virtual
SMTP server, Delivery tab, Advanced button, "Configure external DNS
servers:" click the "Configure" button then "Add" put your ISP's DNS in
then OK your way out.

Thanks for the tip.

Massimo

 

[Massimo]

I agree it appears that the ISP's servers are in IP properties for it to
behave this way. An ipconfig /all can help clear it up. If this is the
case, maybe we don't have to configure the STMP virtual server to use an
external. Usually this is done to offload DNS lookups from the internal
DNS, especially if Exchange is in the DMZ.

No, that's wrong.
All of the machines, including the Exchange server, use the internal DNS
servers, running on the two DCs. These DNS are configured to be
authoritative for the Windows domain, but they also resolve external names,
allowing clients to reach the Internat through the NAT gateway.
The problem arises when the internal DNSs send queries to Libero's ones in
order to resolve hostnames about the domain libero.it; the Windows DNS
server apparently uses the same algorithm as the system resolver, so it
sends out recursive queries appending the local domain suffix to them, and
only when these query fail it tries the "right" queries (i.e., as they were
asked initially).

Massimo

 

[Massimo]

The local behavior (IIRC) for a non-fqdn (i.e. no dot at end) is:
1) Append dot and try that.
2) Append primary suffix and use devolution.
3) Append other suffixes.
4) fail.

If you append the dot to make fully qualified, you should get the
www.anotherdomain.com. answer. If not, need to see more output.

I do. It works perfectly, appending the dot... this is what pointed me in
the right direction for finding what the problem was.
And you're right, the behaviour for a non-fqdn *should* be what you
described; at least, the white paper says it should.
Unfortunately, Windows appears to be not following its own white papers...
the network monitor traces are quite clear about this.

Massimo

 

[Massimo]

I'm having some troubles with the Windows DNS resolver (the behaviour is
the same in Windows 2000, XP and 2003).

More details about the problem: here's some NSLOOKUP output.

----------

server ns1.libero.it

Server predefinito: ns1.libero.it
Address: 195.210.91.100

set querytype=mx
libero.it

Server: ns1.libero.it
Address: 195.210.91.100

com nameserver = H.GTLD-SERVERS.NET
com nameserver = I.GTLD-SERVERS.NET
com nameserver = J.GTLD-SERVERS.NET
com nameserver = K.GTLD-SERVERS.NET
com nameserver = L.GTLD-SERVERS.NET
com nameserver = M.GTLD-SERVERS.NET
com nameserver = A.GTLD-SERVERS.NET
com nameserver = B.GTLD-SERVERS.NET
com nameserver = C.GTLD-SERVERS.NET
com nameserver = D.GTLD-SERVERS.NET
com nameserver = E.GTLD-SERVERS.NET
com nameserver = F.GTLD-SERVERS.NET
com nameserver = G.GTLD-SERVERS.NET

dsfdsfdsrf.dfdsf

Server: ns1.libero.it
Address: 195.210.91.100

com nameserver = H.GTLD-SERVERS.NET
com nameserver = I.GTLD-SERVERS.NET
com nameserver = J.GTLD-SERVERS.NET
com nameserver = K.GTLD-SERVERS.NET
com nameserver = L.GTLD-SERVERS.NET
com nameserver = M.GTLD-SERVERS.NET
com nameserver = A.GTLD-SERVERS.NET
com nameserver = B.GTLD-SERVERS.NET
com nameserver = C.GTLD-SERVERS.NET
com nameserver = D.GTLD-SERVERS.NET
com nameserver = E.GTLD-SERVERS.NET
com nameserver = F.GTLD-SERVERS.NET
com nameserver = G.GTLD-SERVERS.NET

libero.it.

Server: ns1.libero.it
Address: 195.210.91.100

libero.it MX preference = 10, mail exchanger = mx3.libero.it
libero.it MX preference = 10, mail exchanger = mx4.libero.it
libero.it MX preference = 10, mail exchanger = mx5.libero.it
libero.it MX preference = 10, mail exchanger = mx1.libero.it
libero.it MX preference = 10, mail exchanger = mx2.libero.it
libero.it nameserver = ns1.libero.it
libero.it nameserver = ns2.libero.it
mx1.libero.it internet address = 193.70.192.92
mx1.libero.it internet address = 193.70.192.54
mx1.libero.it internet address = 193.70.192.55
mx1.libero.it internet address = 193.70.192.59
mx1.libero.it internet address = 193.70.192.90
mx2.libero.it internet address = 193.70.192.92
mx2.libero.it internet address = 193.70.192.54
mx2.libero.it internet address = 193.70.192.55
mx2.libero.it internet address = 193.70.192.59
mx2.libero.it internet address = 193.70.192.90
mx3.libero.it internet address = 193.70.192.54
mx3.libero.it internet address = 193.70.192.55
mx3.libero.it internet address = 193.70.192.59
mx3.libero.it internet address = 193.70.192.90
mx3.libero.it internet address = 193.70.192.92
mx4.libero.it internet address = 193.70.192.59
mx4.libero.it internet address = 193.70.192.90
mx4.libero.it internet address = 193.70.192.92
mx4.libero.it internet address = 193.70.192.54
mx4.libero.it internet address = 193.70.192.55----------

The domain suffix of my computer is something.com, and as you can see I'm
getting the list of the root name servers for the.com TLD, whatever query I
try. But, using a FQDN, I finally get the right answers. The network monitor
trace (available to anyone wanting to investigate it) clearly shows that
this is happening because Windows first tries the query appending
something.com to it, and only when this fails it sends the right query. But,
since Libero's DNS is answering the query (wrongly) instead of refusing it,
the resolver stops and returns the wrong answer.
Anyway, how can happen that this ISP's DNS is answering MX queries with root
name servers? What was their network administrator smoking when he
configured the servers?!? :-(

Massimo

 

[Massimo]

To configure Exchange to make queries to your ISP's DNS (without using the
system resolver and appending suffixes) use Exchange system manager, drill
down through Administrative Groups, First Administrative group, Servers,
<servername>, Protocols, SMTP. Click on the properties of your Virtual
SMTP server, Delivery tab, Advanced button, "Configure external DNS
servers:" click the "Configure" button then "Add" put your ISP's DNS in
then OK your way out.

I'm not sure this could work: doesn't Exchange use the Windows resolver when
querying DNS servers? It has its own DNS-resolving libraries?

Massimo

 

[Massimo]

More details about the problem: here's some NSLOOKUP output.

Another point worth noting: I partially sovled the problem using conditional
forwarders on my DNS servers, forwarding queries for the libero.it domain to
my ISP's DNS. But, if my ISP was Libero (which, fortunately, isn't), this
wouldn't have solved anything, because I would still have got the same
absurd behaviour that happens when Windows queries that idiotly-configured
DNSs.

Massimo

 

[Kevin D. Goodknecht Sr. [MVP]]

In

All the machines on my network are using the local DNS
server, and that server resolves external names using
standard recursive queries. But, since (as it seems) even
the Windows DNS server uses the system resolver, the
clients are getting wrong answers anyway.

Incorrect, the DNS server service does not use the system resolver.
In fact I would stop the DNS Client service on the server that has DNS
installed. It makes no sense to have the DNS client service running on this
server.
Do use nslookup to test your queries either, it will append names using the
settings from the system resolver, but it has its own cache so it can give
you inconsistent results. Use Dig or Netdig, Netdig is available for
download from www.mvptools.com and requires only that you have .NET
Framework 1.1. Dig comes with BIND, but it requires extra libraries that
must be installed, too.

 

[Kevin D. Goodknecht Sr. [MVP]]

In

More details about the problem: here's some NSLOOKUP
output.

----------
Server predefinito: ns1.libero.it
Address: 195.210.91.100

Server: ns1.libero.it
Address: 195.210.91.100

com nameserver = H.GTLD-SERVERS.NET
com nameserver = I.GTLD-SERVERS.NET
com nameserver = J.GTLD-SERVERS.NET
com nameserver = K.GTLD-SERVERS.NET
com nameserver = L.GTLD-SERVERS.NET
com nameserver = M.GTLD-SERVERS.NET
com nameserver = A.GTLD-SERVERS.NET
com nameserver = B.GTLD-SERVERS.NET
com nameserver = C.GTLD-SERVERS.NET
com nameserver = D.GTLD-SERVERS.NET
com nameserver = E.GTLD-SERVERS.NET
com nameserver = F.GTLD-SERVERS.NET
com nameserver = G.GTLD-SERVERS.NET

Server: ns1.libero.it
Address: 195.210.91.100

com nameserver = H.GTLD-SERVERS.NET
com nameserver = I.GTLD-SERVERS.NET
com nameserver = J.GTLD-SERVERS.NET
com nameserver = K.GTLD-SERVERS.NET
com nameserver = L.GTLD-SERVERS.NET
com nameserver = M.GTLD-SERVERS.NET
com nameserver = A.GTLD-SERVERS.NET
com nameserver = B.GTLD-SERVERS.NET
com nameserver = C.GTLD-SERVERS.NET
com nameserver = D.GTLD-SERVERS.NET
com nameserver = E.GTLD-SERVERS.NET
com nameserver = F.GTLD-SERVERS.NET
com nameserver = G.GTLD-SERVERS.NET

Server: ns1.libero.it
Address: 195.210.91.100

libero.it MX preference = 10, mail exchanger =
mx3.libero.it libero.it MX preference = 10, mail
exchanger = mx4.libero.it libero.it MX preference =
10, mail exchanger = mx5.libero.it libero.it MX
preference = 10, mail exchanger = mx1.libero.it libero.it
MX preference = 10, mail exchanger = mx2.libero.it
libero.it nameserver = ns1.libero.it
libero.it nameserver = ns2.libero.it
mx1.libero.it internet address = 193.70.192.92
mx1.libero.it internet address = 193.70.192.54
mx1.libero.it internet address = 193.70.192.55
mx1.libero.it internet address = 193.70.192.59
mx1.libero.it internet address = 193.70.192.90
mx2.libero.it internet address = 193.70.192.92
mx2.libero.it internet address = 193.70.192.54
mx2.libero.it internet address = 193.70.192.55
mx2.libero.it internet address = 193.70.192.59
mx2.libero.it internet address = 193.70.192.90
mx3.libero.it internet address = 193.70.192.54
mx3.libero.it internet address = 193.70.192.55
mx3.libero.it internet address = 193.70.192.59
mx3.libero.it internet address = 193.70.192.90
mx3.libero.it internet address = 193.70.192.92
mx4.libero.it internet address = 193.70.192.59
mx4.libero.it internet address = 193.70.192.90
mx4.libero.it internet address = 193.70.192.92
mx4.libero.it internet address = 193.70.192.54
mx4.libero.it internet address = 193.70.192.55
----------

The domain suffix of my computer is something.com, and as
you can see I'm getting the list of the root name servers
for the.com TLD, whatever query I try. But, using a FQDN,
I finally get the right answers. The network monitor
trace (available to anyone wanting to investigate it)
clearly shows that this is happening because Windows
first tries the query appending something.com to it, and
only when this fails it sends the right query. But, since
Libero's DNS is answering the query (wrongly) instead of
refusing it, the resolver stops and returns the wrong
answer.
Anyway, how can happen that this ISP's DNS is answering
MX queries with root name servers? What was their network
administrator smoking when he configured the servers?!?

This is the kind of answer you get when you query non-recursive DNS servers,
instead of getting an answer you get a referral to the Root DNS servers.
Also, this is the kind of problem you'll have using nslookup, if you use
nslookup you need to append all queries with a trailing " . " like
libero.it. (notice the dot after the name) this keeps nslookup from
appending with the domain suffixes listed in the domain suffix search list.

You should check with your ISP to see if they have any recursive DNS servers
to use as a forwarder or DNS resolver.

When I tried to query this DNS server, it timed out on everything including
libero.it which, it is Authoritative for. So, I can tell you if
ns1.libero.it is able to do recursive queries.

 

[Ace Fekay [MVP]]

In

No, that's wrong.
All of the machines, including the Exchange server, use the internal
DNS servers, running on the two DCs. These DNS are configured to be
authoritative for the Windows domain, but they also resolve external
names, allowing clients to reach the Internat through the NAT gateway.
The problem arises when the internal DNSs send queries to Libero's
ones in order to resolve hostnames about the domain libero.it; the
Windows DNS server apparently uses the same algorithm as the system
resolver, so it sends out recursive queries appending the local
domain suffix to them, and only when these query fail it tries the
"right" queries (i.e., as they were asked initially).

Massimo

I apologize I was wrong. I've seen it do this with misconfigured DNS clients
and just wanted to point that out. Besides, you've been testing this with
nslookup and not ping. They both work differently whereas ping will try the
fqdn first then suffix it without an answer, but nslookup suffixes it first
then if no answer, tries it without it.

I'm assuming you are NOT using a forwarder? I believe that will eliminate
this issue altogether.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

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

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

 

[Ace Fekay [MVP]]

In

Another point worth noting: I partially sovled the problem using
conditional forwarders on my DNS servers, forwarding queries for the
libero.it domain to my ISP's DNS. But, if my ISP was Libero (which,
fortunately, isn't), this wouldn't have solved anything, because I
would still have got the same absurd behaviour that happens when
Windows queries that idiotly-configured DNSs.

Massimo

I asked in my other response if you were using a forwarder. We must have
posted almost at the same time. Forwarding solves a couple issues, this
being one of them. I usually like to config a forwarder (whether conditonal
or 'all other domains'), so the server itself doesn't have to do any
resolution and just pass it.

Here's that repost I was talking about by William.
William, hope you don't mind!

Ace

----- Original Message -----
From: "William Stacey [MVP]" <[email protected]>
Newsgroups: microsoft.public.win2000.dns
Sent: Saturday, August 31, 2002 1:28 PM
Subject: Re: DNS resolving problems

Seems like ping and nslookup behave a little different as nslookup uses it
own resolver logic (how much I don't know, but would like to find out.)
Say you create a zone on your DNS called "yahoo.com.pin.com" and add a host
record called "www" at 192.168.0.1. Also create a "yahoo.com" zone on the
dns server that we can add and remove a "www" record for testing.

1) In nslookup, if you type www.yahoo.com the period "." is not appended
first to make it fully qualified, but the srchlist (found using "set all")
is appended first, making the query effectively www.yahoo.com.pin.com.
Nslookup will append the period after trying the srchlist first. So if I
remove the www.yahoo.com.pin.com host record, nslookup will find the
www.yahoo.com host record in my fake yahoo.com zone. nslookup, AFAICT,
automatically "devolves" the primary DNS suffix. So if your suffix is
sub1.pin.com. Then nslookups search list will be "sub1.pin.com/pin.com". So
to answer your question directly, nslookup will append the srchlist first,
which by default is the Primary DNS suffix (seen by using ipconfig /all.)

2) Ping, on the other hand, appends the dot "." first. So if I try "ping
www.yahoo.com" with the "www" record in both the yahoo.com zone and the
"yahoo.com.pin.com" zone, the resolver finds the "www.yahoo.com" record
first because it issues the query like "www.yahoo.com.". However, if I
remove the "www.yahoo.com" record, then the query to "www.yahoo.com." fails
(i.e. NXDOMAIN) and the resolver appends the Primary DNS Suffix to return
the following:
E:\>ping www.yahoo.com
Pinging www.yahoo.com.pin.com [192.168.0.1] with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time<10ms TTL=128...

Ping, via the client resolver, will devolve the Primary DNS suffix if you
have the "Append parent suffixes of the primary DNS suffix" check box
checked. So if your Primary DNS suffix is "sub1.pin.com" and you do "ping
www"; the resolver will try www.sub1.pin.com. first, then try www.pin.com..

As you can see, adding "real" subdomains (like hp.com) to your DNS tree can
have unintended side-effects like mail sent to (e-mail address removed) may actually
be delivered to (e-mail address removed). However, this example does serve to
illustrate some subtle differences between how ping and nslookup behave and
how dots "." and search lists can effect query results in both.

HTH

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

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

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

 

[William Stacey [MVP]]

No problem. I was going to talk about nslookup, but looking at this old
post I would add that nslookup does not use the local resolver at all, but
its own resolver logic. So the win resolver logic (in whitpaper) does not
apply to nslookup or dig, etc. Other utils such as ping, telnet, etc use
the local resolver. So massimo should recheck his NetMons using ping, net,
etc to see the local resolver behavior.

--
William Stacey, MVP

"Ace Fekay [MVP]"

In

Another point worth noting: I partially sovled the problem using
conditional forwarders on my DNS servers, forwarding queries for the
libero.it domain to my ISP's DNS. But, if my ISP was Libero (which,
fortunately, isn't), this wouldn't have solved anything, because I
would still have got the same absurd behaviour that happens when
Windows queries that idiotly-configured DNSs.

Massimo

I asked in my other response if you were using a forwarder. We must have
posted almost at the same time. Forwarding solves a couple issues, this
being one of them. I usually like to config a forwarder (whether conditonal
or 'all other domains'), so the server itself doesn't have to do any
resolution and just pass it.

Here's that repost I was talking about by William.
William, hope you don't mind!

Ace

----- Original Message -----
From: "William Stacey [MVP]" <[email protected]>
Newsgroups: microsoft.public.win2000.dns
Sent: Saturday, August 31, 2002 1:28 PM
Subject: Re: DNS resolving problems

Seems like ping and nslookup behave a little different as nslookup uses it
own resolver logic (how much I don't know, but would like to find out.)
Say you create a zone on your DNS called "yahoo.com.pin.com" and add a host
record called "www" at 192.168.0.1. Also create a "yahoo.com" zone on the
dns server that we can add and remove a "www" record for testing.

1) In nslookup, if you type www.yahoo.com the period "." is not appended
first to make it fully qualified, but the srchlist (found using "set all")
is appended first, making the query effectively www.yahoo.com.pin.com.
Nslookup will append the period after trying the srchlist first. So if I
remove the www.yahoo.com.pin.com host record, nslookup will find the
www.yahoo.com host record in my fake yahoo.com zone. nslookup, AFAICT,
automatically "devolves" the primary DNS suffix. So if your suffix is
sub1.pin.com. Then nslookups search list will be

"sub1.pin.com/pin.com".

So
to answer your question directly, nslookup will append the srchlist first,
which by default is the Primary DNS suffix (seen by using ipconfig /all.)

2) Ping, on the other hand, appends the dot "." first. So if I try "ping
www.yahoo.com" with the "www" record in both the yahoo.com zone and the
"yahoo.com.pin.com" zone, the resolver finds the "www.yahoo.com" record
first because it issues the query like "www.yahoo.com.". However, if I
remove the "www.yahoo.com" record, then the query to "www.yahoo.com." fails
(i.e. NXDOMAIN) and the resolver appends the Primary DNS Suffix to return
the following:
E:\>ping www.yahoo.com
Pinging www.yahoo.com.pin.com [192.168.0.1] with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time<10ms TTL=128...

Ping, via the client resolver, will devolve the Primary DNS suffix if you
have the "Append parent suffixes of the primary DNS suffix" check box
checked. So if your Primary DNS suffix is "sub1.pin.com" and you do "ping
www"; the resolver will try www.sub1.pin.com. first, then try www.pin.com..

As you can see, adding "real" subdomains (like hp.com) to your DNS tree can
have unintended side-effects like mail sent to (e-mail address removed) may actually
be delivered to (e-mail address removed). However, this example does

serve

to
illustrate some subtle differences between how ping and nslookup behave and
how dots "." and search lists can effect query results in both.

HTH

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

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

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

 

[Ace Fekay [MVP]]

In

No problem. I was going to talk about nslookup, but looking at this
old post I would add that nslookup does not use the local resolver at
all, but its own resolver logic. So the win resolver logic (in
whitpaper) does not apply to nslookup or dig, etc. Other utils such
as ping, telnet, etc use the local resolver. So massimo should
recheck his NetMons using ping, net, etc to see the local resolver
behavior.

Actually I believe you did mention that in the post that ping and nslookup
do it differently, hence why I posted in another post to the OP that this
all depends on how he's testing it. I would just setup unconditional
forwarders for All Other Domains and eliminate the whole issue.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

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

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

 

[Massimo]

"Ace Fekay [MVP]"

I'm assuming you are NOT using a forwarder? I believe that will eliminate
this issue altogether.

Yes, it works flawlessly if I forward queries to my ISP's DNS.
But if (for a chance) my ISP was actually Libero, it wouldn't have solved
anything... so I'm trying to get to the root of the problem.

Massimo

 

[William Stacey [MVP]]

Actually I believe you did mention that in the post that ping and nslookup

do it differently

Right. I just picked up on "(how much I don't know, but would like to find
out.)" and wanted to clarify that today I do know that they don't use in at
all - just to clarify myself All they do is pickup the local dns servers
and (to different degrees) the domain suffixes configured and maybe other
pieces of info. Cheers!

--wjs

 

[Massimo]

This is the kind of answer you get when you query non-recursive DNS
servers, instead of getting an answer you get a referral to the Root DNS
servers.

So, you're saying this kind of answer is good. Ok.

When I tried to query this DNS server, it timed out on everything
including libero.it which, it is Authoritative for. So, I can tell you if
ns1.libero.it is able to do recursive queries.

Interesting. I tried running a couple of network monitor traces on my DNS
server, and it looks like Libero's DNSs time out when my DNS queries them at
the end of the recursive query. But then, when querying them using NSLOOKUP,
they answer!
What's going wrong here?!?

Massimo

 

[Massimo]

"Ace Fekay [MVP]"

Actually I believe you did mention that in the post that ping and nslookup
do it differently, hence why I posted in another post to the OP that this
all depends on how he's testing it. I would just setup unconditional
forwarders for All Other Domains and eliminate the whole issue.

I know this works, but I don't like this solution because my ISP's DNS is
down sometimes... using recursive queries from my DNSs, I'm sure Internet
names can always be resolved. Unless both my DCs are down, of course, but
then I'd have something worse to worry about than not being able to view web
pages ;-)

Massimo