[Freeipa-users] DNS views: request for comments

[Petr Spacek]

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.

-- 
Petr^2 Spacek