[Unbound-users] unbound views

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Attila,

On 08/11/2009 11:17 AM, Attila Nagy wrote:
> Zdenek Vasicek (author of the python module) was very kind and helped to
> make the query's source IP (and port and transport) accessible from the
> python module. This made answering queries based on the source IP
> possible with unbound.

An idea, but because the cache does not know about that
source IP it does not work.  The cache stores the result
from the python module and will then return it to everyone.

> This is pretty much fine if you want to respond according to complex
> rules (which involves source IP), but sometimes a simple "views" (like
> in bind) solution would be perfectly enough.
> 
> This, with the flexible local and stub zones configuration would satisfy
> a lot use cases.
> 
> So the question is: how hard would it be to make unbound's configuration
> source-IP aware? I mean, putting arbitrary configuration into
> netblock-indexed configuration blocks.

Easier to deploy two servers, one for internal, one external.
Changing the code to have two unbounds internally that it chooses
from based on source IP would be bloat I think.

Who needs different resolving for internal and external?
Names on the internet are names on the internet, right?

I would guess this is about authority information?
Maybe, simply block access to the local-data elements for some IPs
is do-able.  But the question, for me, is more about what is
really needed here.  If you want infinite customizability then
deploy two servers.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkqBV8UACgkQkDLqNwOhpPgNbACfbpDqg51kJpQ+io1BXFpbJV8u
dPMAnAh5HuhbrTqPZemA3VTB4liI9zXI
=rppk
-----END PGP SIGNATURE-----