problems with recursive queries

  • Thread starter Thread starter Ken Blankenship
  • Start date Start date
K

Ken Blankenship

Since installing Service Pack 4, my dns servers don't seem
to be capable of resolving names outside of my domain (eg.
yahoo.com, slashdot.org, microsoft.com). Using nslookup
with the debug option set, I have noticed that my domain
name is appended to the tail end of every query. For
instance a lookup for "microsoft.com" shows a question in
debug for "microsoft.com.domain.edu".

I have also noticed that in the DNS MMC, with advanced
viewing options, the Cached Lookups list only has an
entry for .->net->root-servers, but that root-servers
folder is always empty. When my DNS servers were operating
correctly, I had numerous listings there.

I have tried replaced the cache.dns, but that did not help.

Ken Blankenship
 
In
Ken Blankenship said:
Since installing Service Pack 4, my dns servers don't seem
to be capable of resolving names outside of my domain (eg.
yahoo.com, slashdot.org, microsoft.com). Using nslookup
with the debug option set, I have noticed that my domain
name is appended to the tail end of every query. For
instance a lookup for "microsoft.com" shows a question in
debug for "microsoft.com.domain.edu".

I have also noticed that in the DNS MMC, with advanced
viewing options, the Cached Lookups list only has an
entry for .->net->root-servers, but that root-servers
folder is always empty. When my DNS servers were operating
correctly, I had numerous listings there.

I have tried replaced the cache.dns, but that did not help.

Ken Blankenship
Click to expand...

I have not heard of SP4 causing DNS to stop resolving external names.
So far as the behavior of adding you domain name on queries that is expected
and is designed that way when you have those names in your search order in
TCP/IP properties. That is how DNS searches when you just do a hostname
lookup.

As for not being able to do external lookups, I assume you don't have
recursion disabled on the advanced tab, that you you don't have a "."
Forward Lookup Zone.
Can you ping your gateway from the DNS machine?
 
Read Kevin's response and add the following:

Nslookup always does the "add the domain suffix(es)" to
the name given -- if it's not terminated with a "." (dot.)

This is the client side resolver and is only accidently (through
your setup) related to what your DNS server does (to help
this client resolver.)
 
I have a very similar problem. My DNS server is
NS1.PRONETHOST.COM. When I do a lookup for any domain it
returns the IP address the DNS server is on. If I do a
nslookup on google.com it will return 166.70.205.185
twice. www.Microsoft.com returns 166.70.205.185 many
times. If I use the "set vc" command in nslookup it will
resolve the external and internal names correctly. Also,
the server is running behind a NAT based firewall so if
from my local network I do a nslookup to 10.0.0.3 for
example it will return correct information without having
to use the "set vc" command in nslookup.

Any information on how to fix this would be GREATLY
appreciated!
 
Pinging the gateway works with no problem. The DNS servers
were resolving just fine, but quit just after patching to
Service Pack 4 which may just be a coincidental thing. It
just really disturbs me that DNS resolved without fail for
over a year, but now can't resolve anything.

To take care of resolution for my Dorm network, I ended up
firing up the DNS service on the current DHCP box and set
it up with secondary zones pointed at the original (no
longer resolving external addresses) primary server. It is
resolving externals (with SP4) and taking zone transfers.
The strange thing is that the settings for each of the
servers is identical. I don't have 'Disable Recursive'
checked on any of the systems.

Right now I am debating the idea of rebuilding my original
DNS boxes, but would rather understand the real cause of
the DNS problem.

Ken Blankenship
 
Have you checked your HOSTS file to see if there are entries in there that
don't belong in there? 127.0.0.1 localhost shoud be the only thing in there
unless you added something else in the past.

--
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
Nathan Zaugg said:
HOSTS file looks fine. Hasen't been changed. Any other
ideas?
Click to expand...
Do you have a forwarder set?

Can you provide an example of the nslookup output in your next response?
Just copy if out of the command prompt and paste it here as text. That's
easier than attaching it.

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
 
NZ> If I do a nslookup on google.com it will return
NZ> 166.70.205.185 twice. www.Microsoft.com returns
NZ> 166.70.205.185 many times. [...]

This appears to be the "my NAT box is rewriting all DNS/UDP traffic" problem.
But more information is needed to be sure.

What are the results of the following commands ?

dnsquery -n 195.117.6.25 -t a a.root-servers.orsc.
dnsquery -n 216.239.32.10 -t a www.google.com.
dnsquery -n 193.45.1.76 -t a a562.cd.akamai.net.

