limiting external visibility - without resorting to views.
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
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
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
> 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