Need help on delegation to subdomain/external servers

RUOFF LARS Lars.Ruoff at alcatel-lucent.fr
Thu Sep 17 09:16:01 UTC 2009


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



More information about the bind-users mailing list