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?
-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
