<p>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.</p>

<p>Ondrej</p>
<p><blockquote type="cite">Dne 118  2009, 9:11 PM "Attila Nagy" <<a href="mailto:bra@fsn.hu">bra@fsn.hu</a>> napsal/a:<br><br>



<div bgcolor="#ffffff" text="#000000">
Hello,<p><font color="#500050">

W.C.A. Wijngaards wrote:
>
> On 08/11/2009 11:17 AM, Attila Nagy wrote:
>   
>>
>> Zdenek Vasicek ...</font></p>
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.<br>
At least, when I issue two queries from two, different machines I get
different answers, as it should be.<p><font color="#500050">

>> This is pretty much fine if you want to respond according to complex
>> rules (which involves s...</font></p>
Not always. :)<br>
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.<br>
<br>
BTW, what I need this for is the following:<br>
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).<br>
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:<br>
<a href="http://1.1.1.0/24" target="_blank">1.1.1.0/24</a> should resolve <a href="http://abcd.name" target="_blank">abcd.name</a> to 192.168.0.1<br>
<a href="http://1.1.2.0/24" target="_blank">1.1.2.0/24</a> should resolve <a href="http://abcd.name" target="_blank">abcd.name</a> to 192.168.1.1<br>
... and so on.<br>
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. :)<br>
<br>
So this is not quite internal/external (and not just two of them).<br>
<br>
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. :)<p><font color="#500050">

>
> I would guess this is about authority information?
> Maybe, simply block access to the local-d...</font></p>
I hope I described it above to a level, which makes it clear.<br>
<br>
Thanks,
</div>

<br>_______________________________________________<br>
Unbound-users mailing list<br>
<a href="mailto:Unbound-users@unbound.net">Unbound-users@unbound.net</a><br>
<a href="http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users" target="_blank">http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users</a><br></blockquote></p>