Re: [Freeipa-devel] A new proopsal for Location Based Discovery
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
doesn't
exist.
I propose to let this aspect on implementer's discretion (or
configurable).
Personally, I would fall back to another pre-configured name, e.g.
in
case of SSSD to configured 'IPA domain' ...
Before I seen the design page, I wanted to implement it in SSSD this
way:
If '_location.host.domain' gives any result than take it as primary
servers and SRV from 'domain' as backup servers. Otherwise use
'domain'
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'?
_ldap._tcp._location.example.com
vs
_ldap._tcp.example.com
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/ 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
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
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 > >> doesn't > >>> exist. > >>> > >>> I propose to let this aspect on implementer's discretion (or > >> configurable). > >>> > >>> Personally, I would fall back to another pre-configured name, e.g. > >> in > >>> case of SSSD to configured 'IPA domain' ... > >> > >> Before I seen the design page, I wanted to implement it in SSSD this > >> way: > >> > >> If '_location.host.domain' gives any result than take it as primary > >> servers and SRV from 'domain' as backup servers. Otherwise use > >> 'domain' > >> 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'? _ldap._tcp._location.example.com vs _ldap._tcp.example.com Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
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 doesn't exist. I propose to let this aspect on implementer's discretion (or configurable). Personally, I would fall back to another pre-configured name, e.g. in case of SSSD to configured 'IPA domain' ... Before I seen the design page, I wanted to implement it in SSSD this way: If '_location.host.domain' gives any result than take it as primary servers and SRV from 'domain' as backup servers. Otherwise use 'domain' 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'? Petr^2 Spacek > then fall back to classic SRV records, then fall back to local configuration. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
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 > doesn't > > exist. > > > > I propose to let this aspect on implementer's discretion (or > configurable). > > > > Personally, I would fall back to another pre-configured name, e.g. > in > > case of SSSD to configured 'IPA domain' ... > > Before I seen the design page, I wanted to implement it in SSSD this > way: > > If '_location.host.domain' gives any result than take it as primary > servers and SRV from 'domain' as backup servers. Otherwise use > 'domain' > 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, then fall back to classic SRV records, then fall back to local configuration. Simo. > -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On 04/05/2013 02:22 PM, Petr Spacek wrote:
On 23.1.2013 02:13, Simo Sorce wrote:
On Tue, 2013-01-22 at 18:30 +0100, Petr Spacek wrote:
On 22.1.2013 16:01, Simo Sorce wrote:
Replying to myself for the beginning:
> On Tue, 2013-01-22 at 15:23 +0100, Petr Spacek wrote:
>>> Server Implementation
>>> TODO: interaction with DNSSEC
>> That it *very* important part. I have fear from so many dynamic
things inside.
There is less dynamic things than I thought :-) The only dynamic
thing is
_location.client.domain DNAME record. Proposal of "filters" was
omitted in
this version.
My biggest concern is related to dynamical parts, I like the idea
itself.
> Yes this is indeed going to add complexity. No doubt.
Creating per-server _locations sub-tree is very easy with current
code: Simply
copy&paste new bind-dyndb-ldap section to /etc/named.conf and point
base DN to
some server-specific part of LDAP tree:
dynamic-db "ipa-local" {
//
arg "base cn=srv2.example.com, cn=dns-local,
dc=example,dc=com";
}
Unless you have a way to mange it via LDAP this is unworkable.
Locations
should be managed via the Web UI. So you need to be able to create new
locations on the fly and change server's locations dynamically,
possibly
w/o requiring a server restart, but certainly w/o requiring the DNS
admin to have direct SSH access to all boxes to go and manually change
named.conf
Sure, admin will never touch lines above. All data *are* directly in
LDAP, so
any tool can read & change _locations configuration on the fly.
Ok I can see that now.
Server specific _locations records live in this sub-tree and each
server has
have own view of _locations, i.e. each server could specify mapping
between
locations in own way. DNS clients will see merged DNS tree, no
change on
client side is required.
But this would require to manually change multiple records for multiple
servers in the same location, which could go wrong quite easily.
I agree. This is a problem. It would require a tool to handle all
location
stuff. It definitely needs some clever way for management.
Yes we are shifting complexity from one place to another.
Each location configuration should be in a single place so that it is
consistent for all servers of that location and not a burden for
administration.
I agree, it could be seen as a problem. With LDAP referrals and right
tool it
could be reasonable.
I am not sure I like the idea of using LDAP referrals for this, I need
to think ab out that, I can see how it can be used to reduce some
duplication.
Also your methods puts location information out of the actual DNS, so
you can't lookup location data via DNS except for the 'default'.
That is not correct. Any client could ask any server for
something._locations.domain and the reply will contain server's
mapping for
particular location.
See this is the problem. Because your DNAME is fixed, in order to do
overrides, you have to have a 'server's view of a location.
Ie instead of directing the client to the right place, you 'fake'
information about the place the client thinks it is fetching info for.
This maintains still a great deal of 'duplication' except the data is
not identical, each server have different data labeled with a name
recurring on other servers in order to cheat clients. This can easily
get out of control.
Even if the data is not 'duplicated' in the db and it is just all smoke
and mirrors and internal redirects it still a complex maze of redirects
you have to store. It also prevents to have final absolute rules for
some clients.
But that would not be correct, we want to allow a client to lookup
location data for a non-default location, because an IPA DNS server may
very well be serving multiple locations.
Sure, that doesn't change.
Ah but it does, in order to force clients to stick to a location in some
case you are faking data for all location so all locations point to the
same data.
In my model _location.client.domain returns you arbitrary (dynamic) data
but foo._location.domain is always consistent across all servers.
In your model _location.client.domain returns 'stable' data but
foo._location.domain may instead return fake data.
For some reason I prefer the former rather than the latter, although I
recognize it may just be a matter of taste, but is sounds right to me
that the _locations.domain tree is the stable one rather than the
_location.client.domain one.
E.g. client has preferred location "brno" but the client is
connected to
network in "nyc", i.e. DNS queries are sent to servers in NYC. NYC
server has
own "_locations" sub-tree with trivial mapping "brno DNAME nyc".
How to read the result: Location "Brno" is too far from "NYC", use
"NYC"
anyway! Also, "default" location could prefer local server over
remote ones,
i.e. local clients without any configuration will prefer local
servers.
I am not sure how this is different from my proposal, the problem I see
is that you loose the ability to force a configura
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On 23.1.2013 02:13, Simo Sorce wrote:
On Tue, 2013-01-22 at 18:30 +0100, Petr Spacek wrote:
On 22.1.2013 16:01, Simo Sorce wrote:
Replying to myself for the beginning:
> On Tue, 2013-01-22 at 15:23 +0100, Petr Spacek wrote:
>>> Server Implementation
>>> TODO: interaction with DNSSEC
>> That it *very* important part. I have fear from so many dynamic things
inside.
There is less dynamic things than I thought :-) The only dynamic thing is
_location.client.domain DNAME record. Proposal of "filters" was omitted in
this version.
My biggest concern is related to dynamical parts, I like the idea itself.
> Yes this is indeed going to add complexity. No doubt.
Creating per-server _locations sub-tree is very easy with current code: Simply
copy&paste new bind-dyndb-ldap section to /etc/named.conf and point base DN to
some server-specific part of LDAP tree:
dynamic-db "ipa-local" {
//
arg "base cn=srv2.example.com, cn=dns-local, dc=example,dc=com";
}
Unless you have a way to mange it via LDAP this is unworkable. Locations
should be managed via the Web UI. So you need to be able to create new
locations on the fly and change server's locations dynamically, possibly
w/o requiring a server restart, but certainly w/o requiring the DNS
admin to have direct SSH access to all boxes to go and manually change
named.conf
Sure, admin will never touch lines above. All data *are* directly in LDAP, so
any tool can read & change _locations configuration on the fly.
Ok I can see that now.
Server specific _locations records live in this sub-tree and each server has
have own view of _locations, i.e. each server could specify mapping between
locations in own way. DNS clients will see merged DNS tree, no change on
client side is required.
But this would require to manually change multiple records for multiple
servers in the same location, which could go wrong quite easily.
I agree. This is a problem. It would require a tool to handle all location
stuff. It definitely needs some clever way for management.
Yes we are shifting complexity from one place to another.
Each location configuration should be in a single place so that it is
consistent for all servers of that location and not a burden for
administration.
I agree, it could be seen as a problem. With LDAP referrals and right tool it
could be reasonable.
I am not sure I like the idea of using LDAP referrals for this, I need
to think ab out that, I can see how it can be used to reduce some
duplication.
Also your methods puts location information out of the actual DNS, so
you can't lookup location data via DNS except for the 'default'.
That is not correct. Any client could ask any server for
something._locations.domain and the reply will contain server's mapping for
particular location.
See this is the problem. Because your DNAME is fixed, in order to do
overrides, you have to have a 'server's view of a location.
Ie instead of directing the client to the right place, you 'fake'
information about the place the client thinks it is fetching info for.
This maintains still a great deal of 'duplication' except the data is
not identical, each server have different data labeled with a name
recurring on other servers in order to cheat clients. This can easily
get out of control.
Even if the data is not 'duplicated' in the db and it is just all smoke
and mirrors and internal redirects it still a complex maze of redirects
you have to store. It also prevents to have final absolute rules for
some clients.
But that would not be correct, we want to allow a client to lookup
location data for a non-default location, because an IPA DNS server may
very well be serving multiple locations.
Sure, that doesn't change.
Ah but it does, in order to force clients to stick to a location in some
case you are faking data for all location so all locations point to the
same data.
In my model _location.client.domain returns you arbitrary (dynamic) data
but foo._location.domain is always consistent across all servers.
In your model _location.client.domain returns 'stable' data but
foo._location.domain may instead return fake data.
For some reason I prefer the former rather than the latter, although I
recognize it may just be a matter of taste, but is sounds right to me
that the _locations.domain tree is the stable one rather than the
_location.client.domain one.
E.g. client has preferred location "brno" but the client is connected to
network in "nyc", i.e. DNS queries are sent to servers in NYC. NYC server has
own "_locations" sub-tree with trivial mapping "brno DNAME nyc".
How to read the result: Location "Brno" is too far from "NYC", use "NYC"
anyway! Also, "default" location could prefer local server over remote ones,
i.e. local clients without any configuration will prefer local servers.
I am not sure how this is different from my proposal, the problem I see
is that you loose the ability to force a configuration for select client
by actually creating
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On Tue, Jan 22, 2013 at 07:33:53PM -0500, Simo Sorce wrote: > On Tue, 2013-01-22 at 17:46 +0100, Adam Tkac wrote: > > On Tue, Jan 22, 2013 at 11:19:30AM -0500, Simo Sorce wrote: > > > On Tue, 2013-01-22 at 17:02 +0100, Adam Tkac wrote: > > > > On Tue, Jan 22, 2013 at 10:25:21AM -0500, Simo Sorce wrote: > > > > > On Tue, 2013-01-22 at 16:18 +0100, Adam Tkac wrote: > > > > > > Before we start talking about using DNS for this purpose, have you > > > > > > considered > > > > > > to use IP anycast for this? You can simply create multiple servers > > > > > > with same IP > > > > > > address on different places over the world. After that you announce > > > > > > this IP > > > > > > address from multiple places simultaneounsly via BGP and BGP > > > > > > automatically > > > > > > routes all clients to the closest node. Advantage is that this is > > > > > > already > > > > > > implemented, used and nothing have to be modified. > > > > > > > > > > > > Regards, Adam > > > > > > > > > > > We cannot assume our customers can influence or have access to change > > > > > BGP routing, so I excluded multicast solutions from the get go. > > > > > Also it requires more changes on the clients which is another heavy > > > > > minus. > > > > > > > > If I understand correctly, target customers of IPA are companies and > > > > they use > > > > IPA to maintain resources in their internal networks, aren't they? > > > > > > > > In this case I see two basic solutions how to solve the "location" > > > > issue. > > > > > > > > 1. BGP routing between multiple internal networks > > > > > > Sorry Adam, I do not want to be dismissive, and I know that in an ideal > > > world this would be an awesome solution. > > > > > > Just trust me that for most cases asking someone to change their network > > > architecture is simply impossible. > > > > This is definitely right. > > > > However please read my previous post - I don't propose to change network > > architecture. Do you how to interconnect multiple networks without routers? > > I don't. So routers are already present in customer's networks. It can be > > even > > static routing, not BGP, and admin can simply set rule on router which > > physical > > server clients should use. > > > > > We have users telling us their network admins don't even want change > > > firewall configurations in some cases, so you can well see how they > > > would respond to someone asking them to change their routing or enabling > > > and using multicast. > > > > I think it's same amount of work to add record to DNS or to add record to > > the > > static or dynamic routing tables. > > Adding a record to a DNS server is quite different from changing routing > and starting routing multicast packets. Please note anycast != multicast. Anycast is unicast so no multicast is involved. > > > Sorry but it simply is not a solution we can consider. > > > > Why? Which setup cannot be achieved with routing configuration and can be > > achieved > > with location information in DNS? > > Queries from clients behind a VPN that doesn't do multicast ? > > In general multicast cannot be assumed to be available/configured. > > And it requires support in clients as well as services. > > Also 'location' doesn't mean necessarily 'local'. > > My client in NYC may be configured to be bound to servers in Boston for > whatever administrative reason. Boston is in no way local to me but is > my 'location'. How do you deliver that information in a schema like the > one you had in mind ? This is not possible with my anycast proposal. Thanks for explanation, I just didn't imagine which schema cannot be configured on routing level and this is the one. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On Tue, 2013-01-22 at 18:30 +0100, Petr Spacek wrote:
> On 22.1.2013 16:01, Simo Sorce wrote:
>
> Replying to myself for the beginning:
>
> > On Tue, 2013-01-22 at 15:23 +0100, Petr Spacek wrote:
> >>> Server Implementation
> >>> TODO: interaction with DNSSEC
> >> That it *very* important part. I have fear from so many dynamic things
> inside.
> There is less dynamic things than I thought :-) The only dynamic thing is
> _location.client.domain DNAME record. Proposal of "filters" was omitted in
> this version.
>
> My biggest concern is related to dynamical parts, I like the idea itself.
>
> > Yes this is indeed going to add complexity. No doubt.
>
> >> Creating per-server _locations sub-tree is very easy with current code:
> >> Simply
> >> copy&paste new bind-dyndb-ldap section to /etc/named.conf and point base
> >> DN to
> >> some server-specific part of LDAP tree:
> >>
> >> dynamic-db "ipa-local" {
> >> //
> >> arg "base cn=srv2.example.com, cn=dns-local, dc=example,dc=com";
> >> }
> >
> > Unless you have a way to mange it via LDAP this is unworkable. Locations
> > should be managed via the Web UI. So you need to be able to create new
> > locations on the fly and change server's locations dynamically, possibly
> > w/o requiring a server restart, but certainly w/o requiring the DNS
> > admin to have direct SSH access to all boxes to go and manually change
> > named.conf
> Sure, admin will never touch lines above. All data *are* directly in LDAP, so
> any tool can read & change _locations configuration on the fly.
Ok I can see that now.
> >> Server specific _locations records live in this sub-tree and each server
> >> has
> >> have own view of _locations, i.e. each server could specify mapping between
> >> locations in own way. DNS clients will see merged DNS tree, no change on
> >> client side is required.
> >
> > But this would require to manually change multiple records for multiple
> > servers in the same location, which could go wrong quite easily.
> I agree. This is a problem. It would require a tool to handle all location
> stuff. It definitely needs some clever way for management.
Yes we are shifting complexity from one place to another.
> > Each location configuration should be in a single place so that it is
> > consistent for all servers of that location and not a burden for
> > administration.
> I agree, it could be seen as a problem. With LDAP referrals and right tool it
> could be reasonable.
I am not sure I like the idea of using LDAP referrals for this, I need
to think ab out that, I can see how it can be used to reduce some
duplication.
> > Also your methods puts location information out of the actual DNS, so
> > you can't lookup location data via DNS except for the 'default'.
> That is not correct. Any client could ask any server for
> something._locations.domain and the reply will contain server's mapping for
> particular location.
See this is the problem. Because your DNAME is fixed, in order to do
overrides, you have to have a 'server's view of a location.
Ie instead of directing the client to the right place, you 'fake'
information about the place the client thinks it is fetching info for.
This maintains still a great deal of 'duplication' except the data is
not identical, each server have different data labeled with a name
recurring on other servers in order to cheat clients. This can easily
get out of control.
Even if the data is not 'duplicated' in the db and it is just all smoke
and mirrors and internal redirects it still a complex maze of redirects
you have to store. It also prevents to have final absolute rules for
some clients.
> > But that would not be correct, we want to allow a client to lookup
> > location data for a non-default location, because an IPA DNS server may
> > very well be serving multiple locations.
> Sure, that doesn't change.
Ah but it does, in order to force clients to stick to a location in some
case you are faking data for all location so all locations point to the
same data.
In my model _location.client.domain returns you arbitrary (dynamic) data
but foo._location.domain is always consistent across all servers.
In your model _location.client.domain returns 'stable' data but
foo._location.domain may instead return fake data.
For some reason I prefer the former rather than the latter, although I
recognize it may just be a matter of taste, but is sounds right to me
that the _locations.domain tree is the stable one rather than the
_location.client.domain one.
> >> E.g. client has preferred location "brno" but the client is connected to
> >> network in "nyc", i.e. DNS queries are sent to servers in NYC. NYC server
> >> has
> >> own "_locations" sub-tree with trivial mapping "brno DNAME nyc".
> >>
> >> How to read the result: Location "Brno" is too far from "NYC", use "NYC"
> >> anyway! Also, "default" location could prefer local server over remote
> >> ones,
> >> i.e. local clients without any configuration will
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On Tue, 2013-01-22 at 17:46 +0100, Adam Tkac wrote: > On Tue, Jan 22, 2013 at 11:19:30AM -0500, Simo Sorce wrote: > > On Tue, 2013-01-22 at 17:02 +0100, Adam Tkac wrote: > > > On Tue, Jan 22, 2013 at 10:25:21AM -0500, Simo Sorce wrote: > > > > On Tue, 2013-01-22 at 16:18 +0100, Adam Tkac wrote: > > > > > Before we start talking about using DNS for this purpose, have you > > > > > considered > > > > > to use IP anycast for this? You can simply create multiple servers > > > > > with same IP > > > > > address on different places over the world. After that you announce > > > > > this IP > > > > > address from multiple places simultaneounsly via BGP and BGP > > > > > automatically > > > > > routes all clients to the closest node. Advantage is that this is > > > > > already > > > > > implemented, used and nothing have to be modified. > > > > > > > > > > Regards, Adam > > > > > > > > > We cannot assume our customers can influence or have access to change > > > > BGP routing, so I excluded multicast solutions from the get go. > > > > Also it requires more changes on the clients which is another heavy > > > > minus. > > > > > > If I understand correctly, target customers of IPA are companies and they > > > use > > > IPA to maintain resources in their internal networks, aren't they? > > > > > > In this case I see two basic solutions how to solve the "location" issue. > > > > > > 1. BGP routing between multiple internal networks > > > > Sorry Adam, I do not want to be dismissive, and I know that in an ideal > > world this would be an awesome solution. > > > > Just trust me that for most cases asking someone to change their network > > architecture is simply impossible. > > This is definitely right. > > However please read my previous post - I don't propose to change network > architecture. Do you how to interconnect multiple networks without routers? > I don't. So routers are already present in customer's networks. It can be even > static routing, not BGP, and admin can simply set rule on router which > physical > server clients should use. > > > We have users telling us their network admins don't even want change > > firewall configurations in some cases, so you can well see how they > > would respond to someone asking them to change their routing or enabling > > and using multicast. > > I think it's same amount of work to add record to DNS or to add record to the > static or dynamic routing tables. Adding a record to a DNS server is quite different from changing routing and starting routing multicast packets. > > Sorry but it simply is not a solution we can consider. > > Why? Which setup cannot be achieved with routing configuration and can be > achieved > with location information in DNS? Queries from clients behind a VPN that doesn't do multicast ? In general multicast cannot be assumed to be available/configured. And it requires support in clients as well as services. Also 'location' doesn't mean necessarily 'local'. My client in NYC may be configured to be bound to servers in Boston for whatever administrative reason. Boston is in no way local to me but is my 'location'. How do you deliver that information in a schema like the one you had in mind ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On Tue, Jan 22, 2013 at 11:19:30AM -0500, Simo Sorce wrote: > On Tue, 2013-01-22 at 17:02 +0100, Adam Tkac wrote: > > On Tue, Jan 22, 2013 at 10:25:21AM -0500, Simo Sorce wrote: > > > On Tue, 2013-01-22 at 16:18 +0100, Adam Tkac wrote: > > > > Before we start talking about using DNS for this purpose, have you > > > > considered > > > > to use IP anycast for this? You can simply create multiple servers > > > > with same IP > > > > address on different places over the world. After that you announce > > > > this IP > > > > address from multiple places simultaneounsly via BGP and BGP > > > > automatically > > > > routes all clients to the closest node. Advantage is that this is > > > > already > > > > implemented, used and nothing have to be modified. > > > > > > > > Regards, Adam > > > > > > > We cannot assume our customers can influence or have access to change > > > BGP routing, so I excluded multicast solutions from the get go. > > > Also it requires more changes on the clients which is another heavy > > > minus. > > > > If I understand correctly, target customers of IPA are companies and they > > use > > IPA to maintain resources in their internal networks, aren't they? > > > > In this case I see two basic solutions how to solve the "location" issue. > > > > 1. BGP routing between multiple internal networks > > Sorry Adam, I do not want to be dismissive, and I know that in an ideal > world this would be an awesome solution. > > Just trust me that for most cases asking someone to change their network > architecture is simply impossible. This is definitely right. However please read my previous post - I don't propose to change network architecture. Do you how to interconnect multiple networks without routers? I don't. So routers are already present in customer's networks. It can be even static routing, not BGP, and admin can simply set rule on router which physical server clients should use. > We have users telling us their network admins don't even want change > firewall configurations in some cases, so you can well see how they > would respond to someone asking them to change their routing or enabling > and using multicast. I think it's same amount of work to add record to DNS or to add record to the static or dynamic routing tables. > Sorry but it simply is not a solution we can consider. Why? Which setup cannot be achieved with routing configuration and can be achieved with location information in DNS? Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On 22.1.2013 16:01, Simo Sorce wrote:
Replying to myself for the beginning:
> On Tue, 2013-01-22 at 15:23 +0100, Petr Spacek wrote:
>>> Server Implementation
>>> TODO: interaction with DNSSEC
>> That it *very* important part. I have fear from so many dynamic things
inside.
There is less dynamic things than I thought :-) The only dynamic thing is
_location.client.domain DNAME record. Proposal of "filters" was omitted in
this version.
My biggest concern is related to dynamical parts, I like the idea itself.
> Yes this is indeed going to add complexity. No doubt.
Creating per-server _locations sub-tree is very easy with current code: Simply
copy&paste new bind-dyndb-ldap section to /etc/named.conf and point base DN to
some server-specific part of LDAP tree:
dynamic-db "ipa-local" {
//
arg "base cn=srv2.example.com, cn=dns-local, dc=example,dc=com";
}
Unless you have a way to mange it via LDAP this is unworkable. Locations
should be managed via the Web UI. So you need to be able to create new
locations on the fly and change server's locations dynamically, possibly
w/o requiring a server restart, but certainly w/o requiring the DNS
admin to have direct SSH access to all boxes to go and manually change
named.conf
Sure, admin will never touch lines above. All data *are* directly in LDAP, so
any tool can read & change _locations configuration on the fly.
Server specific _locations records live in this sub-tree and each server has
have own view of _locations, i.e. each server could specify mapping between
locations in own way. DNS clients will see merged DNS tree, no change on
client side is required.
But this would require to manually change multiple records for multiple
servers in the same location, which could go wrong quite easily.
I agree. This is a problem. It would require a tool to handle all location
stuff. It definitely needs some clever way for management.
Each location configuration should be in a single place so that it is
consistent for all servers of that location and not a burden for
administration.
I agree, it could be seen as a problem. With LDAP referrals and right tool it
could be reasonable.
Also your methods puts location information out of the actual DNS, so
you can't lookup location data via DNS except for the 'default'.
That is not correct. Any client could ask any server for
something._locations.domain and the reply will contain server's mapping for
particular location.
But that would not be correct, we want to allow a client to lookup
location data for a non-default location, because an IPA DNS server may
very well be serving multiple locations.
Sure, that doesn't change.
E.g. client has preferred location "brno" but the client is connected to
network in "nyc", i.e. DNS queries are sent to servers in NYC. NYC server has
own "_locations" sub-tree with trivial mapping "brno DNAME nyc".
How to read the result: Location "Brno" is too far from "NYC", use "NYC"
anyway! Also, "default" location could prefer local server over remote ones,
i.e. local clients without any configuration will prefer local servers.
I am not sure how this is different from my proposal, the problem I see
is that you loose the ability to force a configuration for select client
by actually creating real DNAME records.
DNAME record stored in the database is only "preferred" location, it could be
overridden on server side (by different content of _locations.domain sub-tree).
There is another nice feature: "old" _ntp._udp.domain SRV records could
contain aliases pointing to SRV records in some location, e.g. "default". In
that case also old clients will prefer local servers over remote ones - almost
with no price and with no client reconfiguration.
No new concepts, no new code :-)
We can do that with a DNAME in theory, but I would rather keep current
domain records as is for now.
There is still _location DNAME record under client's name, that stay
unchanged. Personally, I don't like any on-the-fly record generation. Is it
really necessary?
Who creates this record for new clients ?
It was mentioned below - 'ipa host-add' + fall-back to 'domain' for new clients.
How to you handle 3 locations on a single DNS server ?
Say I have a headquarters DNS setup where I want to send clients to the
engineering, sales or accounting locations depending on the client but I
have a shared local network configuration so all clients use the same
DNS server.
Each client machine has record like "_location DNAME eng._locations.domain.".
In case described above I don't think so. Roaming between locations don't
require changing any record, so configuration is static.
Yep 'static' is the issue here, we want it more dynamic, the point of
generating is that we can change the way we manage locations in future
w/o having to jump through more hops.
I'm not sure if I understood what "hop" mean. In reality all the CNAME/DNAME
alias de-referencing is done in single shot if all data are avail
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On Tue, 2013-01-22 at 17:02 +0100, Adam Tkac wrote: > On Tue, Jan 22, 2013 at 10:25:21AM -0500, Simo Sorce wrote: > > On Tue, 2013-01-22 at 16:18 +0100, Adam Tkac wrote: > > > Before we start talking about using DNS for this purpose, have you > > > considered > > > to use IP anycast for this? You can simply create multiple servers > > > with same IP > > > address on different places over the world. After that you announce > > > this IP > > > address from multiple places simultaneounsly via BGP and BGP > > > automatically > > > routes all clients to the closest node. Advantage is that this is > > > already > > > implemented, used and nothing have to be modified. > > > > > > Regards, Adam > > > > > We cannot assume our customers can influence or have access to change > > BGP routing, so I excluded multicast solutions from the get go. > > Also it requires more changes on the clients which is another heavy > > minus. > > If I understand correctly, target customers of IPA are companies and they use > IPA to maintain resources in their internal networks, aren't they? > > In this case I see two basic solutions how to solve the "location" issue. > > 1. BGP routing between multiple internal networks Sorry Adam, I do not want to be dismissive, and I know that in an ideal world this would be an awesome solution. Just trust me that for most cases asking someone to change their network architecture is simply impossible. We have users telling us their network admins don't even want change firewall configurations in some cases, so you can well see how they would respond to someone asking them to change their routing or enabling and using multicast. Sorry but it simply is not a solution we can consider. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On Tue, Jan 22, 2013 at 10:25:21AM -0500, Simo Sorce wrote: > On Tue, 2013-01-22 at 16:18 +0100, Adam Tkac wrote: > > Before we start talking about using DNS for this purpose, have you > > considered > > to use IP anycast for this? You can simply create multiple servers > > with same IP > > address on different places over the world. After that you announce > > this IP > > address from multiple places simultaneounsly via BGP and BGP > > automatically > > routes all clients to the closest node. Advantage is that this is > > already > > implemented, used and nothing have to be modified. > > > > Regards, Adam > > > We cannot assume our customers can influence or have access to change > BGP routing, so I excluded multicast solutions from the get go. > Also it requires more changes on the clients which is another heavy > minus. If I understand correctly, target customers of IPA are companies and they use IPA to maintain resources in their internal networks, aren't they? In this case I see two basic solutions how to solve the "location" issue. 1. BGP routing between multiple internal networks If customer wants to interconnect multiple networks (for example networks in different offices) so resources in network 1 will be accessible from network 2, he must use some kind of routing. All traffic from network 1 must go through border router and is accepted by border router in network 2: network1 <-> router1 <-> router2 <-> network2 This can be extended to multiple offices and all border routers will talk to each other. In this scenario customer can specify set of rules on each router and route traffic to services to specific locations. Please note that there is no need to announce anything to the Internet via BGP. 2. No routing between internal networks In this case networks aren't interconnected so no routing is involved. In this case "location" discovery doesn't make sense because machine in network 1 cannot access resources in network 2. So it will also use the closest service. To summarize my idea, as long as services have _same_ IP addresses in all cooperating IPA installations, which definitely make sense, you don't need to use DNS for location because routing protocol will automatically pick the closest location. I don't see any reason for modifications on clients. Everything what will be modified is routing rules on border routers. Please note that anycast != multicast. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On Tue, 2013-01-22 at 16:18 +0100, Adam Tkac wrote: > Before we start talking about using DNS for this purpose, have you > considered > to use IP anycast for this? You can simply create multiple servers > with same IP > address on different places over the world. After that you announce > this IP > address from multiple places simultaneounsly via BGP and BGP > automatically > routes all clients to the closest node. Advantage is that this is > already > implemented, used and nothing have to be modified. > > Regards, Adam > We cannot assume our customers can influence or have access to change BGP routing, so I excluded multicast solutions from the get go. Also it requires more changes on the clients which is another heavy minus. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On Mon, Jan 21, 2013 at 07:59:02PM -0500, Simo Sorce wrote: > Hello FreeIPA developers and other followers, > > we've have thought for quite a while about how to best implement > location based discovery for our clients so that we can easily redirect > group of clients to specific servers in order to better use resources > and keep traffic local to clients. > > However although we made some proposal we haven't implemented anything > so far, one reason is that all solution we came up till now were complex > and involved substantial client changes. > > I recently came up with a new take on how to resolve the problem, I've > written it up here after some minimal discussion with Petr Spacek and > others. > > It is available here: > http://www.freeipa.org/page/V3/DNS_Location_Mechanism > > > I thinks this proposal stands an actual chance at being implemented and > getting enough client support, mostly because the necessary changes to > existing clients vary from none to very minimal. > > This is proposal is not yet definitive, and is open to adjustments. > > I've also inlined a copy below for easier commenting. > Please trim out unnecessary text if you choose to reply and comment, and > keep only the relevant sections of text if you comment inline. Before we start talking about using DNS for this purpose, have you considered to use IP anycast for this? You can simply create multiple servers with same IP address on different places over the world. After that you announce this IP address from multiple places simultaneounsly via BGP and BGP automatically routes all clients to the closest node. Advantage is that this is already implemented, used and nothing have to be modified. Regards, Adam > Have a good read, > Simo. > > > > A Mechanism to allow for location based discovery > by Simo Sorce with help from Petr Spacek and others > > > Forewords > This is a new proposal (Jan 2013) to support Location Based discovery in > FreeIPA. It was inspired by this earlier proposal made a while ago. The > main difference is that it simplifies the whole management by > eliminating IP subnets and special client code while still maintaining a > great deal of flexibility. The key insight being that different > locations can configure the network to use different FreeIPA DNS > servers, that are local to the location being considered. > > > Introduction > Service Discovery is a process whereby a client uses information stored > in the network to find servers that offer a specific service. It is > useful for two reasons. First, it places the information required for > the location of servers in the network, lessening the burden of client > configuration. Second, it gives system and network administrators a > central point of control that can be used to to define an optimized > policy that determines which clients should use which server and in what > order. > > A standard for service discovery is defined in RFC 2782. This standard > defines a DNS RR with the mnemonic SRV and usage rules around it. It > allows a client to discover servers that offer a given service over a > given protocol. > > A drawback of SRV Records is that it assumes clients know the correct > DNS domain to use as the query target. Without any further information, > the client's options includes using their own DNS domain and the name of > the security domain in which the client operates (such as the domain > name associated to the Kerberos REALM the client refers to). Neither > option is likely to yield optimal results however. One key service > discovery requirement, especially in large distributed enterprises, is > to choose a server that is close to a client. However in many situation > binding the client name to a specific zone that is tied to a physical > location is not possible. And even if it were it would not address the > needs of a roaming client that moves across the networks. We cannot have > the name of a client change when it move across networks as this break > the Kerberos protocol that associates keys to a fixed host name for > Service Principals. > > The incompleteness of RFC 2782 is acknowledged by systems such as Active > Directory that contain extra functionality to augment SRV lookups to > make them site aware. The basic idea is to use a target in SRV service > discovery that is specific to a location or "site" in AD parlance. > Unfortunately AD clients rely on additional configureation or side > protocols to determine the client "site" and it is quite specific to > Microsoft technologies so the method they use is not easily portable and > reusable in other contexts nor documented in Standards or informative > IETF RFCs. > > This document specifies a protocol for location discovery based > exclusively on DNS. While the protocol itself can be fully implemented > with a normal DNS the FreeIPA mechanism is augmented by additional > 'location' awarne
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On Tue, 2013-01-22 at 15:23 +0100, Petr Spacek wrote:
> Creating per-server _locations sub-tree is very easy with current code:
> Simply
> copy&paste new bind-dyndb-ldap section to /etc/named.conf and point base DN
> to
> some server-specific part of LDAP tree:
>
> dynamic-db "ipa-local" {
> //
> arg "base cn=srv2.example.com, cn=dns-local, dc=example,dc=com";
> }
Unless you have a way to mange it via LDAP this is unworkable. Locations
should be managed via the Web UI. So you need to be able to create new
locations on the fly and change server's locations dynamically, possibly
w/o requiring a server restart, but certainly w/o requiring the DNS
admin to have direct SSH access to all boxes to go and manually change
named.conf
> Server specific _locations records live in this sub-tree and each server has
> have own view of _locations, i.e. each server could specify mapping between
> locations in own way. DNS clients will see merged DNS tree, no change on
> client side is required.
But this would require to manually change multiple records for multiple
servers in the same location, which could go wrong quite easily.
Each location configuration should be in a single place so that it is
consistent for all servers of that location and not a burden for
administration.
Also your methods puts location information out of the actual DNS, so
you can't lookup location data via DNS except for the 'default'.
But that would not be correct, we want to allow a client to lookup
location data for a non-default location, because an IPA DNS server may
very well be serving multiple locations.
> E.g. client has preferred location "brno" but the client is connected to
> network in "nyc", i.e. DNS queries are sent to servers in NYC. NYC server has
> own "_locations" sub-tree with trivial mapping "brno DNAME nyc".
>
> How to read the result: Location "Brno" is too far from "NYC", use "NYC"
> anyway! Also, "default" location could prefer local server over remote ones,
> i.e. local clients without any configuration will prefer local servers.
I am not sure how this is different from my proposal, the problem I see
is that you loose the ability to force a configuration for select client
by actually creating real DNAME records.
> There is another nice feature: "old" _ntp._udp.domain SRV records could
> contain aliases pointing to SRV records in some location, e.g. "default". In
> that case also old clients will prefer local servers over remote ones -
> almost
> with no price and with no client reconfiguration.
>
> No new concepts, no new code :-)
We can do that with a DNAME in theory, but I would rather keep current
domain records as is for now.
> There is still _location DNAME record under client's name, that stay
> unchanged. Personally, I don't like any on-the-fly record generation. Is it
> really necessary?
Who creates this record for new clients ?
How to you handle 3 locations on a single DNS server ?
Say I have a headquarters DNS setup where I want to send clients to the
engineering, sales or accounting locations depending on the client but I
have a shared local network configuration so all clients use the same
DNS server.
> In case described above I don't think so. Roaming between locations don't
> require changing any record, so configuration is static.
Yep 'static' is the issue here, we want it more dynamic, the point of
generating is that we can change the way we manage locations in future
w/o having to jump through more hops.
> Old clients would see "default" location and _location record for new clients
> could be created during ipa host-add or something similar.
We can't give out the privilege to create arbitrary DNAME records to
lower level admins, so we would have to add special code.
> > DNS Slave server problem
> Without dynamic record generation it would be possible to do zone transfers
> without any change to current code. Only one new zone (i.e. _locations part
> of
> DNS sub-tree) has to be set on each slaves and we are done.
This is true, and we can opt for this fallback initially, but I do not
want to restrict manageability just to make the job easier for one of
the cases.
> > Server Implementation
> > TODO: interaction with DNSSEC
> That it *very* important part. I have fear from so many dynamic things inside.
Yes this is indeed going to add complexity. No doubt.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] A new proopsal for Location Based Discovery
On 22.1.2013 01:59, Simo Sorce wrote:
Hello FreeIPA developers and other followers,
Roaming/Remote clients
Roaming clients or Remote clients have one big problem, although they
may have a default preferred location they move across networks and the
definition of 'location' and 'closest' server changes as they move. Yet
their name is still fixed. With a classic Bind setup this problem can
somewhat be handled by using views and changing the DNAME returned or
directly the SRV records depending on the client IP address. However
using source IP address is not always a good indicator. Clients may be
behind a NAT or maybe IP addressing is shared between multiple logical
locations within a physical network. or the client may be getting the IP
address over a VPN tunnel and so on. In general relying on IP address
information may or may not work. (There is also the minor issue that we
do not yet support views in the bind-dyndb-ldap plugin.)
Addressing the multiple locations problem
The reason to define multiple locations is that we want to redirect
clients to different servers depending on the location they belong to.
This only really makes sense if each location has its own (set of)
FreeIPA server(s).
Also usually a location corresponds to a different network so it can be
assumed the if at least one of the FreeIPA servers in each location is a
DNS enabled server and the local network configuration (DHCP) server
serves this DNS server as the primary server for the client then we can
make the reasonable assumption that a client in a specific location will
generally query a FreeIPA server in that same location for
location-specific information.
If this holds true then changing the 'default' location base on the
server's own location would effectively make clients stick to the local
servers (Assuming the location's SRV records are properly configured to
contain only local server, which we can insure through appropriate
checks in the framework)
This is another simple optimization and works for a lot of cases but not
necessarily all. However this optimization leads to another problem.
What if the client needs to belong to a specific location indipendetly
from what server they ask to, or what if we really only have a few
FreeIPA DNS servers but want to use more locations ?
One way of course is to create a fixed DNAME record for these clients,
so the defaults do not kick in. However this is rather final. Maybe the
clients needs a preference but that preference can be overridden in some
circumstances.
Choosing the right location
So the right location for a client may be a combination of a preference
and a set of requirements. One example of a requirement that can trump
any preference is a bandwidth constrained location.
Assume we have a client that normally resides in a large location. This
location has been segmented in small sublocations to better distribute
load so it has a preferred location. If we use a fixed DNAME to
represent this preference when this client roams to a bandwidth
constrained network it will try to use the slow link to call 'home' to
his usual location. This may be a serious problem.
However if we generate the default location dynamically we can easily
have rules on the bandwidth constrained location DNS servers that no
matter what is the preference any client asking for location based SRV
records will always be redirected to the local location which includes
only local servers in their SRV records.
This is quite powerful and would neatly solve many issues connected with
roaming clients.
I see two ways how to achieve server controlled "location override" as
described above.
First way is about dynamically changing the _location.client DNAME record, as
Simo proposed above.
Second way is about making DNS sub-tree "_locations.domain" per-server
specific. In that case, client's _location DNAME record points to same
("preferred") location all the time, but real records under
"preferred._locations.domain" can point to local or remote servers, it depends
on configuration.
Creating per-server _locations sub-tree is very easy with current code: Simply
copy&paste new bind-dyndb-ldap section to /etc/named.conf and point base DN to
some server-specific part of LDAP tree:
dynamic-db "ipa-local" {
//
arg "base cn=srv2.example.com, cn=dns-local, dc=example,dc=com";
}
Server specific _locations records live in this sub-tree and each server has
have own view of _locations, i.e. each server could specify mapping between
locations in own way. DNS clients will see merged DNS tree, no change on
client side is required.
E.g. client has preferred location "brno" but the client is connected to
network in "nyc", i.e. DNS queries are sent to servers in NYC. NYC server has
own "_locations" sub-tree with trivial mapping "brno DNAME nyc".
How to read the result: Location "Brno" is too far from "NYC", use "NYC"
anyway! Also, "default" location could prefer local server over remote
[Freeipa-devel] A new proopsal for Location Based Discovery
Hello FreeIPA developers and other followers, we've have thought for quite a while about how to best implement location based discovery for our clients so that we can easily redirect group of clients to specific servers in order to better use resources and keep traffic local to clients. However although we made some proposal we haven't implemented anything so far, one reason is that all solution we came up till now were complex and involved substantial client changes. I recently came up with a new take on how to resolve the problem, I've written it up here after some minimal discussion with Petr Spacek and others. It is available here: http://www.freeipa.org/page/V3/DNS_Location_Mechanism I thinks this proposal stands an actual chance at being implemented and getting enough client support, mostly because the necessary changes to existing clients vary from none to very minimal. This is proposal is not yet definitive, and is open to adjustments. I've also inlined a copy below for easier commenting. Please trim out unnecessary text if you choose to reply and comment, and keep only the relevant sections of text if you comment inline. Have a good read, Simo. A Mechanism to allow for location based discovery by Simo Sorce with help from Petr Spacek and others Forewords This is a new proposal (Jan 2013) to support Location Based discovery in FreeIPA. It was inspired by this earlier proposal made a while ago. The main difference is that it simplifies the whole management by eliminating IP subnets and special client code while still maintaining a great deal of flexibility. The key insight being that different locations can configure the network to use different FreeIPA DNS servers, that are local to the location being considered. Introduction Service Discovery is a process whereby a client uses information stored in the network to find servers that offer a specific service. It is useful for two reasons. First, it places the information required for the location of servers in the network, lessening the burden of client configuration. Second, it gives system and network administrators a central point of control that can be used to to define an optimized policy that determines which clients should use which server and in what order. A standard for service discovery is defined in RFC 2782. This standard defines a DNS RR with the mnemonic SRV and usage rules around it. It allows a client to discover servers that offer a given service over a given protocol. A drawback of SRV Records is that it assumes clients know the correct DNS domain to use as the query target. Without any further information, the client's options includes using their own DNS domain and the name of the security domain in which the client operates (such as the domain name associated to the Kerberos REALM the client refers to). Neither option is likely to yield optimal results however. One key service discovery requirement, especially in large distributed enterprises, is to choose a server that is close to a client. However in many situation binding the client name to a specific zone that is tied to a physical location is not possible. And even if it were it would not address the needs of a roaming client that moves across the networks. We cannot have the name of a client change when it move across networks as this break the Kerberos protocol that associates keys to a fixed host name for Service Principals. The incompleteness of RFC 2782 is acknowledged by systems such as Active Directory that contain extra functionality to augment SRV lookups to make them site aware. The basic idea is to use a target in SRV service discovery that is specific to a location or "site" in AD parlance. Unfortunately AD clients rely on additional configureation or side protocols to determine the client "site" and it is quite specific to Microsoft technologies so the method they use is not easily portable and reusable in other contexts nor documented in Standards or informative IETF RFCs. This document specifies a protocol for location discovery based exclusively on DNS. While the protocol itself can be fully implemented with a normal DNS the FreeIPA mechanism is augmented by additional 'location' awarness and will depend on additional computation done by the FreeIPA DNS plugins. The Discovery Protocol The main point about this protocol is the recognition that all we really need is to find a specific (set of) server(s) that a specific client needs to find. The second point is that the client has 1 bit of information that is inequivocal: its own fully qualified name. Whether this is fixed or assigned by the network (via DHCP) is not important, what matters is that the name univocally identifies this specific host in the network. Based on these two points the idea is to make the client query for a special set of SRV records keyed on the client's own DNS name. From the client persp
