[Freeipa-users] DNS views: request for comments

Tue Oct 22 07:29:26 UTC 2013

On 21.10.2013 21:13, 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?

It should be finished by the end of May 2014. (I assume the Martin^2 doesn't 
want to spent another year with this thesis ... :-))

-- 
Petr^2 Spacek