(If you don't have either "dnsquery" or "dig", get them from ISC.)

<URL:ftp://ftp.isc.org./isc/bind/contrib/ntbind-9.2.2/>
 
When I tried it with your server, I got the proper responses:
server ns1.pronethost.com
Click to expand...
Default Server: ns1.pronethost.com
Address: 166.70.205.185
google.com
Click to expand...
Server: ns1.pronethost.com
Address: 166.70.205.185

Name: google.com
Addresses: 216.239.53.100, 216.239.37.100

Try enabling Secure Cache Against Pollution in DNS properties. Also like to
see the output from what Jonathan requested. If not familiar with dnsquery,
just use the DIG tool. It's part of the BIND installation. Just download it,
but don't install it as a service. Just want to use the DIG tool out of the
folder.

--
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
 
Thats weird that you got a correct response. I have tried
this from neumerous other clients from a variety of
different networks and providers. Perhaps you have a
special configuration that required auth lookups.

I am not familiar with dnsquery or dig. I can find dig in
BIND installations but I can't find dnsquery anywhere!
Some more spcific information would be helpful. Do you
want me to run this from the server, another computer in
the network, or externally?

I am very intrested in the theory of the NAT firewall
changing my dns packets. It just makes sense logically
except for the fact that I can get a correct response when
I "set vc".

Thanks for your help!
Nathan

-----Original Message-----
When I tried it with your server, I got the proper responses:
Default Server: ns1.pronethost.com
Address: 166.70.205.185

Server: ns1.pronethost.com
Address: 166.70.205.185

Name: google.com
Addresses: 216.239.53.100, 216.239.37.100


Try enabling Secure Cache Against Pollution in DNS properties. Also like to
see the output from what Jonathan requested. If not familiar with dnsquery,
just use the DIG tool. It's part of the BIND
Click to expand...
installation. Just download it,
 
In
Nathan said:
Thats weird that you got a correct response. I have tried
this from neumerous other clients from a variety of
different networks and providers. Perhaps you have a
special configuration that required auth lookups.

I am not familiar with dnsquery or dig. I can find dig in
BIND installations but I can't find dnsquery anywhere!
Some more spcific information would be helpful. Do you
want me to run this from the server, another computer in
the network, or externally?

I am very intrested in the theory of the NAT firewall
changing my dns packets. It just makes sense logically
except for the fact that I can get a correct response when
I "set vc".

Thanks for your help!
Nathan
Click to expand...

I wouldn't say it's weird, just that there are no restrictions on DNS
traffic with my network.

Without going into detail, I have allowed the necessary ports opened to my 2
public DNS servers, including UDP 1024 to 65534. Yes, that is a WIDE range.
But that's how MS DNS works. There's a reg entry to change that, but haven't
had much luck with it as of yet.

I don't understand why you would need to set vc (use a virtual circuit) when
you're doing it. This command FORCES a TCP connection instead of UDP (which
is the normal default initial attempt). So that says you don't have certain
ports opened to the machine(s) you are trying this from. So that may be your
answer because I need to set that at my workstation when using nslookup
since I don't have that wide UDP range open to it. This way it forces it to
use TCP and I get the response back using nslookup.

NAT complicates it a bit. Normally NAT will allow all established back in,
so when you do queries or anything else, the response comes back. So
nslookup just works. Initial connection attempts aren't allowed in (like
running mail or DNS servers, etc) unless you create a port-remap to allow
that back in. But only one port to one internal IP is allowed. Can't have
mutliple IPs to one port, which is a restriction saying you can only run one
of a kind service internally. Only exception is web services only if using a
Proxy or ISA server and iwth that you can port remap by host header. So if
you're running a public DNS server, you can only run one if behind a NAT.

Dnsquery is something Jonathan wrote and works on OS2Warp and I believe on
*nix versions, but not Windows. Dig is a nice tool as an alternative to
nslookup. No matter what you're running as a tool, you should still get some
sort of response unless something is being BLOCKED!!!


--
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
 
JdeBP*> dig @195.117.6.25 a.root-servers.orsc. a
JdeBP*> dig @216.239.32.10 www.google.com. a
JdeBP*> dig @193.45.1.76 a562.cd.akamai.net. a

N> Do you want me to run this from the server, another
N> computer in the network, or externally?

Run them on the machine that is running your DNS server.

N> I am very intrested in the theory of the NAT firewall
N> changing my dns packets.

