> > Its more dependable than trying to depend on some type of cookie hidden in
> > areas that arent guaranteed to come back unmangled
>
> Perhaps we're not in sync with each other. I get the impression that my
> "cookie" idea (probably because I use the term "cookie" to describe it) is
> being assumed to be something more complicated than it is.
>
> All the "cookie" consists of is a totally standard DNS query. It could
> just as easily be an A record query for SPLOITS.CERT.ORG as it could be a
> type 212, class 13 query for DF97H37F74H4H3778FGH3F747.74TF784GF84GF4. The
> point, of course, is simply that it's not trivial to guess, and we'll only
> get a response back if the server we query is alive.
>
> Under what circumstances would a 1 question nonrecursive query ever be
> "mangled"? Is there a nameserver out there that destroys the question
> section of DNS packets?
Ah, I had believed you were trying to piggy back the query in the same
packet as the first one. If they are sent separate, and your cookie is set
nonrecursive, then you are right, it should return unmangled, unless the
packet gets lost along the way somehow. The reason I say this will
introduce latency is because obviously to accept a response you must wait
for the second query to return, which first of all gives two packets we
must wait for the return of, on top of a slightly extra amount of
traffic... And for busy nameservers that are ALWAYS sending out cookies,
this can add up, causing some serious speed problems (ie. any busy
ISP/WPP)
> If the TCP connection fails, it will never work. There's a chance that it
> will fail, because servers don't necessarilly *have* to allow TCP DNS
> (firewall configurations, for instance, might make this impossible).
>From the comp.protocols.tcp-ip.domains FAQ available via www.isc.org:
Q: Does anyone out there have any information/experience on exactly which
TCP/UDP ports DNS uses to send and receive queries ?
[..nice chart, etc..]
Also, ALL versions of BIND use TCP for queries in some cases. The
original query is tried using UDP. If the response is longer than the
allocated buffer, the resolver will retry the query using a TCP
connection. If you block access to TCP port 53, you may find that some
things don't work.
So, as you can see, if you HAVE been configuring your firewalls to block
tcp port 53, you are breaking bind. If you are doing that to prevent zone
transfers, then you are doing it wrong, since that can be sent over UDP as
well. Besides, you can configure a list of IPs to allow zone transfers to
in the config file. But I admit, not everyone who's setting up a firewall
takes caution not to break inside services. In those cases we cant do
anything about not reaching tcp port 53, and a udp type of authentication
would be more favorable..
Perhaps your cookie method could be a fallback if the tcp connect fails..
That way we dont have to generate extra traffic unless we need to. And
once an attempted spoof is noticed, it can flag those domain servers as
dangerous, and use tcp/cookies for all subsequent queries to prevent any
more chances for spoofing.
> On the other hand, nothing should cause a simple UDP query to fail. It
> also doesn't require connection setup (how will this affect latency?).
It will affect latency because you will have to wait for the second reply
containing the cookie.. So it wouldnt be something you would want to
configure on a very busy nameserver (especially one that's losing
packets).
> That doesn't work. This is a blind attack. I can make the queries come
> from wherever I want them to. Eliminating recursive queries is not, from
> what I can see, a valid solution to this problem. Am I wrong?
Of course it will not prevent an attacker from continually bombarding us
with spoofed replies.. But his only reward will be that we are forced to
contact some DNS servers via TCP or with cookies.
> > TCP-ready BIND servers are probably 99% of the internet. However, if you
>
> I don't set firewalls up to accept incoming TCP connections to port 53. At
> the very least, every firewall I've configured is now broken.
Yep. You shouldn't block access to a vast majority of ports and then
expect all of the servers to function as expected. Sometimes it takes a
little bit of reading and some tcpdump watching
> You seem to think that there's alot of weirdness happening here. I don't
> think there is. Can you come up with some specific things that can cause
> weird failures? I'm not doing *anything* weird with DNS packets - I'm just
> sending queries for information I don't care about.
Well, you are using the packets for a purpose that bind was not built for.
But once again, if it proves to be more reliable, then it is the superior
solution (only testing will tell).. We also arent restricted from trying
both safeguards.
> However, I have to grant you that if a TCP connection is successful,
> you've eliminated the problem entirely - you just finish the request over
> TCP, and you know that you're getting reasonably authentic information
> back.
>
> Unless, of course, I can predict the sequence numbers involved in setting
> up the connection, or otherwise subvert the connection to fail or be
> spoofed...
That would be a problem with the tcp/ip implementation. If connections
can be spoofed to the target, then they have far worse problems.
> > what do you do if a server doesnt return your cookies? Return a failure?
>
> If a server doesn't return my cookies, it's dead. Try the next server.
> Continue until SERVFAIL.
Same here.. There is nothing that we can do if the nameservers we are
querying are dead, unless you want to make bind fax the domain owners a
sheet that says they are under attack..
> Again, we now have denial-of-service coupled with security; the attack
> only needs to work once.
Wrong: it will need to work each time someone queries for a hostname in
that domain, since the server will be intelligent and not cache hosts as
nonexistent if the nameservers are unreacheable. So the attacker would
need to maintain a steady stream of packets to deny access to the
nameservers, at which point we can try your cookie method.
However, if someone wanted to deny access to a nameserver, all he would
need to do is send several recursive queries to resolve addresses that
belong to unreacheable name servers. DOS on the remote end is something
we on the local end can't prevent, unless we force everyone on the
internet to upgrade their servers.
Hopefully though, the important domains will. All they have to do is block
packets that appear to come from the inside from travel in through an
outside gateway (hopefully this is standard practice by now), and not
allow recursive queries from outside IPs. If we had totalitarian control
over the internet, maybe we could do something about this. However, since
we dont, all I'm worried about is maintaining security on the local end.
And returning a failure because a server is indeed DOWN is something we
can't prevent.
> > that is being blocked. So the problem no longer lies in your nameserver,
> > it is now a problem of the site being blocked for whatever reason, and
> > would have to be fixed on that end. What else can be done on our end?
>
> Our security shouldn't rely on any site's servers working.
"Our security" does not. The simple fact is we can't do anything about
unreacheable nameservers. Unless you want to try the fax idea
-vermont@gate.net