[Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
Petr Spacek
pspacek at redhat.com
Tue May 29 15:16:06 UTC 2012
Hello,
for clarity: I'm not going to implement it (now). There are another features
on the table.
I'm trying to find simplest solution/workaround, because several people asked
for this feature and I think it is quite important. (Besides load-balancing
purpose it can be handy for environments with NAT in place - as Amazon EC2.)
Discussion about major changes should be read as "design for far future".
On 05/25/2012 04:10 PM, Simo Sorce wrote:
> On Thu, 2012-05-24 at 19:07 +0200, Petr Spacek wrote:
>> Hello,
>>
>> some time ago there was a request for DNS to support "routing requests to
>> local servers". Any opinions if/when do it and proposals how to do it are more
>> than welcome. My best knowledge about this problem follows:
>>
>>
>> This request actually means "differentiate answer to DNS query on client's IP
>> address basics".
>> Relevant thread on ipa-users-list:
>> https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html
>>
>> First question is: Do we want to implement it?
>> (IMHO it is very important for large-scale deployments.)
>
> I am not really sure I like it, as it makes things quite difficult to
> handle.
>
> Please think how we are going to operate if you ahve a view dfined and a
> client does a dyn DNS update.
Yes, it's a bit difficult. I propose this approach:
- add new record -> add it to "base" (shared) part
- delete record -> delete "visible" record: i.e. delete override record if it
is present, delete "base" record otherwise.
It allows clients to update own records as usual and changes will be visible
to the whole world.
One potential problem are update scripts from monitoring systems. Monitoring
system can test availability of server and dynamically adjust DNS records, if
server status has changed.
I'm not sure if some monitoring systems supports this feature directly, I
always used my own scripts. These scripts have to be changed from
nsupdate/another tool to ldapmodify, but I think it is acceptable.
...snip ...
>> Adam and I discussed possible approaches. We agreed on "stackable" approach:
>> - Store whole original DNS tree in one subtree, let say "base".
>> - Create "override" subtrees for each "locality" = set of customized records.
>> Shared records are only in "base". During DNS query processing "override"
>> subtree is searched first. If record does not exist in "override" subtree,
>> search will continue in "base" subtree.
>
> Yes, this is my first thought too.
>
>> Second question is how to realize these "overrides":
>> - Let Directory Server to do the work. If DS supports this, it is mostly done.
> Why do you need dirsrv to do anything special ?
I can save bugs in the new code (and time) if dirsrv can do it.
I played with 389 last days and unfortunately I can't find support for this
use case. (I'm pretty sure that OpenLDAP can support this scenario - that was
a reason why I started to examine this possibility in 389.)
> The simple way is to do subtree searches, if you get back more than one
> result for a specific name then you know you have views and proceed to
> filter out the one you want. The bonus here is that you can cache all
> replies if you keep different caches per view.
>
> The alternative is to add a 'viewname' or something in the filter, but
> then you need to do 2 searches and fallbacks. This sounds more
> expensive.
>
>> It do not require any change in bind-dyndb-ldap code. All merges/overrides
>> will be done on Directory server.
>
> Given we do persistent searches and we also do some caching in
> bind-dyndb-ldap we almost certainly do not want to 'fool' it by
> returning different values from DS w/o bind-dyndb-ldap knowledge.
I probably missed something, I don't see the problem. One bind-dyndb-ldap
instance is run for each "view" separately. Each instance has own caches and
other data structures. They don't know about each other.
>> Only /etc/named.conf has to be adjusted with
>> right search base and "view" clause.
>>
>> I asked on 389 mailing list and I'm waiting for reply:
>> http://lists.fedoraproject.org/pipermail/389-users/2012-May/014653.html
>>
>>
>> - Another approach is to add support directly to bind-dyndb-ldap, but it is
>> not so nice solution.
>
> Why ?
>
>> In that case both LDAP search bases have to be defined
>> in /etc/named.conf. For each DNS query is necessary to search "override" base
>> first. If required record is not present then is necessary to search through
>> "base" subtree.
>
> No, you do not need to do multiple searches, you just need to filter the
> results by view.
You are right, if we change the way how DNS data are stored in LDAP (a bit).
Mentioned idea was to create new subtree ("cn=dns-viewname") and re-use
existing driver and all tools for managing it with minimal changes.
> It would make it very easy to manage if we added a 'dnsView' attribute
> to overriding entries in the subtree. This would allow us to define a
> new overriding entry and even assign it to multiple views if the
> 'dnsView' attribute is multivalued.
>
>> With persistent search it should be better, because all records are in memory,
>> but basic principle remains same.
>
> psearch is one of the reasons we might want a dnsView attribute base
> approach instead of playing games with DS.
> I would also prefer to avoid adding more code to DS where the bind
> plugin can easily handle this data itself. Another reason is that I
> really want this plugin code to be generic and usable with other LDAP
> servers and not be tied so strictly to 389ds.
>
> Simo.
I'm not talking about new DS plugin, I wanted to use existing features.
IMHO OpenLDAP with rewrite/remap and rwm overlays can do all the work for us.
Unfortunately 389 is poor in this case (or I can't find it in manual).
Merging with another thread:
On 05/25/2012 09:20 PM, Simo Sorce wrote:
> On Fri, 2012-05-25 at 15:52 +0200, Petr Spacek wrote:
>> > On 05/24/2012 08:00 PM, Dmitri Pal wrote:
>>> > > On 05/24/2012 01:07 PM, Petr Spacek wrote:
>>> > >
>>> > > May be I am oversimplifying things but it seems that it would make
>>> > > sense
>>> > > to just have an extra multi-value attribute added to the DNS schema.
>>> > > This attribute would contain a value that would allow the entry to be
>>> > > included into the view. This way the base is the same and what the view
>>> > > exposes is just a filter. The default view would have a filter that
>>> > > matches all entries like now.
>>> > >
>>> > >
>>> > > I assume that DNS server makes it decision based on the IP so it has a
>>> > > call to get a "view" data. The ldap driver can return a filter. The DNS
>>> > > server them makes a call using this filter to get all the records that
>>> > > apply. I know it is too ldap centric. There is some abstraction in DNS
>>> > > server and we do not want to change it. But the point is there are
>>> > > probably two calls in the DNS server (have not actually confirmed):
>>> > > lookup data X by IP to understand what the view is.
>>> > > Pass data X to get the actual DNS entries.
>>> > >
>>> > > I am saying that X can be filter.
>>> > >
>>> > > Thoughts?
>> >
>> > Special attribute sounds like a good idea. It is not realizable
>> > directly, but
>> > I will explore variants with some "view" attribute.
>> >
>> > Current DNS "name" (name can potentially contain multiple records)
>> > structure
>> > is following:
>> >
>> > dn: idnsname=_kerberos._tcp,idnsname=e.localnet,cn=dns,dc=e,dc=org
>> > objectClass: idnsrecord
>> > objectClass: top
>> > idnsName: _kerberos._tcp
>> > sRVRecord: 0 100 88 unused-4-107
>> >
>> > DNS name is part of DN. It is not possible to have more objects with
>> > same DNS
>> > name and different attributes. This problem lead me to "stackable"
>> > approach.
> Yes, and we can also use multiple attributes in the same tree, although
> for clarity I probably prefer the subtree approach.
>
> So a few options:
>
> 1. all in the same subtree:
> # Normal object
> dn: idnsname=bar,idnsname=foo.org,cn=dns,dc=foo,dc=org
> objectClass: idnsrecord
> objectClass: top
> idnsName: bar
> aRecord: 192.168.12.34
> dNSTTL: 1200
>
> # Object belongin to the 'DMZ' view
> dn:cn=DMZ-bar,idnsname=foo.org,cn=dns,dc=foo,dc=org
> objectClass: idnsrecord
> objectClass: top
> objectClass: nsContainer
> cn: DMZ-bar
> idnsName: bar
> aRecord: 5.6.7.8
> dNSTTL: 3600
> idnsView: DMZ
>
>
> NOTE: I had to add nsContainer here in order to give the object a way to
> have a unique name by using the CN attribute. I am not very fond of this
> arrangement though. It is also ugly to parse out using a LDAP browser.
> It make one thing simpler in that using multiple values for dnsView you
> can assign the same entry to multiple views.
>
> 2. using per view subtrees
Generally - I like this idea.
> # Normal object
> dn: idnsname=bar,idnsname=foo.org,cn=dns,dc=foo,dc=org
> objectClass: idnsrecord
> objectClass: top
> idnsName: bar
> aRecord: 192.168.12.34
> dNSTTL: 1200
I prefer to create "_default" view for normal records (as BIND does).
e.g. dn: idnsname=bar,cn=_default,idnsname=foo.org,cn=dns,dc=foo,dc=org
It allows to treat "normal" and override records in the same way. Also it
allows to optimize query with extensibleMatch filter.
E.g. plugin is configured to serve records for "view1": Filter can be
(|(cn:dn:=view1)(cn:dn:=_default)) so LDAP server will not return unnecessary
records for view2, view3, view4 ...
Another problem to solve is how to modify SOA record/hide zone/add new zone to
view. With this view-zone-dnssubtree ordering you cannot modify SOA record or
hide the zone from certain views.
With ordering zone-view-dnssubtree situation is better. We still can run
subtree query in 'cn=dns' and as bonus it is possible to define zone only in
some views or create modified version of zone's SOA record in another views.
Problem is how to *not* override zone SOA record. One (not very nice) approach:
We can create extensibleObject and define container only with idnsName
attribute (necessary for RDN construction). "Real" zones from "fake" ones can
be distinguished by objectClass. Records are leaves under this zone record as
usual.
> # Object belongin to the 'DMZ' view
> dn:idnsname=bar,cn=DMZ,idnsname=foo.org,cn=dns,dc=foo,dc=org
> objectClass: idnsrecord
> objectClass: top
> idnsName: bar
> aRecord: 5.6.7.8
> dNSTTL: 3600
>
>
> NOTE: I prefer this method as it makes things a lot easier to manage and
> view through an LDAP broiwser, however it makes sharing entries between
> multiple views a bit awkward.
I like this idea. What about LDAP aliases? (I never used them, so I don't
know.) It is not very nice, but for limited amount of "override" records it
can be sufficient.
> 3. using only one 'views' subtree pr zone and dnsView to discrimnate
>
> # Normal object
> dn: idnsname=bar,idnsname=foo.org,cn=dns,dc=foo,dc=org
> objectClass: idnsrecord
> objectClass: top
> idnsName: bar
> aRecord: 192.168.12.34
> dNSTTL: 1200
>
> # Object belongin to the 'DMZ' view
> dn:idnsUniqueID=F6A1245-bar,cn=views,idnsname=foo.org,cn=dns,dc=foo,dc=org
> objectClass: idnsrecord
> objectClass: top
> idnsUniqueID: F6A1245-bar
> idnsName: bar
> aRecord: 5.6.7.8
> dNSTTL: 3600
> idnsView: DMZ
> idnsView: VPN
>
>
> NOTE: here I added also a idnsUniqueID as a way to have unique names so
> we can have multiple entries for the same record. This is so that you
> can have 3 different entries for the same record belonging to 3
> different views. The reason why I added the actual name after a random
> id is that this way it is simpler to recognize what it is when looking
> at an ldap browser w/o having to read the actual object attributes, it
> also make collisions a lot less likely and so it allows to keep the
> random part smaller (and thus more readable).
> Also note that I've put 2 values in idnsView, meaning that this record
> belongs to 2 separate views. This allows compact representation when
> multiple views want to redefine some records in the same way (an dothers
> in a different way, thus why 2 separate views)/
I also prefer "way 2", as I said above.
... snip ...
Thanks for your time.
Petr^2 Spacek
More information about the Freeipa-devel
mailing list