Re: [Freeipa-users] DNS views: request for comments
Hello, On 25.10.2013 13:28, david t. klein wrote: In a previous life, I was DNS hostmaster for a large Fortune-rated firm for about a year. We used views in the typical way (internal vs external), but we also had a third view, in which we black-holed domains known to either propagate viruses or to be used for C&C. We would forward the traffic to the address hosting that view (an IP anycasted address, hosted on our DNS appliances), which would return the address of our malware analysis lab for known bad zones, and would forward everything else to our recursive/caching DNS proxies. This is very interesting. Could you elaborate how clients were directed to the third view? I.e. how is the a query associated with the view? External = IP addresses outside corporate network Internal = IP addresses inside corporate network Blackhole = ? I'm not following ... Did you mean that the 'internal' view contains some set of 'well known names' and those names were (only in the internal view) redirected to the lab? Or something else? Could you tell us if the following proposal for DNS views in FreeIPA seems okay to you, please? The proposal: - There is one default view: Any zones and records can be configured in this view. The default view can be even empty. - Other views 'inherit' data from the default view. Inheritance works in this way: Example: Default view definition: - gateway.example.com. A 203.0.113.66 - gateway.example.com. TXT "this record came from base" - example.com MX 10 gateway.example.com. Another-view definition (with implicit inheritance from default view): - gateway.example.com. A 10.1.1.1 Result for 'another-view': - gateway.example.com. A 10.1.1.1 - example.com MX 10 gateway.example.com. => A and TXT records for the name 'gateway.example.com.' from default view were not inherited because override was present in the 'another-view'. => MX record for name 'example.com' was inherited because there is no override with this name in the view. => Modification done in 'default view' will not affect 'another-view' in any way if a override is present, so there can't be information leak from 'default' view (I mean a leak caused by modification of existing record). Any feedback is more than welcome. Thank you very much for your time! Petr^2 Spacek -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Spacek Sent: Tuesday, October 01, 2013 10:11 AM To: freeipa-users@redhat.com Subject: [Freeipa-users] DNS views: request for comments 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! ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] DNS views: request for comments
In a previous life, I was DNS hostmaster for a large Fortune-rated firm for about a year. We used views in the typical way (internal vs external), but we also had a third view, in which we black-holed domains known to either propagate viruses or to be used for C&C. We would forward the traffic to the address hosting that view (an IP anycasted address, hosted on our DNS appliances), which would return the address of our malware analysis lab for known bad zones, and would forward everything else to our recursive/caching DNS proxies. -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Spacek Sent: Tuesday, October 01, 2013 10:11 AM To: freeipa-users@redhat.com Subject: [Freeipa-users] DNS views: request for comments 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! -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6767 - Release Date: 10/20/13 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] DNS views: request for comments
On 22.10.2013 19:31, Simo Sorce wrote: On Tue, 2013-10-22 at 18:14 +0200, Petr Spacek wrote: On 22.10.2013 16:44, Martin Kosek wrote: On 10/21/2013 10:57 PM, Simo Sorce wrote: On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote: On 1.10.2013 17:11, Petr Spacek wrote: [...] Doesn't this scheme means you always have to do 2 searches ? One to find if the object is in the view and one to the base ? We could use multivalued RDNs to achieve something similar but that will require you only one search (assuming it matters). Reading = 0 searches :-D Psearch/SyncRepl delivers the data from LDAP asynchronously to the plugin, almost immediatelly after each change in LDAP. This is true only with the current specific implementation, I think we want to create a schema that can be used with an alternative implementation w/o forcing the use of syncrepl/psearch and synchronization. Good point! - 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'? I think this would be acceptable, however what happens if then someone deletes the base object and later on again recreates it ? Will the view still 'mask' it ? My original idea was: "Yes, it will." The main reason is that user can have some tools which do LDAP delete/add instead of replace/modify, so some data from the base could be accidentally exposed if we delete 'override' automatically with base object. Ok. Is this the actual desired outcome maybe ? This is a good question :-) This is most generic/powerful mechanism but it could create some nasty surprises. One drawback is that you have to go and add 'mask'/'delete' record to affected views (if necessary) when you add a record to the base. As long as it is possible it is not surprising, I would expect that when using inheritance. Another variants: aa) Do overrides on name-level instead of record level. I.e. records for particular name will not be inherited if the override is present. Example: Base definition: - gateway.example.com. A 203.0.113.66 - gateway.example.com. TXT "this record came from base" - example.com MX 10 gateway.example.com. View definition: - gateway.example.com. A 10.1.1.1 Result - view: - gateway.example.com. A 10.1.1.1 - example.com MX 10 gateway.example.com. I think this is preferable indeed. => A and TXT records from base were not inherited because override for the name 'gateway' was present in the view. => MX record for name 'example.com' was inherited because there is no override with this name in the view. => Modification done in 'base' will not affect view in any way if the override is present, so there can't be information leak. => This approach doesn't require ;x-deleted or cn=deleted trick. It till requires an empty object to mask though, but that is fine I think, I like this better. Me too. Reasonable use will be to fill 'the base' with all shared names/records and use views mainly for addition and minor edits, so empty objects will not appear so often. ab) No inheritance at all. This is what BIND9 does if dynamic updates are enabled. After first update the inheritance relationship is broken and views operate independently. I am not sure what this means exactly, our server uses Dynamic Updates by default, so I am not sure that 'breaking inheritance' on dynamic updates makes much sense, we'd have no inheritance at all. "we'd have no inheritance at all." Exactly. BIND9 simply copies inherited records to each view during start up and then views operate independently. (If you use dynamic updates.) Obviously, this is simplest and clearest solution. Maybe that it is enough for most users, look at the support in open source software ... Maybe that some UI support for copying from one view to the other would be enough? It is certainly a first implementation option. Start w/o inheritance but do not preclude the option of adding it later. This is exactly why we have this discussion now. I want to prepare some future-proof plan. We have to find if 1:1 mapping between 'name+view' pair will be always here (even with views, inheritance and the other stuff). All bind-dyndb-ldap depend on this relationship (at the moment), so I want to know if we are going to break it or not. I don't want to finish DNSSEC and then start re-writing it again because of views ... Should we allow Dynamic Updates in Views at all ? It would be too simple without dynamic updates :-) I think that we should allow updates, otherwise we can drop all the code for DNS updates from SSSD, ipa-client-install etc. Of course, we can implement first version without support for updates and add it later, if there is a d
Re: [Freeipa-users] DNS views: request for comments
On Tue, 2013-10-22 at 18:14 +0200, Petr Spacek wrote: > On 22.10.2013 16:44, Martin Kosek wrote: > > On 10/21/2013 10:57 PM, Simo Sorce wrote: > >> Comments inline. > >> > >> On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote: > >>> On 1.10.2013 17:11, Petr Spacek wrote: > >> > >> [trim] > > I should make one thing clear: > We already do two-way synchronization between LDAP and DNS server (run-time). > > Persistent search (and now syncrepl) dumps content of LDAP database to a > internal database in DNS server and the bind-dyndb-ldap plugin operates on > this internal database. I.e. changes done in LDAP are asynchronously applied > to internal database and vice versa, changes done via DNS protocol are > written > back to LDAP. > > This is why we are able to apply any change in LDAP almost immediatelly to > DNS > data. It is true that there are nasty corner cases, but up to now we didn't > receive many complains about data inconsistency. (This will change after the > major refactoring in bind-dyndb-ldap 4.0 :-)) Yes but this synchronization is tightly coupled and controlled and only the LDAP data is considered authoritative. It's quite different from using things like zone transfers to perform some sort of 'generic' synchronization. [..] > >> Doesn't this scheme means you always have to do 2 searches ? One to find > >> if the object is in the view and one to the base ? > >> > >> We could use multivalued RDNs to achieve something similar but that will > >> require you only one search (assuming it matters). > > Reading = 0 searches :-D Psearch/SyncRepl delivers the data from LDAP > asynchronously to the plugin, almost immediatelly after each change in LDAP. This is true only with the current specific implementation, I think we want to create a schema that can be used with an alternative implementation w/o forcing the use of syncrepl/psearch and synchronization. > >>> - 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'? > >> > >> I think this would be acceptable, however what happens if then someone > >> deletes the base object and later on again recreates it ? > >> > >> Will the view still 'mask' it ? > My original idea was: "Yes, it will." The main reason is that user can have > some tools which do LDAP delete/add instead of replace/modify, so some data > from the base could be accidentally exposed if we delete 'override' > automatically with base object. Ok. > >> Is this the actual desired outcome maybe ? > This is a good question :-) This is most generic/powerful mechanism but it > could create some nasty surprises. One drawback is that you have to go and > add > 'mask'/'delete' record to affected views (if necessary) when you add a record > to the base. As long as it is possible it is not surprising, I would expect that when using inheritance. > Another variants: > aa) Do overrides on name-level instead of record level. I.e. records for > particular name will not be inherited if the override is present. > > Example: > Base definition: > - gateway.example.com. A 203.0.113.66 > - gateway.example.com. TXT "this record came from base" > - example.com MX 10 gateway.example.com. > > View definition: > - gateway.example.com. A 10.1.1.1 > > Result - view: > - gateway.example.com. A 10.1.1.1 > - example.com MX 10 gateway.example.com. I think this is preferable indeed. > => A and TXT records from base were not inherited because override for the > name 'gateway' was present in the view. > => MX record for name 'example.com' was inherited because there is no > override > with this name in the view. > => Modification done in 'base' will not affect view in any way if the > override > is present, so there can't be information leak. > => This approach doesn't require ;x-deleted or cn=deleted trick. It till requires an empty object to mask though, but that is fine I think, I like this better. > ab) No inheritance at all. > This is what BIND9 does if dynamic updates are enabled. After first update > the > inheritance relationship is broken and views operate independently. I am not sure what this means exactly, our server uses Dynamic Updates by default, so I am not sure that 'breaking inheritance' on dynamic updates makes much sense, we'd have no inheritance at all. > Obviously, this is simplest and clearest solution. Maybe that it is enough > for > most users, look at the support in open source software ... > > Maybe that some UI support for copying from one view to the other would be > enough? It is certainly a first implementation option. Start w/o inheritance but do
Re: [Freeipa-users] DNS views: request for comments
On 22.10.2013 16:44, Martin Kosek wrote:
On 10/21/2013 10:57 PM, Simo Sorce wrote:
Comments inline.
On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote:
On 1.10.2013 17:11, Petr Spacek wrote:
[trim]
I should make one thing clear:
We already do two-way synchronization between LDAP and DNS server (run-time).
Persistent search (and now syncrepl) dumps content of LDAP database to a
internal database in DNS server and the bind-dyndb-ldap plugin operates on
this internal database. I.e. changes done in LDAP are asynchronously applied
to internal database and vice versa, changes done via DNS protocol are written
back to LDAP.
This is why we are able to apply any change in LDAP almost immediatelly to DNS
data. It is true that there are nasty corner cases, but up to now we didn't
receive many complains about data inconsistency. (This will change after the
major refactoring in bind-dyndb-ldap 4.0 :-))
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
Doesn't this scheme means you always have to do 2 searches ? One to find
if the object is in the view and one to the base ?
We could use multivalued RDNs to achieve something similar but that will
require you only one search (assuming it matters).
Reading = 0 searches :-D Psearch/SyncRepl delivers the data from LDAP
asynchronously to the plugin, almost immediatelly after each change in LDAP.
- 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'?
I think this would be acceptable, however what happens if then someone
deletes the base object and later on again recreates it ?
Will the view still 'mask' it ?
My original idea was: "Yes, it will." The main reason is that user can have
some tools which do LDAP delete/add instead of replace/modify, so some data
from the base could be accidentally exposed if we delete 'override'
automatically with base object.
Is this the actual desired outcome maybe ?
This is a good question :-) This is most generic/powerful mechanism but it
could create some nasty surprises. One drawback is that you have to go and add
'mask'/'delete' record to affected views (if necessary) when you add a record
to the base.
Another variants:
aa) Do overrides on name-level instead of record level. I.e. records for
particular name will not be inherited if the override is present.
Example:
Base definition:
- gateway.example.com. A 203.0.113.66
- gateway.example.com. TXT "this record came from base"
- example.com MX 10 gateway.example.com.
View definition:
- gateway.example.com. A 10.1.1.1
Result - view:
- gateway.example.com. A 10.1.1.1
- example.com MX 10 gateway.example.com.
=> A and TXT records from base were not inherited because override for the
name 'gateway' was present in the view.
=> MX record for name 'example.com' was inherited because there is no override
with this name in the view.
=> Modification done in 'base' will not affect view in any way if the override
is present, so there can't be information leak.
=> This approach doesn't require ;x-deleted or cn=deleted trick.
ab) No inheritance at all.
This is what BIND9 does if dynamic updates are enabled. After first update the
inheritance relationship is b
Re: [Freeipa-users] DNS views: request for comments
On 10/21/2013 10:57 PM, Simo Sorce wrote:
> Comments inline.
>
> On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote:
>> On 1.10.2013 17:11, Petr Spacek wrote:
>
> [trim]
>
>> 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
>
> Doesn't this scheme means you always have to do 2 searches ? One to find
> if the object is in the view and one to the base ?
>
> We could use multivalued RDNs to achieve something similar but that will
> require you only one search (assuming it matters).
>
>> - 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'?
>
> I think this would be acceptable, however what happens if then someone
> deletes the base object and later on again recreates it ?
>
> Will the view still 'mask' it ?
> Is this the actual desired outcome maybe ?
>
> Should we allow Dynamic Updates in Views at all ?
>
>> - The other option is to store deleted attributes in separate object:
>> DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns
>
> This sound cumbersome and require a 3rd search for every query, nack :)
>
>
> I like variant A, I think it is the most sensible and the only one
> really needed. People have an internal view and want to 'filter' it some
> for the external world or similar.
>
>
>> 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!)
>
> Sound very complex not only to build, but to explain to admins as well,
> is anyone actually going to need this level of complexity, what scenario
> would really benefit from this that can't be done with A ?
>
>
>> 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
Re: [Freeipa-users] DNS views: request for comments
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: > > mailA192.0.2.1 > > > > zone file internal.db: > > $INCLUDE external.db > > shellA10.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: > > gitA10.3.3.33 > > mailA192.0.2.1 > > shellA10.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, th
Re: [Freeipa-users] DNS views: request for comments
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: mailA192.0.2.1 zone file internal.db: $INCLUDE external.db shellA10.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: gitA10.3.3.33 mailA192.0.2.1 shellA10.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 Re
Re: [Freeipa-users] DNS views: request for comments
Comments inline.
On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote:
> On 1.10.2013 17:11, Petr Spacek wrote:
[trim]
> 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
Doesn't this scheme means you always have to do 2 searches ? One to find
if the object is in the view and one to the base ?
We could use multivalued RDNs to achieve something similar but that will
require you only one search (assuming it matters).
> - 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'?
I think this would be acceptable, however what happens if then someone
deletes the base object and later on again recreates it ?
Will the view still 'mask' it ?
Is this the actual desired outcome maybe ?
Should we allow Dynamic Updates in Views at all ?
> - The other option is to store deleted attributes in separate object:
> DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns
This sound cumbersome and require a 3rd search for every query, nack :)
I like variant A, I think it is the most sensible and the only one
really needed. People have an internal view and want to 'filter' it some
for the external world or similar.
> 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!)
Sound very complex not only to build, but to explain to admins as well,
is anyone actually going to need this level of complexity, what scenario
would really benefit from this that can't be done with A ?
> 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 i
Re: [Freeipa-users] DNS views: request for comments
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: > mailA192.0.2.1 > > zone file internal.db: > $INCLUDE external.db > shellA10.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: > gitA10.3.3.33 > mailA192.0.2.1 > shellA10.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 h
Re: [Freeipa-users] DNS views: request for comments
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: mailA 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 mailA 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 o
Re: [Freeipa-users] DNS views: request for comments
Hi, On Tue, Oct 01, 2013 at 05:11:16PM +0200, Petr Spacek wrote: > Questions are: > - For what purpose do you use views? I see only use for 2 views: a) Internal clients, domain members. They - see everything (internet DNS records plus IPA domain data) - can request recursive lookups - one could consider DNS updates here b) Internet view - basically just handing out a single zone to the internet - no AXFR, no reqursive lookups, maybe rate limiting etc. as this is internet facing Christian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] DNS views: request for comments
On 10/01/2013 09:11 AM, 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! We use split-horizon, or DNS views, very simply. We have an internal view and an external view. I am not really sure if I buy into the whole security aspect of views, however with NAT it seems pointless to publish all of your non routable records out there in the world. Hence internal and external. I have spoken with other organizations that have many views ( a view for the Tokyo office, a view for the Beijing office, etc.), however for the most part they are all trying to get to a simpler internal and external only view to save their sanity. I do share data between views. In my zone I have a common file of all data that is going to be in both views which is then included in the respective view files. It just makes it simpler to edit it in one place. And in fact in our case the common file is the external view as the internal view only adds entries. If that make sense. The zones are all dynamic in my case, this just simplifies key management for DNSSEC as I allow BIND to handle most of the work. So yes I use DNS updates. However for the most part what I end up doing is freezing the zone/view editing the file and then thawing the zone/view. However, my needs are very modest. Views and DNSSEC are the only two reasons why I don't use the integrated DNS that is part of IPA. Y'all fix these two and you got me :). I can't speak much for the LDAP layout, y'all are better than me in that regard. But the above is my general usage scenario. -Erinn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
