[Freeipa-users] DNS views: request for comments

Tue Oct 22 08:20:36 UTC 2013

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