[Unbound-users] unbound views

[Ondřej Surý]

Seems like you are trying to fit square brick into a round hole. Try setting
zero ttl when returnong response from python, so unbound doesn't cache the
result. Or try evldns framework which Ray has just released to create custom
dns server.

Ondrej

Dne 118 2009, 9:11 PM "Attila Nagy" <bra at fsn.hu> napsal/a:

 Hello,

W.C.A. Wijngaards wrote: > > On 08/11/2009 11:17 AM, Attila Nagy wrote: > >>
>> Zdenek Vasicek ...
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 s...
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-d...
I hope I described it above to a level, which makes it clear.

Thanks,

_______________________________________________
Unbound-users mailing list
Unbound-users at unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20090811/6f3ac213/attachment.htm>