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" <[email protected] <mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
