Bug 815621 - [RFE] add support for BIND views
Summary: [RFE] add support for BIND views
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: rc
: 7.1
Assignee: Martin Kosek
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks: 1203710
TreeView+ depends on / blocked
 
Reported: 2012-04-24 05:21 UTC by Brian Cook
Modified: 2016-02-22 12:25 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-22 12:25:20 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Article) 1154063 0 None None None Never

Description Brian Cook 2012-04-24 05:21:50 UTC
Description of problem:

IPA/IdM has no awareness of network topology and no mechanism for preferring local servers over ones that may be across a slow WAN segment

BIND views are a way to accomplish this.  

Ideally the IPA / IdM administrator would be able to group together networks [x.x.x.x/xx] in a way that designates a site, and IPA will help clients prefer servers inside the site.  

Sites could be implemented as a list of networks tied to a site name.  Support for networks that aren't part of IPA DNS is required.

Server preference would be accomplished by IPA automatically maintaining BIND VIEWS for each site so that depending on what site the client is querying from, BIND orders the DNS query results such that local addresses are first.

a view like:
match-clients {"any"; }; // all other hosts

would match clients that are't in any defined site.

Since this feature depends on an interaction between the IPA configuration and BIND, it would be unavailable to people using external DNS.

A good example of using BIND VIEWS clauses is provided here: http://wiki.sipfoundry.org/pages/viewpage.action?pageId=3768360#SettingupBINDwithlocationbasedviewsforsipX-ExampleNetworkScenario

Comment 2 Martin Kosek 2012-04-24 07:10:16 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2008

Comment 3 Petr Spacek 2012-05-31 08:04:11 UTC
Upstream bind-dyndb-ldap ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/69

Discussion: https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html

