Well, I wouldn't consider the use of OS-level magic to solve a
DNS-specific problem (or meet a DNS-specific business requirement) to be
solving problems in the right "space" at all. Quite the opposite. It
smacks of a layer violation (the OS being considered as lower-level,
layer-wise, than the DNS subsystem).
Layer violation aside, though, in practical terms, while maybe there are
a few server-centric options from which to choose with respect to
match-destinations-based virtualization of the DNS database -- use
views, separate named instances on the same server with non-overlapping
listen-on's, separate (physical or virtual) OS instances -- what about
match-clients-based virtualization? That involves big-picture
considerations beyond just those focused on to the server side of the
DNS transaction -- client configuration/management and name-resolution
architecture. Does one go out and (re-)configure different communities
of clients to point to different resolver addresses? Even with DHCP
(*assuming* that it's centrally-managed, and *assuming* good
communication and co-ordination between the DNS and DHCP groups, if
separate), there are still going to be clients that don't use DHCP for
resolver configuration. Manually configure those? And even where DHCP
can ease the task, is it a win, overall, for simplicity and elegance, to
complicate the configuration of one network subsystem (DHCP) to protect
another (DNS)? If Anycast is in use, how does one handle that? Separate
sets of Anycast addresses for each virtualization of the DNS database
(thus shifting the "impurity" of view configuration to the "impurity" of
fragmented Anycast configuration)? What about the network topology and
the need sometimes to keep queries as "local" as possible (e.g. when
faced with a trans-continental WAN link having 400ms+ latency)? Does one
spin up virtual instances at *all* of the locations where there are
clients which need to see a particular virtualization of the DNS
database? So now we're looking at not just "x" number of virtual
instances (one to substitute for each view), but a worst-case scenario
of "x times y", where "y" is the number of locations which really need
local DNS resolution. How scalable is all of this?
Seems you value "purity" of named.conf highly, and that's admirable. But
reality, in the form of economics and logistics, often intrudes on
configurational purity. "Purity" and 80 cents might buy someone a cup of
coffee...
FYI, my previous figure of 7 views, in the worst case, was actually
overstated somewhat. After disregarding the views which are extraneous
(never matched, just artifacts of my configuration-management system),
and those which are truly temporary (due to sundowning of a datacenter,
and of a GSLB technology that needed a "helper"), the most I have in any
nameserver instance is 3. And all 3 of those are match-clients-based for
purposes of enforcing security policies with respect to which DMZ or
internal hosts can see internal and/or external DNS data ("defense in
depth"). My long-term plan for resolution in my non-DMZ,
non-Internet-facing environment is to have no views at all (or,
technically, only the "default" view), but I won't hesitate to implement
views where they make sense as temporary "bridge" measures and/or for
legitimate business reasons.
- Kevin
On 1/3/2014 6:20 PM, Johan Ihrén wrote:
Hi,
On 03 Jan 2014, at 22:00 , Kevin Darcy wrote:
On 1/2/2014 5:47 PM, Johan Ihrén wrote:
On 02 Jan 2014, at 16:37 , Alan Clegg wrote:
On Jan 2, 2014, at 9:19 AM,wbr...@e1b.org wrote:
Use views
Views +1
Im a proponent of separating servers and NOT using views, as any of you that
have taken a class that Ive taught will attest.
Furthermore, in addition to the very valid reasons that Alan list, I'd want to add yet
another reason to implement this via multiple, simple, [virtual] servers, rather than
using views and that is "platform independence". Views are a feature specific
to BIND9 (and ANS, I think). If I implement this via multiple servers then for each
server I am free to choose whatever implementation is best for that task. If choose a
design based on views, I am forced to used BIND9.
And while BIND9 may be the best thing since sliced bread, it will not be the
preferred choice forever.
I see views in broader terms as a kind of
source-and/or-dest-address-and/or-TSIG-key-based "virtualization" of a DNS
database. Now, one can virtualize a database by virtualizing the underlying host OS
itself -- as you and Alan have been advocating -- or one can virtualize it in a
subsystem-specific way (BIND 9 views), which seems more focused and lightweight. Even if
BIND 9 goes away some day, I don't think this subsystem-specific virtualization
desire/requirement will go away. Something else will come along to fill that void
(possibly a proprietary, for-pay piece of code). Virtualizing at the OS layer just isn't
logistically or ec
