limiting external visibility - without resorting to views.

Tim Peiffer peiffer at
Sun Mar 27 05:03:09 UTC 2005

Jim Reid wrote:

>>>>>>"Tim" == Tim Peiffer <peiffer at> 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  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
>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