Comment 4 Petr Spacek 2012-06-01 14:03:54 UTC
(In reply to comment #2)
> Upstream ticket:
> https://fedorahosted.org/freeipa/ticket/2008

This bug was "disconnected" from Trac ticket 2008. Another ticket has to be created for it, because this RFE is "bigger" that one descibed in Trac ticket 2008.

Comment 5 Martin Kosek 2012-06-01 14:13:27 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2802

Comment 6 Martin Kosek 2013-06-11 15:47:59 UTC
Changing Bugzilla title to match the RFE intent better.

Note that there is a slightly related Bug 747612 (linked to https://fedorahosted.org/freeipa/ticket/2008)  which targets implementation of sites for clients - though using different means than BIND views.

Comment 7 Martin Kosek 2013-06-11 15:49:32 UTC
Sorry, copy&paste error. This is the title I intended: "[RFE] add support for BIND views"

Comment 10 Eric Rich 2015-11-24 22:11:06 UTC
With out this IPA can not be deployed to IaaS environments like OpenStack or AWS efficiently. 

The following highlight issues seen on OpenStack with Bind as it relates to OpenShift: https://access.redhat.com/node/1154063

The same issues "theoretically" apply to any services on OpenStack that uses IPA or Bind as it DNS source if client based resolution is not done.

Comment 12 Petr Spacek 2015-11-25 13:51:27 UTC
Looking at https://access.redhat.com/node/1154063, it is not clear what the zone files in the example should contain and what not so it is hard to say what is needed from IPA.

Generally DNS views are often mis-used as a hacky workaround for suboptimal routing on IP layer, so I would not implement support for views unless there is a strong use-case behind this.

Comment 15 Josep 'Pep' Turro Mauri 2015-11-30 11:12:51 UTC
(In reply to Petr Spacek from comment #12)
> Looking at https://access.redhat.com/node/1154063, it is not clear what the
> zone files in the example should contain and what not so it is hard to say
> what is needed from IPA.

There are sample zone files attached to the article to try to illustrate, but the idea is that the zone info should be mostly the same except for A records which would resolve to different addresses in the internal vs external view (although there could be use cases with other differences).

> Generally DNS views are often mis-used as a hacky workaround for suboptimal
> routing on IP layer, so I would not implement support for views unless there
> is a strong use-case behind this.

The use case covered by the article is deployments on infrastructure-as-a-service environments (e.g. AWS, OpenStack, ...) where it's very common that systems are part of a private virtual network that has a private network address space (not routable externally). Systems that can be reached from outside are allocated routable addresses which are handled by the infrastructure via some type of NAT or proxy service. The systems are not necessarily aware of their external addresses, but even if they are they should communicate to each other using their internal/private addresses.

Hence the two views: one view that provides internal addresses to queries from the systems, and another view that provides external addresses for queries from outside.

The alternative involves having separate name servers for internal vs external queries. This means more infrastructure to maintain, but also a redundancy of places to maintain information.

For example: the article referenced above targets OpenShift Enterprise (OSE) 2.x deployments, OSE regularly updates DNS dynamically to maintain CNAME records for applications deployed there. These records are the same in the internal and external views, so OSE would have to update 2 DNS servers with the same information which is redundant and prone to get out-of-sync. 

Plus OSE does not support updating multiple servers - that's a different story, but from the product's perspective it's also a hard sell to add this support of multi-updates when it is simpler and more reliable to use the multiple view approach... otherwise you would be handing part of the responsibility to maintain the DNS infrastructure to OSE

(In reply to Martin Kosek from comment #11)
> If we see what exactly is the use case you are solving and the issue, we may
> be able to propose an alternate solution how to configure that in other ways
> with current IdM capabilities. I would let Petr Spacek as DNS SME to comment
> here.

I hope the above clarifies the use case. Aren't DNS views a good way to address it?

Comment 16 Petr Spacek 2015-11-30 13:56:16 UTC
To answer your question:
> I hope the above clarifies the use case. Aren't DNS views a good way to address it?

It is not the best way, it would be way way better to avoid NAT completely and just configure IP routing for OpenShift nodes properly so everyone could use routable IP address and get optimal routing anyway. (And, naturarly, use firewall, but you have to do that anyway.)


Nevertheless we need to work with that we have.

Let me rephrase what I understood so you can check if I undestood it correctly:
* zone os.example.com contains only CNAMEs from "application-name.os.example.com." to "node1.example.com.".
-- This zone is updated dynamically by OpenShift as applications are added and removed.
-- There is in fact nothing to amend because this zone does not contain IP addresses, just CNAMEs.

* zone example.com contains A/AAAA records for OpenShift nodes
-- These IP addresses differ between views as IP routing optimization.
-- Are these IP addresses are updated by hand? I assume so because the example files attached to the article do not allow updates for them.


Assuming that this is correct, I would recommend you to do this:
Assumption: IPA is used mostly to manage internal resources, so it does make more sense to fill it with internal IP addresses instead of external ones.

1. Install IPA and let it manage DNS zones example.com and os.example.com. Populate these zones with internal IP addresses and allow OpenShift to issue updates to IPA managed zone os.example.com. This will lead to named.conf which contains section dynamic-db {}.

2. Enclose whole section dynamic-db {} into view "internal" as seen in example configuration:

view "internal" {
  match-clients { "openstack"; 127.0.0.0/8; };
  recursion yes;
  dynamic-db { ... };
}

Now the "internal" view contains master zones and can accept dynamic updates as configured in IPA.

3. Create view "global" with hand-made zone file for zone "example.com":
view "global" {
  match-clients { any; };
  recursion no;

  zone "os.example.com" IN {
          type forward;
          // 192.0.2.1 is the private IP of this DNS server
          forwarders { 192.0.2.1; };
  // assumption here is that DNS updates for "os.example.com" are generated from internal IP addresses
  // if it is not correct, you might need to use slave zone here and allow zone tranfers from IPA
  };

  zone "example.com" IN {
          type master;
          // this is hand-made DNS zone which contains globaly routable IP addresses of OpenShift nodes
          file "static/example.com-external";
  };
};

Comment 17 Josep 'Pep' Turro Mauri 2015-11-30 16:14:12 UTC
(In reply to Petr Spacek from comment #16)
> It is not the best way, it would be way way better to avoid NAT completely

I'm not saying I disagree, but:

> Nevertheless we need to work with that we have.

Right, that's the point. This type of environment is not going away any time soon: as mentioned, AWS and OpenStack are two example deployment environments with this type of setup (private network addresses for instances with NAT for external access).

> Assuming that this is correct, I would recommend you to do this:

Thanks for the recommendation. A summary of it is to basically implement the same type of modifications in named.conf that the article suggests and manage the external static zone outside of IPA, right? (thanks for the suggestion of using a forward zone, it's indeed better than the slave zone approach in the article, although as you say the slave zone is a bit more generic).

Taking a step back: my previous comment used the OpenShift-based article because this was mentioned as an example, but I believe that the RFE here is to be able to manage everything from IPA - not necessarily when there's a dynamic zone whose contents are only CNAMEs. Back to the example: IPA would only manage "example.com internal", where "example.com external" would require manual maintenance. The RFE would be to manage both from IPA.

In other words: the use case here is not [only] "OpenShift on OpenStack using IPA" but "OpenStack/AWS based deployments using IPA to manage their DNS".

In these environments each host typically has an "internal" and an "external" ddress. Does that make sense as a use case?

Comment 18 Eric Rich 2015-11-30 16:21:58 UTC
I feel like the ask in https://www.redhat.com/archives/freeipa-users/2015-April/msg00432.html is similar to what is being asked here as well. 

In short the RFE or ask seems to be that IPA have the capability to create DNS records for "Node/Instance - hostname" that have "public" IP and "private" IP addresses. 
    - without having to modify a 'static/example.com-external' file manually and also run IPA command[s] to update "dynamic-db { ... };" dynamic entries.  

I feel that in some customer environments (like mine) where "provisioning systems" (heat, cloud-formations, ansible, etc) are used to create instances, and add them to the DNS system of record. Having a standard interface (API, command, etc) in IPA, makes the tool/product stand out compared to other solutions who have the same issue. 

In a way the request for "views" really become a request for "tighter" integration/interoperability with IaaS platforms, by allowing for IPA to manage DNS views.

Comment 19 Brian Cook 2015-11-30 17:47:09 UTC
The original RFE had nothing to do with NAT, nor anything releated to cloud or openstack specifically.  The most basic functionality that is missing is that if I have two sites seperated by a WAN link with a large number of servers on each side, currently there is no mechanism to get servers in site A to prefer IDM servers in site A, and servers in site b to prefer IdM servers in site B.  The list of servers shouldn't have to be manually ordered or edited, DNS should just take care of providing the list of services to clients, and ordering them appropriately.  Automatic Bind views would fix this problem very nicely and make sure that authentication is local whenever possible, and avoid a bunch of unnecessary chatter on slower links.

Comment 20 Petr Spacek 2015-12-01 07:53:37 UTC
Brian, your specific request (for IPA clients to use local IPA server) does not require general purpose views, so it was split out to separate bug 747612.

General purpose DNS views are a very different beast so this request is tracked in bug 815621 (this one).

DNS sites (bug 747612) are way more likely to be addressed than generic DNS views (bug 815621).

Comment 22 Petr Spacek 2015-12-03 07:31:25 UTC
Let us do one step back:
Should IPA be a general-purpose DNS server + additional fancy features like DNS views?

We have to answer this question first. I'm personally not sure.

Comment 23 Martin Kosek 2016-02-22 12:25:20 UTC
Hello, I am sorry for the long wait, but the (very good) question that Petr Spacek asked in Comment 22 needed first some research and a discussion within the Identity Management development team.

Petr did a research of past bind-dyndb-ldap development, collected the good and bads of this approached and shared them on this page:

https://fedorahosted.org/bind-dyndb-ldap/wiki/Maintainability

resulting in revised Goals and Assumptions of the DNS component in IPA/IdM:
http://www.freeipa.org/page/DNS#Assumptions
http://www.freeipa.org/page/DNS#Goals

Based on this evidence, the answer for Petr's question is "no". Which means that DNS Views support in bind-dyndb-ldap directly does not really fit our direction and should be resolved in other way. I am therefore closing this request as WONTFIX.


Note You need to log in before you can comment on or make changes to this bug.