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
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users