Need help on delegation to subdomain/external servers
Lars.Ruoff at alcatel-lucent.fr
Thu Sep 17 09:16:01 UTC 2009
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-bounces at 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
> 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.
More information about the bind-users