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

Reply via email to