[Unbound-users] unbound views

[Attila Nagy]

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
>>
>