Need help on delegation to subdomain/external servers

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

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.

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.

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

- Kevin