[Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]

Simo Sorce simo at redhat.com
Fri May 25 19:20:49 UTC 2012


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:
> >> 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.)
> >>
> >>
> >> It is related to IPA ticket #122 at architecture level:
> >> IPA DNS integration should support GeoIP
> >> https://fedorahosted.org/freeipa/ticket/122
> >> IMHO it is better to support generic "locations" defined by user than
> >> real Geo-IP:
> >> - at least private IP addresses will be problematic
> >> - real Geo-IP database is huge and can slow all things down
> >>
> >>
> >> Bind-dyndb-ldap plugin supports BIND "views" already. It should be
> >> possible to define multiple plugin instances with different ldap
> >> search base and let it to serve records.
> >>
> >> The main problem problem is managing DNS subtree in LDAP. With current
> >> implementation you have to copy whole subtree to another place and
> >> then change necessary records. Problem is with maintaining "base"
> >> (non-overridden) records - you have to do same change n-times.
> >>
> >>
> >> 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.
> >>
> >>
> >> Second question is how to realize these "overrides":
> >> - Let Directory Server to do the work. If DS supports this, it is
> >> mostly done.
> >> It do not require any change in bind-dyndb-ldap code. All
> >> merges/overrides will be done on Directory server. 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. 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.
> >> With persistent search it should be better, because all records are in
> >> memory, but basic principle remains same.
> >>
> >>
> >> Thanks for all opinions.
>  >>
> >> Petr^2 Spacek
> >
> > 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

# 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: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.


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'm looking into "Views" in DS now.

We do not want to make this code 389DS specific, anyways, so I think we
should not go there.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list