Help Understanding Cache Poisoining

[Will]

"Peter Dambier" <peter at peter-dambier.de> wrote in message
news:eka400$1033$1 at sf1.isc.org...
> Will wrote:
> > Can someone explain to me if an ISP has misconfigured their public DNS
to
> > allow outsiders to do recursive queries on the server, how does that
make
> > possible cache poisoining of zones for which the ISP is primary?
>
> You do not need an outsider to poison your ISPs cache. An insider can do
> as well.

Okay, that's clear, I guess it's a question of commercial responsibilities.
If an ISP configures access to the recursive DNS through his firewall only
for his paying customers, and one of those customers has a hacker that
poisons the cache, the ISP can rightly exercise some leverage with the
customer to clean up that situation.   An ISP that has an open DNS can't
even identify the hackers in many cases, and there is no one to contact
often.    So it's more a question of percentages that an open dns is going
to suffer from this problem, and have a much harder time resolving it when
it happens if they choose to leave the DNS open.


> The machine you are querying normally is a resolver, and the resolver you
> can poison.

But the question was *how* does that poisoining happen?    I see how a
hacker can do a denial of service attack, but not how they can get the
resolver to enter in bad values.


> My advice, if you want to be save then never use your ISPs resolver or
> somebody elses. Build your own resolver. Let this resolver only answer
> to queries from inside, never from outside.

It sounds right, but here is what is happening to us:   about 80% of our
lookups to open DNS servers don't get any response.    We have no problems
resolving domains with properly configured DNS, but the ones that are open
we simply get back no responses 80% of the time.   That plays havoc with our
outgoing mail infrastructure, and it disallows us from using blocks on non
resolving domains for incoming e-mail.

When we use the ISP as a forwarder, everything works.  Perhaps their cache
is better; perhaps it is a routing problem.   I see the packets leave our
firewall's external firewall with a packet sniffer, so it's not a firewall
problem.

-- 
Will