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