limiting external visibility - without resorting to views.
Tim Peiffer
peiffer at umn.edu
Sun Mar 27 05:03:09 UTC 2005
Jim Reid wrote:
>>>>>>"Tim" == Tim Peiffer <peiffer at umn.edu> writes:
>>>>>>
>>>>>>
>
> Tim> I am interested in limiting the visibility of my nameservers
> Tim> to the extent that I do not want to answer external queries
> Tim> from my cache. What are the methods of control other than
> Tim> allow-query, allow-recursion?
>
>That's it. Though you could maybe do something with a firewall that
>can filter DNS packets from outside that happen to be queries for
>non-local names.
>
>
Please elaborate on firewalling based upon DNS query content.
> Tim> I have ACL'ed 'allow-query' and 'allow-recursion' at the
> Tim> global option level, and have 'allow-query' as a per-zone
> Tim> option set to 'any'.
>
>This is just fine. If the global ACLs are done properly -- ie every
>non-local net -- nobody can query or use your name servers, except for
>the local zones. Which is how things should be. An ACL for a
>global allow-recursion statement restricting recursive queries to the
>local network might well be enough on its own. This wouldn't stop
>outside clients making non-recursive queries for stuff in your
>server's caches. It's highly unlikely anyone would do something
>like that. Apart perhaps from off-site idiot forwarding servers who
>shouldn't be freeloading on your DNS infrastructure anyway.
>
>
This is exactly the behaviour that I am trying to curtail. I blackholed
for a while and found it a losing battle against the DDOS that asks for
www.yahoo.com. The fact that I answer at all is what keeps the outside
DDOS yahoo's using us. If we are well connected and have a pretty beefy
infrastructure, I believe it is fairly easy to flood a small .com off
the wire (all with 53/udp responses). I wish not to be used as DDOS
amplification instrument.
How does one ACL the non-local zones (that I am not authorative for)? I
believe it to be syntactically correct to create a forward zone for
.com, .net. .biz, .info, etc. and ACL the zones, yet I seem to remember
seeing something in the code that says that allow-query is not allowed
for forward zones. Are there any example configurations that are legal
for this sort
of behaviour that anyone is willing to share?
> Tim> I have thought about removing the root hints as well, but not
> Tim> 100% sure of the outcome.
>
>Leave it alone. Your name server needs this to find the root servers
>at start-up. [Although BIND9 has a compiled-in hints list for the root
>servers, it's better that the server gets this info from a file. Updating
>the file is easier than recompiling BIND....] Without knowledge of the
>root of the DNS, your name servers would be unable to resolve
>non-local names.
>
> Tim> Specifically, I want to restrict
> Tim> external use of my servers without resorting to 'views'. I
> Tim> have members of our staff that are not comfortable with views
> Tim> at scale; scale being ~50Million transactions/day/server
>
>Well views don't help much for the scenario you describe. They are a
>way of partitioning name spaces based on source/destination query
>address. ie You define inside and outside name spaces for umn.edu.
>Users on the campus nets see the inside, those on the rest of the
>internet see the outside view. If you setup views, you'd probably
>still want to control whether external users got recursive service
>from your name servers or not. Which brings you right back to the
>allow-query and allow-recursion ACLs.
>
>If you have colleagues who are uncomfortable with views, ask them to
>produce hard data supporting their position. Or setup a testbed to see
>what impact introducing views would have on your DNS infrastructure.
>Remember the famous scientific quote "To measure is to know"? BTW 50M
>queries a day per server seems very high. That said, it averages out
>
>
The discomfort with views follows many of the earlier BIND9.x
problems with assert(). Besides, as you observe, views are not
appropriate for what I wish to achieve.
I average 50M/day across both of my campus servers. With one server
out, I would expect the remaining one to carry full load. And my stats
indicate approx 1100 transactions (550 qps?) across both campus servers.
>around 600qps per server which is well within the capabilities of BIND
>on reasonable hardware. Most root servers run BIND and get a sustained
>load of around 5-10,000qps. Though they of course don't offer
>recursive service to anyone.
>
> Tim> I am currently putting together an anycast service using
> Tim> Bind9.3.1, setting up the masters as authoritative only, with
> Tim> the anycast running from cache-only. I could wait until I
> Tim> complete my anycast service and my masters are split out to
> Tim> ACL the cache servers to on-campus only.
>
>Splitting the authoritative and cacheing-only servers is a very good
>idea. So is using anycasting.
>
>
>
More information about the bind-users
mailing list