<URL:http://cisco.com./warp/public/110/alias.html>
 
AF> Dnsquery is something Jonathan wrote and works on OS2Warp [...]

No. _My_ tool is DNSQRY (note the spelling). "dnsquery" is one of the
several DNS diagnosis tools that comes with ISC's BIND. (It's under "bin" in
version 8. I vaguely recall that it was under "contrib" in version 4. I
haven't checked version 9.)

I've given the "dig" equivalents of the "dnsquery" commands in another post.
 
In
Jonathan de Boyne Pollard said:
Dnsquery is something Jonathan wrote and works on OS2Warp [...]
Click to expand...

No. _My_ tool is DNSQRY (note the spelling). "dnsquery" is one of
the several DNS diagnosis tools that comes with ISC's BIND. (It's
under "bin" in version 8. I vaguely recall that it was under
"contrib" in version 4. I haven't checked version 9.)

I've given the "dig" equivalents of the "dnsquery" commands in
another post.
Click to expand...

Oops. Sorry, another one of my misspellings!

--
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
 
JdeBP*> dig @195.117.6.25 a.root-servers.orsc. a
JdeBP*> dig @216.239.32.10 www.google.com. a
JdeBP*> dig @193.45.1.76 a562.cd.akamai.net. a
Click to expand...

Here are the responses to those queries:
C:\Documents and Settings\Administrator\Desktop\New
Folder>dig @195.117.6.25 a.r
oot-servers.orsc. a

; <<>> DiG 8.3 <<>> @195.117.6.25 a.root-servers.orsc. a
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3,
ADDITIONAL: 4
;; QUERY SECTION:
;; a.root-servers.orsc, type = A, class = IN

;; ANSWER SECTION:
a.root-servers.orsc. 2D IN A 199.166.24.12

;; AUTHORITY SECTION:
ORSC. 2D IN NS ns1.vrx.net.
ORSC. 2D IN NS mejac.palo-
alto.ca.us.
ORSC. 2D IN NS ns1.jerky.net.

;; ADDITIONAL SECTION:
ns1.vrx.net. 2D IN A 199.166.24.1
ns1.vrx.net. 2D IN A 199.166.27.6
mejac.palo-alto.ca.us. 5m18s IN A 192.147.236.1
ns1.jerky.net. 12H IN A 204.57.55.100

;; Total query time: 1000 msec
;; FROM: neo to SERVER: 195.117.6.25 195.117.6.25
;; WHEN: Sun Sep 14 13:44:26 2003
;; MSG SIZE sent: 37 rcvd: 205

C:\Documents and Settings\Administrator\Desktop\New
Folder>dig @216.239.32.10 ww
w.google.com. a

; <<>> DiG 8.3 <<>> @216.239.32.10 www.google.com. a
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4,
ADDITIONAL: 4
;; QUERY SECTION:
;; www.google.com, type = A, class = IN

;; ANSWER SECTION:
www.google.com. 5M IN A 216.239.33.99

;; AUTHORITY SECTION:
google.com. 4D IN NS ns1.google.com.
google.com. 4D IN NS ns2.google.com.
google.com. 4D IN NS ns3.google.com.
google.com. 4D IN NS ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com. 4D IN A 216.239.32.10
ns2.google.com. 4D IN A 216.239.34.10
ns3.google.com. 4D IN A 216.239.36.10
ns4.google.com. 4D IN A 216.239.38.10

;; Total query time: 1000 msec
;; FROM: neo to SERVER: 216.239.32.10 216.239.32.10
;; WHEN: Sun Sep 14 13:45:20 2003
;; MSG SIZE sent: 32 rcvd: 184

C:\Documents and Settings\Administrator\Desktop\New
Folder>dig @193.45.1.76 a562
..cd.akamai.net. a

; <<>> DiG 8.3 <<>> @193.45.1.76 a562.cd.akamai.net. a
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0,
ADDITIONAL: 0
;; QUERY SECTION:
;; a562.cd.akamai.net, type = A, class = IN

;; ANSWER SECTION:
a562.cd.akamai.net. 20S IN A 206.112.112.5
a562.cd.akamai.net. 20S IN A 206.112.112.14
a562.cd.akamai.net. 20S IN A 206.112.112.15
a562.cd.akamai.net. 20S IN A 206.112.112.13

;; Total query time: 0 msec
;; FROM: neo to SERVER: 193.45.1.76 193.45.1.76
;; WHEN: Sun Sep 14 13:45:52 2003
;; MSG SIZE sent: 36 rcvd: 100

