Hi,
On 03 Jan 2014, at 22:00 , Kevin Darcy<k...@chrysler.com> wrote:
On 1/2/2014 5:47 PM, Johan Ihrén wrote:
On 02 Jan 2014, at 16:37 , Alan Clegg<a...@clegg.com> 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 economically optimal in all cases.
Interesting points. However, I must say that looking at the exact same problem
space I come to the complete opposite conclusion.
1. Virtualisation:
Once views were the thing to do. I also have boxes with seven or more views, a
few of them are still running. But I don't design things that way today. The
reason is that OS level virtualisation is so prevalent today and provides so
many additional benefits (simplicity of DNS config, standardization of hosting
environments, platform independence, etc).
In a way, I look at BIND9 as the forerunner for what was needed, and then functionality became more standardized... and
I migrated away from the BIND9 special version. Another example is the "r" in "rndc": once upon a
time I used "rndc -s remote.box cmd" to manage remote nameservers. These days I do "ssh remote.box rndc
cmd" and thereby I removed yet another dependency on a BIND9 special feature, removed the RNDC protocol from the
list of remote attack vectors and closed another open port. All good. Views are similar.
2. Lightweight:
Well, I have to agree that BIND9 views are more lightweight than OS level virtualisation,
although for most of us the bang-for-the-buck is less of an issue than the maintenance
costs... and more people seem to understand the concept of having several virtual
servers, each with a config that they grasp. In my world we are at a point where creating
a couple of virtual servers is done almost by clicking a checkbox or two, and is
available basically everywhere. Creating new views in BIND9 on the other hand is
"advanced stuff". If you mess up, not only do you not get the new views, you
run the real risk of compromising the entire existing DNS infrastructure. So while most
of us on this list may look at it as trivial, it is not trivial to everyone.
3. Something else providing views-like functionality in a post-BIND9 enviroment:
Hmm. Not from where I'm looking. A very common use for views is to have both an
authoritative view and a recursive/validating view in the same box. But the
general trend is away from nameservers that do both auth and reursive service.
NSD3, NSD4, Unbound, Knot-DNS, ANS, CNS, Yadifa, pdns, pdns-recursor, etc, etc.
All of them are *either* authoritative or recursive. Show me the piece of code
that is going to provide the equivalent of having both a recursive and an auth
view in such an environment? I seem to remember that ANS has views, but as it
is auth-only I'm assuming it cannot do this. On the other hand, yes, I'm aware
that BIND10 has an auth module and will have a recursive module, so the picture
is not completely one-sided.
4. Logistically or economically viable:
I have to make the observation that trying to solve "problems" in the wrong
"space" never works out in the long run. Yes, I am painfully aware that the world in
general likes to try to address all sorts of problems by DNS tweaks, DNS lying, DNS rewriting and
what have you. None of which improve on the quality and robustness of the DNS, in my book.
So I have to say that I strongly believe that financial and logistic problems, important as they may be, should be
addressed somewhere else than in my named.conf. Or, put another way, I'd argue that while the parameters for good DNS
design includes things like "simplicity", "maintainability", "being understandable to the next
admin", etc, it does not include "optimise for cost in a broken price schedule for virtual servers".
All that said, I do agree that there are situations when "views" are the best
alternative. But I argue that it should be the fall back, last resort, design, when the
standard design of using OS level virtualisation doesn't solve the problem.
Regards,
Johan
