[Unbound-users] unbound views

[Attila Nagy]

Hello,

W.C.A. Wijngaards wrote:
> 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.
>   
Hmm, yes, that's what I first thought of, but running Zdenek's sample 
python program (and the modified pythonmod, which makes the source IP 
accessible) it doesn't seem to be the case.
At least, when I issue two queries from two, different machines I get 
different answers, as it should be.

>> 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?
>   
Not always. :)
Think of a DNS load balancer, which actively monitors servers and give 
back only those, which work. And because this doesn't (usually, but can, 
for example source sticky load balancing) involve the client's IP, take 
for example a location based redirector.

BTW, what I need this for is the following:
I have a service name, which must be the same for all clients (it is 
hardwired in the device). The clients are spread out in the country and 
use a normal internet connection and the normal caching nameservers (in 
this case: unbound).
The problem is that that hardwired name must resolve to an IP, which is 
close to the client. This is determined by the routers' assigned pools, 
so everything is simple in theory:
1.1.1.0/24 should resolve abcd.name to 192.168.0.1
1.1.2.0/24 should resolve abcd.name to 192.168.1.1
... and so on.
There is no given pattern, everything can be on each sides. The networks 
are aggregated (and does not change often), so it's not a great hassle 
to list them in a static config file, that's what bind's views are good 
for. But we use unbound. :)

So this is not quite internal/external (and not just two of them).

Oh, and please, don't come with anycast routing, that's what I said to 
the group, which invented this, but there are other reasons, which makes 
that unsuitable for this purpose. :)

> 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.
>   
I hope I described it above to a level, which makes it clear.

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20090811/bc906bb7/attachment.htm>