DNS with several ip adessess

[Kevin Darcy]

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<kcd at chrysler.com>  wrote:
>
>> On 1/2/2014 5:47 PM, Johan Ihrén wrote:
>>> On 02 Jan 2014, at 16:37 , Alan Clegg<alan at clegg.com>  wrote:
>>>
>>>> On Jan 2, 2014, at 9:19 AM,WBrown at 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
>