On 15.9.2013 20:19, Dmitri Pal wrote:
On 09/14/2013 01:27 PM, Simo Sorce wrote:
>On Fri, 2013-09-13 at 14:26 -0400, Dmitri Pal wrote:
>>On 09/13/2013 09:08 AM, Simo Sorce wrote:
>>>On Fri, 2013-09-13 at 10:26 +0200, Petr Spacek wrote:
>>>>Hello list,
>>>>FreeIPA deployments in cloud environments do not work very well because
>>>>'clouds' break some assumptions we made during FreeIPA's design.
>>>>We should fix it somehow:-)
>>>>=== Problems ===
>>>>- A machine has two host names in DNS:
>>>>-- The first name is internal to the cloud and resolvable only from inside 
>>>>the cloud.
>>>>--- This name should be used for communication inside cloud.
>>>>--- E.g. 'ipa.cust1.cloud.'
>>>>--- Internal name is mapped to internal IP address, see below.
>>>>-- The second name is external to the cloud and should be used for
>>>>communication between the Internet and cloud.
>>>>--- E.g. 'ipa.example.com.'
>>>>--- External name maps to external IP address, see below.
>>>>- A machine has two IP addresses:
>>>>-- Internal, private IP address configured at the machine's interface
>>>>--- Typically the only IP address known to the machine.
>>>>--- E.g.
>>>>--- IP address can change dynamically, at least after a machine reboot.
>>>>-- External, public IP address:
>>>>--- Typically mapped to internal address at cloud boundary (NAT).
>>>>--- E.g.
>>>>--- IP address can change dynamically, at least after a machine reboot.
>>>>Related tickets:
>>>>The natural request is to add support for DNS views/split horizon DNS into
>>>>FreeIPA, so different names and IP addresses can be served to clients inside
>>>>and outside of the cloud.
>>>>Is it enough? What else should we change to make FreeIPA reliable in clouds?
>>>I do not understand what's the use of views in this case.
>>>Views are used when you want to assign different IP addresses to the
>>>same name depending on where the query comes from.

You are right, the scenario described by me doesn't require views. Please see reply from James in another part of this thread - his setup has shared host name (internal = external) but different IP addresses for internal and external usage.

The question is if DNS is the right layer to solve the problem. Some oddities like this could be solved on IP routing level: I.e. use 'external'/public IP address everywhere and route packets with this 'external IP' to the right part of the internal network.

Solution on routing layer can be technically feasible, but it doesn't mean that it is politically acceptable. People usually don't want to touch routing unless absolutely necessary :-)

Petr^2 Spacek

Freeipa-devel mailing list

Reply via email to