I do think it likely that some udp port is being blocked,
though I do have a range of 5 IP addresses useable for DNS
behind the NAT firewall/router so I should be able to
configure it correctly. Opening up all of those ports
makes me REALLY nervious though.

--Nathan
 
In
Nathan said:
Here are the responses to those queries:
C:\Documents and Settings\Administrator\Desktop\New
Folder>dig @195.117.6.25 a.r
oot-servers.orsc. a

; <<>> DiG 8.3 <<>> @195.117.6.25 a.root-servers.orsc. a
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3,
ADDITIONAL: 4
;; QUERY SECTION:
;; a.root-servers.orsc, type = A, class = IN

;; ANSWER SECTION:
a.root-servers.orsc. 2D IN A 199.166.24.12

;; AUTHORITY SECTION:
ORSC. 2D IN NS ns1.vrx.net.
ORSC. 2D IN NS mejac.palo-
alto.ca.us.
ORSC. 2D IN NS ns1.jerky.net.

;; ADDITIONAL SECTION:
ns1.vrx.net. 2D IN A 199.166.24.1
ns1.vrx.net. 2D IN A 199.166.27.6
mejac.palo-alto.ca.us. 5m18s IN A 192.147.236.1
ns1.jerky.net. 12H IN A 204.57.55.100

;; Total query time: 1000 msec
;; FROM: neo to SERVER: 195.117.6.25 195.117.6.25
;; WHEN: Sun Sep 14 13:44:26 2003
;; MSG SIZE sent: 37 rcvd: 205
Click to expand...

--Nathan
Click to expand...

The Digs look fine. Here's my result for the first query below. Notice, that
since I don't have UDP 1024 to 65534 open to this workstation, so I had to
use the +vc option.

===================================
; <<>> DiG 9.2.2rc1 <<>> @195.117.6.25 a.root-servers.orsc. a +vc
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;a.root-servers.orsc. IN A

;; ANSWER SECTION:
a.root-servers.orsc. 172800 IN A 199.166.24.12

;; AUTHORITY SECTION:
ORSC. 172800 IN NS ns1.vrx.net.
ORSC. 172800 IN NS mejac.palo-alto.ca.us.
ORSC. 172800 IN NS ns1.jerky.net.

;; ADDITIONAL SECTION:
ns1.vrx.net. 172800 IN A 199.166.24.1
ns1.vrx.net. 172800 IN A 199.166.27.6
mejac.palo-alto.ca.us. 318 IN A 192.147.236.1
ns1.jerky.net. 43200 IN A 204.57.55.100

;; Query time: 296 msec
;; SERVER: 195.117.6.25#53(195.117.6.25)
;; WHEN: Sun Sep 14 21:04:00 2003
;; MSG SIZE rcvd: 205
===================================


So that kind of tells me that your ports are fine, at least to this machine
you did the query on.

By chance, did you ever enable the "Secure Cache Against Pollution" option?


--
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
 
By chance, did you ever enable the "Secure Cache Against
Click to expand...
Pollution" option?

Yes, that has always been enabled. I will continue
exploring the possibility of ports not being open because
thats the best lead I have so far. Though, it doesn't
explain a lot. I guess I am still looking for a solution.

--Nathan
 
In
Nathan said:
Yes, that has always been enabled. I will continue
exploring the possibility of ports not being open because
thats the best lead I have so far. Though, it doesn't
explain a lot. I guess I am still looking for a solution.

--Nathan
Click to expand...

So it's still giving you back the 166.x.x.x numbers?

Also, see if you can open up your firewall just for a few minutes and try it
again.


--
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
 
JdeBP*> dig @195.117.6.25 a.root-servers.orsc. a
JdeBP*> dig @216.239.32.10 www.google.com. a
JdeBP*> dig @193.45.1.76 a562.cd.akamai.net. a

N> Here are the responses to those queries:

Good. They weren't mangled.

Now ensure that your DNS server (running on that machine) isn't forwarding
queries, and then run the same commands, on that same machine, but without the
'@' arguments. You can then compare the answers obtained via your proxy DNS
service with the answers obtained directly from the content DNS servers.

If they are essentially the same, the next stop is to ensure that your other
machines receive the same responses that you receive locally. Run the
commands, still without the '@' arguments, on one of your other machines.

If they are essentially different, the next stop is to look carefully at your
DNS server's configuration.
 
Back
Top