limiting external visibility - without resorting to views.

[Tim Peiffer]

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.
>
>  
>