[Unbound-users] unbound views

[Attila Nagy]

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