Spooky DNS problem

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

Guest

I have two W2K DNS servers (dns1 and dns2) to support AD (standard zones, not
AD-integrated) and to resolve Internet names via forwarders. Each is
configured with forwarders to our ISP's two DNS servers. Internal clients
point to dns1 first and then dns2. I have had several instances where a user
is trying to access a web site and the page that loads is afternic.com (not
the requested page) and it indicates that the requested domain is for sale.
I examine our DNS server's cache and see that our DNS server does not have
the correct host record for the requested URL. I compare this to a lab
machine that uses a different DNS server and I can successfully navigate to
the requested URL from this machine. I clear the DNS server cache and run
ipconfig /flushdns and both the user and I can successfully navigate to the
requested URL.

If I understand how DNS and forwarders work correctly, the only zones the
DNS servers "know" are the forward and reverse lookup zones that I have
configured. Everything else it "learns" from the DNS server configured as
forwarders (our ISP's DNS servers). After the TTL for the records expire,
the DNS server "forgets" what it "learned".

It appears that our DNS servers are "learning" an incorrect ip address for
the requested URL . That is hard to believe since we are using a Tier-1 ISP.

Can anyone shed some light on what might be happening here?

Thanks in advance for your help.

McR
 
There really is nothing hard to believe about this. DNS problems are not
limited to small-fry organizations.

You are basically correct in your description of how you expect a forwarding
DNS to behave with regards to cache, although there are ways to make a
forwarding server "unlearn" things pretty fast. As for the "why" of the
issue you are seeing, the first thing that comes to mind is that this may be
happening on your ISP's side. I would stop forwarding for a while, restart
DNS service and monitor the server to see if the problem comes back. While
you are at it, make sure that the option to protect against "cache
pollution" is enabled on your DNS server.

--


Sincerely,

Dèjì Akómöláfé, MCSE+M MCSA+M MCP+I
Microsoft MVP - Directory Services
www.readymaids.com - we know IT
www.akomolafe.com
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
 
In Deji Akomolafe <[email protected]> made a post then I commented below
:: There really is nothing hard to believe about this. DNS problems are
:: not limited to small-fry organizations.
::
:: You are basically correct in your description of how you expect a
:: forwarding DNS to behave with regards to cache, although there are
:: ways to make a forwarding server "unlearn" things pretty fast. As
:: for the "why" of the issue you are seeing, the first thing that
:: comes to mind is that this may be happening on your ISP's side. I
:: would stop forwarding for a while, restart DNS service and monitor
:: the server to see if the problem comes back. While you are at it,
:: make sure that the option to protect against "cache pollution" is
:: enabled on your DNS server.


I would also suggest to check the HOSTS file for possible hijacking or a
BHO.


--
Regards,
Ace

G O E A G L E S !!!
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 - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
Deji, thanks for your reply. Is what I am describing referred to as "DNS
cache poisoning"? I have read a little about it in response to these events.
If I understand correctly, DNS cache poisoning is when someone maliciously
intercepts the forwarded request from my DNS server to my ISP's DNS server
and substitutes an IP address of their choice and responds to my DNS server's
forwarded query. Is that correct? In your experience, is this rare or does
it happen often, just not to me? Our ISP is AT&T and I guess I thought their
DNS servers were protected from such attacks but it is actually the
communication from my DNS server to theirs that is being compromised (as DNS
has no authentication mechanism). I do have the cache pollution option
enabled on both servers (thanks for the tip). In your opinion, is the best
way to deal with this to take the steps I have taken by flushing the DNS
cache and the local cach on the client?
Thanks for the brainpower...
McR
 
mcron said:
Deji, thanks for your reply. Is what I am describing referred to as "DNS
cache poisoning"? I have read a little about it in response to these events.
If I understand correctly, DNS cache poisoning is when someone maliciously
intercepts the forwarded request from my DNS server to my ISP's DNS server
and substitutes an IP address of their choice and responds to my DNS server's
forwarded query. Is that correct? In your experience, is this rare or does
it happen often, just not to me? Our ISP is AT&T and I guess I thought their
DNS servers were protected from such attacks but it is actually the
Click to expand...

Deji likely knows more about this than I do but
that is not my understand of the USUAL mechanism
of "cache poisoing" -- although your example would
also be possible.

Cache poisoning is much more likely this way:

1) You query some arbitrary DNS server for a resolution
e.g., www.EvilHackers.com (perfectly normal,
happens all the time with users visiting web pages or
even receiving HTML email)

2) The DNS server for EvilHackers.com sends back the
answer AND it also loads some unrequested resolutions:
www.Microsoft.com = somethere really bad
windowsupdate.microsoft.com = somewhere worse

3) Evil <GRIN> goes here

Without protection from cache poisoning the DNS server accepts
and caches those UNREQUESTED resolutions. (This was done
in the past when everyone still trusted everyone on the Internet.)

With cache polution protection, the unrequested resolutions are
discarded.
 
Herb, thanks for the additional example. In your scenario, is it true that
the malicious response would come from the DNS server for EvilHackers.com?
After my last post I realized that the DNS query being intercepted might not
be the one from my DNS server to our ISP but (more likely) the query from our
ISP's DNS server on up.
At the end of the day, is it fair to say that there is no guarantee that any
DNS query to the Internet will result in a valid response?
Thanks again,
McR
 
mcron said:
Herb, thanks for the additional example. In your scenario, is it true that
the malicious response would come from the DNS server for EvilHackers.com?
Click to expand...

Yes, or any server in the referral chain -- i.e., a
forwarder or parent of that domain.

Realistically, it's not likely that one of your chosen
forwarders or a top level domain DNS would do this
(maliciously).

The real danger is the EvilHackers.com DNS server,
OR a server that has been taken over by hackers at

newbieDNSadmins.com

Or even OldHandsCantHappentome.com said:
After my last post I realized that the DNS query being intercepted might not
be the one from my DNS server to our ISP but (more likely) the query from our
ISP's DNS server on up.
Click to expand...

The interception can still happen but isn't as likely
as say the following:

DNS request to ns1.InnocousDomain.com

Hacker responds QUICKLY with packet containing
pollution.

Since this is (probably) all UDP, not connection
required and wouldn't matter anyway problably.

Why would that work? ANYONE (including virus
and trojan infected machines) at Innocuous.com or
anywhere else on the path to them could make such
a response.
At the end of the day, is it fair to say that there is no guarantee that any
DNS query to the Internet will result in a valid response?
Click to expand...

No. Except in the sense that NO IP traffic is reliable
unless it is authenticated with some sort of security
like IPSec.

But, a response could be returned from an infected
(or just malicious machine) at your ISP as you originally
indicated -- it just isn't as likely.

IP in general, UDP in specific (and TCP is not really
better) is NOT authenticated.
 
Back
Top