Hello,
W.C.A. Wijngaards 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,
