North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: DNS cache poisoning attacks -- are they real?
- From: Joe Maimon
- Date: Tue Mar 29 23:24:24 2005
I suspect and google confirms, that you know a whole lot more about this
than I do, so please have a little patience explaining this to me.
Brad Knowles wrote:
Why would this not work against the procedure as originaly described?
At 8:49 AM -0500 2005-03-29, Joe Maimon wrote:
1) Registrars being required to verify Authority in delegated to
nameservers (will this break any appreciated valid models?) before
activating/changing delegation for zone.<REAL FIX>
Okay, so the spammers make the data appear valid just long enough to
pass the test, then they go back to their wily ways. Not a real fix.
Step 1) Spammers register Domain and delegate it to nameserver that
respond with AA set for domain.
Step 2) Registrar activated delegation due to Authority response from
Step 3) Spammers seed recursive resolvers
Step 4) Spammers change delegation by registrar to seeded resolvers
Step 5) Change fails because Registrar check Authority from seeded
resolvers and does not get it.
How do spammers make step 5 succeed?
What I meant is that when a server attempts to seed its cache and it
encounters lameness it should not attempt to obtain it from any other
servers. Perhaps it should return the answer but not cache it (or cache
with forced small TTL).
2) Stricter settings as regards to all lame delegations -- SERVFAIL by
default without recursion/caching attempts?
You'd have the caching server check the name of the zone to see if
it is claimed as an NS record, even when it's just caching/recursive?
Now, tell me how they'd do this at all the sites on the Internet, since
we assume that the data advertised may change at any moment?
Now lameness is something that the server SHOULD see when it attempts to
recursively resolve the name without extra effort.
I am suggesting that the server can semi-reliably detect that the parent
soa hasnt aimed the ns record for the subzone at it. It would verify its
cache contents every X before sending on the answers it has. It should
purge from cache anytime the check reveals that the parent zone has an
NS aimed at it for the cache contents -- which should be a clear
indication of cache hijacking.
In terms of running a caching/recursive server, I don't think
there's any way to reliably detect that someone has aimed an NS record
at you. That would be like asking how you know, a prior, whether or not
www.youareadamnedbloodyfool.com is a now CNAME record for your webserver.
Or perhaps servers should check periodicaly for all kinds of lameness of
the cached contents. This would prevent practical usage of a technique
where spammers spray-seed all resolvers they can with large TTL's so
that the resolvers users see them for quite some time irregardless of
registrars/parent zone's actions.
3) Paranoid checking for situations such as these by having recursing
nameservers attempt to periodically check for suspicous NS and glue from
the parent zone's POV and compare it to cache, trashing cached records
if they do not like result.
How do they know who their claimed "parent" is, when someone aims a
totally bogus NS record at them? Do you ask them to walk the entire DNS
tree throughout the entire Internet?
And thats so hard? Servers do this all the time fairly often.
So far nobody here has said that they are either neccessary or evil --
'cept for you and chris on the evil part.
An open recursive/caching nameserver is like an open mail relay.
There may be some people who stubbornly insist that they are a necessary
evil -- feel free to become the next toad.com if you like. There may be
a lot of people who have one but don't know it.
But they are evil, and I believe that they should be eliminated.
As to that, I cant credit the resulting evilness you paint as evil as
open mail servers became, not because open mail-relay servers were
intrinsically so but because they become so very attractive to all the
evil users out there.
For a real life example of an open-relay mail server, walk to your
nearest corner and see the maildrop that takes mail from anybody and
delivers it to anyone else.
A commandeered open-relay server is spewing garbage to its victims.
A commandeered open-recursion server, while not a good thing, is hardly
doing the same - in most cases described here its simply perpetuating a
domain name far longer than POLICY reasons would like. This was probably
a designed for feature, for example keeping panix.com going strong for
the lucky one due to cached large NS TTLS would have been viewed as a
good thing at the time.
Furthermore, as others have pointed out, eliminating the openness of
these resolvers would simply force a push to have spammers trojan armies
seek 'n' seed the resolvers they can recurse from.
Due to the nature of this game, the larger client base the resolver
serves, the better the chances of it getting seeded. These would be the
same resolvers targetted were they open. And as others have pointed out,
once an answer is in cache, its not considered recursion and different
access control needs to be applied.