[Unbound-users] unbound views

[W.C.A. Wijngaards]

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
>