[Freeipa-users] DNS views: request for comments

[Petr Spacek]

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-bounces at redhat.com
> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek
> Sent: Tuesday, October 01, 2013 10:11 AM
> To: freeipa-users at 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!