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

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to