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 >>> >>> I’m a proponent of separating servers and NOT using views, as any of you >>> that have taken a class that I’ve 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
