RUOFF LARS wrote:
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).
DNS isn't really suited to this. If you control a node that the network
paths to both servers share in common, then you could put a (simple)
load-balancer or "traffic cop" of some sort at that node which
dynamically directs the traffic to the currently active server. Of
course, having a node in common like that represents a Single Point of
Failure, so either you have more diversity or you accept that the Single
Point of Failure exists and incorporate that into your availability
expectations.
If the servers are completely diverse, then you might need a commercial
load-balancing solution, "anycast", some sort of redirect scheme, etc.
You might want to check out the companion web pages
http://www.tenereillo.com/GSLBPageOfShame.htm and
http://www.tenereillo.com/GSLBPageOfShameII.htm>.
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.
I hope this stays on a private network then, because TTL=0 is considered
quite anti-social on the Internet. It makes everyone who queries your
nameservers work significantly harder than they should.
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.
Do I understand correctly? The zone loaded successfully, including the
delegation of x.lab.ts from lab.ts, and at least one of the delegated
nameservers can resolve its own name, but named-checkzone is *still*
complaining about not being able to resolve the glue records into
addresses?
What happens if you just look up that name from the command line on the
same box? How about a dig +trace?
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
