Hello, Thanks for your detailed answer. I think I don't have enough DNS knowledge to understand every bit of it, but I'll try to clarify. [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy: > > RUOFF LARS wrote: > > Hi, > > > > i'm using BIND9 on an Ubuntu-8.10-server. > > I'd like to configure the following: > > For a given name (eg. vega.lab.ts), I'd like to forward the > request to > > two external DNS servers, *simultaneously*, and respond > with the first > > response that i get. > > > > Is this possible? > > > Short answer: not possible with BIND currently, that I know of. > > Longer answer: why would you even want to do this? Sounds > like you're barking up the wrong tree. Latency of DNS > response may have little or nothing to do with the latency of > whatever real-time connection (HTTP, LDAP, VoIP, video, > audio, whatever) is being established using that DNS > information. Trying to equate DNS response latency to > anything else that a user would care about, is an exercise in > futility, IMO. > The reason for this is: I have a hot-swap redundant system where 1 out of 2 servers is active at any given time and the other is standby. DNS is (mis?-)used to tell the clients which one is active at a given moment. The idea is that clients resolve a name of the server and the result is the address of the server that is currently active. (Only the current active server responds to DNS queries for its own name).
> Furthermore, have you considered caching? Once the answer is > cached, then a BIND nameserver won't try to fetch the > information from other servers *at*all*, until that cache > entry expires. The server uses TTL=0 in order to inhibit any caching on clients. > > If your goal is to optimize application performance by always > directing users to a "best" node, among a set or cluster of > nodes, then put a load-balancer in front of this resource: on > the back-end, it can measure latency or any other metric(s), > which is most representative of the "user experience" for > this resource (depending on the probing/measurement > capabilities of the load-balancer device/package/subsystem). > On the front-end, the load-balancer responds with whatever IP > represents the "best" choice for that resource, at any > particular point in time. As with any DNS-based > load-balancing scheme, you might have to lower the TTLs of > the relevant records to > ridiculously- (possibly anti-socially-)low values in order to > provide sufficiently-dynamic load balancing. > > > I didn't see how to do it directly, so i tried using a > subdomain, (eg. > > x.vega.lab.ts) and specifiying the two DNS for this subdomain: > > > > Extract from the lab.ts zone file: > > [...] > > x.lab.ts. IN NS vega-a.x.lab.ts. > > x.lab.ts. IN NS vega-b.x.lab.ts. > > vega-a.x.lab.ts. IN A 172.25.32.252 > > vega-b.x.lab.ts. IN A 192.168.2.3 > > [...] > > > > But this doesnt seem to work: > > named-checkzone lab.ts /etc/bind/db.lab.ts says: > > zone lab.ts/IN: x.lab.ts/NS 'vega-a.x.lab.ts' (out of zone) has no > > addresses records (A or AAAA) zone lab.ts/IN: x.lab.ts/NS > > 'vega-b.x.lab.ts' (out of zone) has no addresses records (A > or AAAA) > > zone lab.ts/IN: loaded serial 2 OK > > > I just ran a quick test, and it appears that named-checkzone > actually goes out and tries to resolve glue records it > encounters. Since you haven't delegated the zone yet, it's > not surprising that the glue records don't resolve from the > authoritative nameservers for the zone. > In this respect, I think named-checkzone is being more > rigorous than named itself would be, as it loads the zone. If > these "no addresses records [sic]" errors are the *only* ones > being reported for the zone, then I'd try to load it and see > if those errors magically evaporate once you do that. > Well, I tried this, but it doesn't seem to work. I got no answer for vega.x.lab.ts, although the end serve was configured properly. > I don't think delegation is the solution to your > load-balancing requirement, however. NS'es are tried, > sequentially, according to historical RTT statistics; > _over_time_, faster-responding servers will tend to get tried > before slow-responding ones, but this adaptivity may take > time to kick in when the responsiveness of the target > nameservers changes, so it would probably not be dynamic > enough to meet your requirements, even _if_ the latency of > DNS responses were reflective of the performance of the > underlying app (which I question above). As said, my issue is not really load balancing, but active-standby switching, where only one server will ever respond at any given time. Regards, Lars _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
