Hello, Yes, this solves my problem (it's not as fast as views would be, but more flexible (I don't need that flexibility this time, BTW :)). My only question, whether that change can go into the upstream version. It won't be good to always patch unbound... Thanks, W.C.A. Wijngaards wrote: > Hi Attila, > > Yeah with the patch from Zdenek, then in the python > module use TTL 0, and you can return a source specific IP address. > > This is not optimal performance for that source-IP name, > but it is easy to operate... Perhaps this solves it? > > Best regards, > Wouter > > On 08/11/2009 09:45 PM, Attila Nagy wrote: >> Why? (the brick into the hole) >> I've already written a custom DNS server (but didn't know about evldns, >> thanks), but the task here is to give different results depending on the >> *client's ip* on a *recursive nameserver*, which they use otherwise. >> >> I wouldn't reimplement unbound (a recursive nameserver) just to give >> back different IP for a single name from different source networks. And >> of course (if you have read what I wrote, it must be clear) I can't >> implement this feature in an authoritative NS, because there I've >> already lost the client's real IP. >> >> Ondřej Surý wrote: >>> >>> 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 <mailto: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 <http://1.1.1.0/24> should resolve abcd.name >>>> <http://abcd.name> to 192.168.0.1 >>>> 1.1.2.0/24 <http://1.1.2.0/24> should resolve abcd.name >>>> <http://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 <mailto:Unbound-users at unbound.net> >>>> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users >> >