[Freeipa-users] DNS views: request for comments

[Dmitri Pal]

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/