internal dns can not resolve sometime

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I just inherit this problem please bear with me, We our running internal
windows 2000 DNS and sometime client can not get to a specific website which
they already view before. To resolve this problem, I simply restart the DNS
and it will work fine.But it's becoming everyday problem. I check the root
hints and it's pointing to our ISP's DNS address. We are also using a
firewall.

Any suggestions what's going on? Thank you in advance.
 
Root hints should be left as they come -- pointing to
the root InterNIC servers. It/they absolutely should not
be pointing to your ISPs DNS.

Try restoring the original root hints, then disable
forwarding and see if that fixes it.

Steve Duff, MCSE, MVP
Ergodic Systems, Inc.
 
How do you restore the original root hints? I also noticed that we dont have
the "." forward lookup zone.

Thank you in advance
 
In
JOey said:
How do you restore the original root hints? I also
noticed that we dont have
the "." forward lookup zone.
Click to expand...

Replace the cache.dns file with a good one. Or you can manually edit them
from the Root Hints tab.
Here are the ICANN Roots.
A.ROOT-SERVERS.NET. 603517 IN A 198.41.0.4
B.ROOT-SERVERS.NET. 603743 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 598590 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 598590 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 603744 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 598590 IN A 192.5.5.241
G.ROOT-SERVERS.NET. 603744 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 603743 IN A 128.63.2.53
I.ROOT-SERVERS.NET. 598591 IN A 192.36.148.17
J.ROOT-SERVERS.NET. 551821 IN A 192.58.128.30
K.ROOT-SERVERS.NET. 598591 IN A 193.0.14.129
L.ROOT-SERVERS.NET. 598590 IN A 198.32.64.12
M.ROOT-SERVERS.NET. 598590 IN A 202.12.27.33
 
You don't want a "." zone. That would make your
server believe it is a root server and prevent any type
of outside name resolution.

The original DNS root hints should be in
%windir%\system32\dns\samples, in the file cache.dns.
If not here it is below. I believe if you just replace the
active cache.dns in \dns with this one and restart
the DNS server service it will take.


Cheers

Steve Duff, MCSE, MVP
Ergodic Systems, Inc.

;;;;;;;;;;;;;;;;;;CACHE.DNS follows;;;;;;;;;;;;;;;;;;;;
;
; cache.dns -- DNS CACHE FILE
;
; Initial cache data for root domain servers.
;
; YOU SHOULD CHANGE:
; -> Nothing if connected to the Internet. Edit this file only when
; updated root name server list is released.
; OR
; -> If NOT connected to the Internet, remove these records and replace
; with NS and A records for the DNS server authoritative for the
; root domain at your site.
;
; Note, if you are a root domain server, for your own private intranet,
; no cache is required, and you may edit your boot file to remove
; it.
;

; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC
; under anonymous FTP as
; file /domain/named.root
; on server FTP.INTERNIC.NET
;
; last update: Nov 5, 2002
; related version of root zone: 2002110501
;
;
; formerly NS.INTERNIC.NET
;
.. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
.. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
.. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
.. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
.. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
.. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
.. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; operated by VeriSign, Inc.
;
.. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
;
; housed in LINX, operated by RIPE NCC
;
.. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; operated by IANA
;
.. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
.. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File
 
J> I check the root hints and it's pointing to our ISP's DNS address.

That's probably (depending from what type of DNS service your ISP is
providing) harmless. However, one should only do that sort of thing
with good reason. (Running one's own private root content DNS servers
is one such good reason, for example. That's unlikely to be the case
here.) If you don't have a reason, don't do it and stick to using one
of the sets of public root content DNS servers.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-updating-resolving-proxy-root-list.html>

J> We are also using a firewall.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-shaped-firewall-holes.html>

J> Any suggestions what's going on?

There can be none. It could be any of a wide range of things, some of
which wouldn't even be your problem at all. Any suggestions that you
receive will be little more than random guesses. You haven't provided
anywhere near enough information for problem diagnosis. For starters,
you can provide examples of both successful and failing lookups.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/problem-report-standard-litany.html>
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dont-obscure-your-dns-data.html>
 
SD> It/they absolutely should not be pointing to your ISPs DNS.

As I said, it's probably harmless. If the hints are pointing to the
ISP-provided proxy DNS servers, his server will happily locate the root
content DNS servers. It will simply be that it will locate whatever set
of root content DNS servers his ISP decides to use. He will have
abnegated his choice of roots, relying upon his ISP to make that choice
for him.

<URL:http://homepages.tesco.net./~J.deBo...ting-resolving-proxy-root-list.html#Microsoft>

Of course, if the hints are pointing to the ISP's content DNS servers,
and those content DNS servers aren't publishing anything about the root
(which content DNS servers are not obliged to do, of course), then his
server will not be able to locate the root content DNS servers, and his
system will only work if query forwarding has also been configured. In
which case, yet further aetiologies of his problem present themselves.
 
Back
Top