Discussion:
[Unbound-users] combining python + 2 iterator modules
Petr Spacek
2015-01-21 22:05:31 UTC
Permalink
Hello list,

I would like to know if it is possible to somehow combine 1 custom python
module with two instances of iterator modules (with different configurations).

I'm trying to get structure like this:

python module -> validator -> iterator 1
-> iterator 2

The Python module should pass the query to the validator & iterator 1 tandem,
wait for results from validator and conditionally re-query iterator 2.

Iterator 1 should be real iterator and iterator 2 could be a stub resolver if
it helps.

Thank you very much for any advice!
--
Petr Spacek @ Red Hat
Yuri Schaeffer
2015-01-22 09:37:01 UTC
Permalink
Hi Petr,
Post by Petr Spacek
I would like to know if it is possible to somehow combine 1 custom
python module with two instances of iterator modules (with
different configurations).
I don't see a way to do that within a reasonable amount of work. Might
I suggest sharing the problem you are trying to solve with the list,
rather than your solution?

//Yuri
Petr Spacek
2015-01-22 17:00:26 UTC
Permalink
Post by Yuri Schaeffer
Hi Petr,
Post by Petr Spacek
I would like to know if it is possible to somehow combine 1 custom
python module with two instances of iterator modules (with different
configurations).
I don't see a way to do that within a reasonable amount of work. Might I
suggest sharing the problem you are trying to solve with the list, rather
than your solution?
The purpose of this exercise is to help with DNSSEC validation on roaming
machines & support DNS split views at the same time.

Fundamental assumption:
Internal & external DNS view are both signed or both unsigned.


It should work like this:
1) Probing/preparation when client connects to a network:
Client probes if servers advertised by DHCP support DNSSEC:
a) If DHCP-advertised servers *do support* DNSSEC -> use them for
everything, do full validation.
b) If DHCP-advertised servers *do not support* DNSSEC:
- Find a hole in firewall so we can contact DNS servers on public Internet.

2) Query processing for cases where local servers do not support DNSSEC:
- Do recursion and validation using external DNS servers.
a) If result is SECURE -> return result.
b) If result is provably INSECURE -> query local servers advertised by DHCP
and return whatever they returned.


This algorithm covers DNS split-views with internal unsigned views pretty
nicely as long as the fundamental assumption holds.

Thank you for any implementation advice!
--
Petr Spacek @ Red Hat
Paul Wouters
2015-01-22 17:10:42 UTC
Permalink
Post by Petr Spacek
- Do recursion and validation using external DNS servers.
a) If result is SECURE -> return result.
b) If result is provably INSECURE -> query local servers advertised by DHCP
and return whatever they returned.
Is this really worth the effort and the risk? This is clearly not ideal
when at a coffeeshop. And as a concept, unexplainable to endusers.
Post by Petr Spacek
This algorithm covers DNS split-views with internal unsigned views pretty
nicely as long as the fundamental assumption holds.
In my opinion, the way to do this is simply an option in Network Manager
that says "when on this network, trust and use the local DNS".

Simple. easy to explain to endusers. Easy to implement without python
modules. Does not change behaviour based on whether domains are DNSSEC
signed.

Paul
Yuri Schaeffer
2015-01-23 10:52:11 UTC
Permalink
Hi Petr,

I think Paul makes an excellent point. Also, having this 'internal
view' in your local Unbound cache seems less than ideal for roaming
users.
Post by Petr Spacek
This algorithm covers DNS split-views with internal unsigned views
pretty nicely as long as the fundamental assumption holds.
If it doesn't, your DNS problems get again a little harder to debug.
At this point I have no suggestion for a feasible solution though.

//Yuri
Petr Spacek
2015-01-23 11:19:54 UTC
Permalink
Post by Yuri Schaeffer
Hi Petr,
I think Paul makes an excellent point. Also, having this 'internal
Let me clarify my design goals:
1) Get a reliable DNSSEC validator for roaming clients.
2) It has to handle DNS split views.
3) It can *not* rely on untrusted information (like DHCP search lists etc.)
4) It can *not* rely on explicit configuration from user or network administrator.

This is of course a huge hack but to me it seems as an inevitable hack if we
want to deploy DNSSEC validators everywhere.

BTW Fedora 22 (to be finished around May 2015) is planned to contain DNSSEC
validator in every installation so it can't possibly rely on manual
configuration just to make DNS working again (if local network is broken).
Post by Yuri Schaeffer
view' in your local Unbound cache seems less than ideal for roaming
users.
I did not describe implementation details in depth. One of details is that
cache should be flushed after configuration change. This (theoretical) module
should be used along with dnssec-trigger or similar system which will handle
cache maintenance as necessary.

(BTW an option to flush only unsigned records from cache would be a nice thing
to have.)
Post by Yuri Schaeffer
Post by Petr Spacek
This algorithm covers DNS split-views with internal unsigned views
pretty nicely as long as the fundamental assumption holds.
If it doesn't, your DNS problems get again a little harder to debug.
At this point I have no suggestion for a feasible solution though.
I'm definitely open to suggestions how to implement a system which fulfills
goals described above.

In meantime (before someone invents something better :-) I would be very glad
for any advice how the original design could be implemented with current
Unbound codebase.
--
Petr Spacek @ Red Hat
Yuri Schaeffer
2015-01-23 13:12:48 UTC
Permalink
Post by Petr Spacek
In meantime (before someone invents something better :-) I would be
very glad for any advice how the original design could be
implemented with current Unbound codebase.
I wouldn't even know where to begin using unbound.

My advice would be not to touch unbound at all but instead implement a
very small stub talking to Unbound and your advertised resolver
simultaneously. Which relays the answer it likes best. As an added
bonus this can be done in parallel and no caches need to be flushed on
network events.

//Yuri

Loading...