limiting external visibility - without resorting to views.

[Jim Reid]

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

    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. 

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