On 5.4.2013 16:32, Simo Sorce wrote:
On Fri, 2013-04-05 at 14:54 +0200, Petr Spacek wrote:
On 5.4.2013 14:38, Simo Sorce wrote:
On Fri, 2013-04-05 at 14:29 +0200, Pavel Březina wrote:

Pavel Brezina discovered that the design doesn't specify how client
should behave if expected _location.client.example.com. record

I propose to let this aspect on implementer's discretion (or

Personally, I would fall back to another pre-configured name, e.g.
case of SSSD to configured 'IPA domain' ...

Before I seen the design page, I wanted to implement it in SSSD this

If '_location.host.domain' gives any result than take it as primary
servers and SRV from 'domain' as backup servers. Otherwise use
result as primary servers.

But I'm not so sure now.

This is what I would expect too.
If no 'custom' record are available fallback to global records,
What is the difference between 'global records' and 'classic SRV records'?


I don't see any definition of the 'global' name _location.domain.com. in the design document [1].

What is the meaning of this 'global' record?
Is it site-specific?
If it isn't site-specific, why we need it?
If it is site-specific, how it will be configured/generated? You proposed to generate artificial record '_location.example.com' only if parent name ('example.com') contains A/AAAA record, but that is not mandatory for zone origin.

We should keep number of queries at minimum, so I would not add any 'global' records and other layers of indirection without very very good reason.

You know, each query adds latency and network load. Some caching for non-existing records is more than good idea. We should not try to lookup _locations.client.domain and _location.domain during each domain lookup (in case where it is not configured, of course :-).

[1] http://www.freeipa.org/page/V3/DNS_Location_Mechanism

Petr Spacek

Freeipa-devel mailing list

Reply via email to