On Mon, 2013-10-21 at 15:13 -0400, Dmitri Pal wrote: > On 10/21/2013 12:48 PM, Petr Spacek wrote: > > On 1.10.2013 17:11, Petr Spacek wrote: > >> Hello list, > >> > >> we would like to get more details about DNS views and how you use > >> them in real > >> life. Also, any idea how user a interface should work is more than > >> welcome! > >> > >> (If you don't know views, read it as "differentiate answer to a DNS > >> query on > >> client's IP address basics".) > >> > >> > >> Questions are: > >> - For what purpose do you use views? > >> E.g. handling clients inside/outside of company network (e.g. hiding > >> internal > >> names); Selecting nearest server in a big network; Some other weird > >> 'Cloud' > >> scenarios etc. etc. > >> > >> - How many views do you use? > >> > >> - Do you share some data between views? How did you solve that? Do > >> you use > >> some user interface for that? > >> > >> - Do you use DNS updates? (nsupdate/RFC 2136/RFC 3007) > >> > >> Previous discussions about DNS views: > >> https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html > >> https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html > >> > >> Related tickets & bugs: > >> https://fedorahosted.org/freeipa/ticket/2802 > >> https://bugzilla.redhat.com/show_bug.cgi?id=815621 > >> https://fedorahosted.org/freeipa/ticket/3725 > >> https://fedorahosted.org/bind-dyndb-ldap/ticket/69 > >> > >> > >> The next step will be to design LDAP schema for DNS data with views ... > >> > >> I can see three basic options: > >> > >> 1) Resign from any data sharing, which will make the thing pretty > >> easy :-) > >> In that case 'view1' will be represented by one sub-tree in LDAP, > >> 'view2' will > >> be another sub-tree etc. > >> > >> 2) Select one sub-tree which will be 'the base' containing all shared > >> records. > >> All other views will inherit and override data from the shared 'base'. > >> > >> 3) Make it as general as possible and allow multiple levels of > >> inheritance. > >> View3 inherits from View2 and it inherits from Base. > >> (View3 <- View2 <- Base) > >> > >> It is basically generalized variant (2), but it could require > >> different LDAP > >> schema. > >> > >> > >> Please post your opinions! > > > > I spent some time investigating how DNS views work in various DNS > > servers. I hope that it will help us to find some balance between real > > world requirements and complexity. > > > > The next section discusses possible LDAP schema and semantics for our > > DNS views implementation. Feel free to jump directly to the proposal > > if you have some particular idea how it should work. > > > > > > Support for DNS views in server software > > ======================================== > > I have tried to find how widely DNS views are supported by various > > software packages. > > > > Open Source software > > -------------------- > > PowerDNS > > - only specialized backend for Geo->something mapping > > - no inheritance > > - no dynamic updates > > - > > http://wiki.powerdns.com/trac/browser/trunk/pdns/modules/geobackend/README > > > > Djbdns/tinydns > > - no inheritance > > - non-standard dynamic updates (?? via external tools, I'm not 100 % > > sure) > > - can differentiate answers on IP-prefix basics: > > http://cr.yp.to/djbdns/tinydns-data.html (search for "ipprefix") > > > > Dnsmasq > > - subnet-based selection for A records only (based on client's subnet) > > - no inheritance > > - dynamic update only from built-in DHCP server > > http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html (see option > > --localise-queries) > > > > > > BIND 9 > > - full support for DNS views > > - each view can be totally independent on other views > > - inheritance is done via $INCLUDE directive in zone file > > - in any case, a update affects only DNS view where the update was > > received > > - limitations: > > -- inherited data can be modified only via addition; > > modification/deletion to the inherited data is not possible (you have > > to break inheritance if you have to modify/delete inherited data) > > -- any dynamic update breaks inheritance > > > > BIND 9 examples: > > Example external view is subset of company-internal view. > > > > zone file external.db: > > mail A 192.0.2.1 > > > > zone file internal.db: > > $INCLUDE external.db > > shell A 10.1.2.3 > > > > Imagine that internal view was updated via DNS update, a record for > > name "git" was added. The resulting zone file internal.db will look like: > > git A 10.3.3.33 > > mail A 192.0.2.1 > > shell A 10.1.1.1 > > > > You can see that inheritance from the external view was broken and all > > records from external view were copied to the internal view. > > > > It is possible to use multiple levels of $INCLUDE, but then thigs > > become twisted. > > > > > > Proprietary software > > -------------------- > > Simple DNS Plus > > - only special handling "for NAT": > > "In DNS responses to DNS requests from LAN clients only, this function > > changes host records which are pointing to a public IP address of the > > NAT router to point to the corresponding private IP address of a local > > server." > > - http://www.simpledns.com/help/v52/wd_opt_dnsnatlan.htm > > > > InfoBlox > > - full support for DNS views > > - each view can be totally independent on other views > > - DNS object hierarchy: > > 1. one view = set of zones > > 2. one zone = set of records + set of shared record groups > > 3. shared record group = set of records shared between DNS zones > > - inheritance is realized via "Shared Record Groups" (see page 465): > > -- records are grouped to named group called "Shared Record Group" > > -- the group is associated with one or more DNS *zones* > > -- there is single-level inheritance only > > -- E.g. the same set of MX records can be present in DNS zone > > example.com and eshop.example.com. I.e. mail server addresses are > > managed from single place, it is not necessary to change MX records > > separelly for example.com and eshop.example.com. > > -- In case of FreeIPA it could be group of all SRV or NS records so > > all records for a new replica have to be created only on single place > > and the change will affect all FreeIPA-managed DNS zones. > > - only one DNS view can receive the dynamic DNS updates (page 388) > > - it is unclear if the same limitations for inheritance apply or not > > - > > http://dloads.infoblox.com/direct/appliance/NIOS/NIOS_AdminGuide_6.5.pdf > > > > Nominum Vantio > > - caching only (I guess) - listed as an extreme example > > - there is not much public details about that, but this is what they > > claim: > > "Lightweight Views take the “view” concept of the server to > > the ultimate extent, where each individual user can have their own > > view. Policies defining how queries are handled can be applied to each > > view, effectively enabling a personal Internet for each subscriber." > > - http://nominum.com/assets/Documents/Datasheets/vantio-datasheet.pdf > > > > > > Proposal - variant A ("classical" views) > > ==================== > > - keep it simple :-) > > - single level inheritance, all views inherit from 'base' (Base is our > > current cn=dns subtree, so old and new plugins can co-exist. The base > > can be empty.) > > - the data in views can be modified via DNS updates, a change done to > > inherited data creates an override (BIND9 does the same): e.g. name > > 'r1.z.' is shared between View1 and View2. Value change in View1 > > doesn't affect View2. > > - particular record from the 'base' can be overriden > > (deleted/replaced) in any view > > - changes done to the base are propagated to all views > > > > LDAP schema > > ----------- > > My goal is to maintain 1:1 mapping between "name+view" pair and LDAP > > DN. This is crucial for DNS updates. The other option is to maintain > > some 'record->LDAP DN database' or do a LDAP search before each DNS > > update - I would like to avoid that. > > > > Each view is stored as separate object under cn=dns. > > DN: idnsView=view1, cn=dns > > - this object stores settings specific to particular view (allowed > > clients, recursion ...) > > > > Zone in particular view is stored inside view container: > > DN: idnsName=zone1, idnsView=view1, dn=dns > > - this object can be empty container > > - attributes without explicit configuration are inherited from the base > > - a zone doesn't appear in the DNS view if the container is not > > present (i.e. it is possible to hide the zone from particular view) > > > > 'Override' records for particular name in zone and view are stored as: > > DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns > > - values added on top of inherited set are represented as normal DNS > > attributes: e.g. aRecord: 192.0.2.1 > > - values deleted from inherited set - *are open question*: It would be > > great if we could store it under the same object as additions, it > > would make implementation a bit simpler. > > - Would it be acceptable to store override 'delete TXT record "hello"' > > as attribute 'tXTRecord;x-deleted: test'? > > - The other option is to store deleted attributes in separate object: > > DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns > > > > > > Proposal - variant B (shared record groups) > > ==================== > > - not so simple to implement, especially update-performance could be > > an issue > > - multiple zones can share the same record group > > - each view can contain arbitrary zones anf those zones can inherit > > arbitrary record groups - inheritance is fully configurable > > - the data in views can be modified via DNS updates, a change done to > > inherited data creates an override (BIND9 does the same): e.g. name > > 'r1.z.' is shared between View1 and View2. Value change in View1 > > doesn't affect View2. > > - particular record from any shared record group can be overriden > > (deleted/replaced) in any zone in any view > > - changes done to the shared record group are propagated to all views > > (this is the hard part!) > > > > > > LDAP schema > > ----------- > > Group of shared records - container: > > DN: idnsRecordGroup=group1, cn=dns > > > > One shared name: > > DN: idnsName=record1, idnsRecordGroup=group1, cn=dns > > - contains DNS records for that name as usual > > > > Each view is stored as separate object under cn=dns. > > DN: idnsView=view1, cn=dns > > > > Zone in particular view is stored inside view container: > > DN: idnsName=zone1, idnsView=view1, dn=dns > > - zone has a attribute with DNs of inherited record groups > > > > 'Override' records for particular name in zone and view are stored as: > > DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns > > > > > > After each change to any data we have to compute new resulting value. > > It means to combine the data for particular name from all record > > groups and then apply overrides for particular instance. > > > > It means a lot of bookkeeping after each change ... > > > > > > Proposal - variant 0 > > ==================== > > Do not implement it in bind-dyndb-ldap and wait if Martin Basti > > succeeds with his thesis. He is trying to design and implement some > > generic/pluggable LDAP<->DNS synchronization mechanism. > > > > Personally, I think that variant "0" is the best one! :-D One of side > > effects is that our depedency on BIND 9 will be lowered and most of > > the work will be deferred to the real DNS server. > > > What is the time line for this thesis? >
Hello, deadline is 2014-05-28. But I hope, I will have my thesis useful earlier. :) -- Martin Basti _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
