Re: Need help on delegation to subdomain/external servers
The re-design of the DNS network architecture was one of the few
internal projects where a credible Concept of Operations document
was produced. It had detailed graphics showing the flow of network
traffic between local and regional name servers. There were detailed
discussions and graphics explaining how local name servers would fail
over to another regional name server and which regional name server
would be used under certain failure conditions.
The unfortunate aspect is, simply, that IT colleagues (and
management) believe that the document is right.
On 21 Sep 2009, at 14:31:39, Kevin Darcy wrote:
What is unfortunate about BIND picking a forwarder based on real,
up-to-date information about the thing that the end-user ultimately
cares about -- how quickly the queries get answered?
Surely this is better than hardcoding a bunch of assumptions into
your forwarding configs, assumptions that can be trivially
invalidated by such factors as nameserver failures, nameserver
performance bottlenecks, network congestion, route flapping and
other topographical anomalies, query usage patterns, etc.
If you want more fine-grained control of your query traffic, for
reasons other than pure query performance (e.g. you might pay per-
byte on link A but a flat rate on link B), then you might have to
resort to devices and/or mechanisms outside of named in order to
accomplish it, e.g. traffic shapers, transparent DNS proxies and the
like.
- Kevin
Merton Campbell Crockett wrote:
When I was transferred into our corporate IT Networks group, I
inherited a DNS architecture based on forwarding DNS queries to
regional name servers. The regional name servers had access to the
Internet and were able to provide name and address resolution for
both Intranet and Internet queries.
The designers of the DNS architecture carefully configured the
forwarders statement on each name server so that the name server
for the region was listed first. It was followed by the other
regional name servers ordered by distance from the local name server.
Had this been implemented under BIND 8, it would have worked as the
designers had expected. Unfortunately, it was implemented under
BIND 9.3. The list of name servers in the forwarders statement was
no longer treated as a sequential list as it had been in BIND 8.
Under BIND 9.3 and later releases, the selection of name server
from the forwarders list is performed the same way as the selection
of name server for a DNS zone: its round-robin with a preference
given to the name server with the smallest RTT.
Another item that the designers didn't anticipate was how RTT is
calculated. It is not based on the RTT to the forwarder but on the
time that it takes for the forwarder to return a result. Given the
physical locations of the regional name servers, the calculated RTT
is roughly identical even at sites where there is a local name
server co-located with the regional name server. In our particular
environment, the primary forwarder changes approximately every
20-30 seconds.
Given this behavior, I'm not sure what advantage there is in having
online and offline name servers. I would opt for having all
name servers online and let BIND select the more desirable name
server.
On 17 Sep 2009, at 11:15:59, Ben Croswell wrote:
I have done some testing of the RTT forwarding and found that as
long as only one, or the other of the two nameservers that you
forward to is active at any given time the switch over is actually
very quick.
The exception being the first query when the currently active
forwarder dies and the second comes up. The reason being that the
first query has to wait for a timeout cycle before trying the
second forwarder and readjusting the RTT values for both.
So theoretically if your forwarders are 10.1.1.1 and 10.2.1.1 as
long as only one will answer queries at a given time with their
own right answer it should failover fairly quickly. If both
answer then you will be at the mercy of the RTT as to which answer
you will get.
--
-Ben Croswell
On Thu, Sep 17, 2009 at 12:27 PM, Kevin Darcy k...@chrysler.com mailto:k...@chrysler.com
wrote:
RUOFF LARS wrote:
[mailto:bind-users-boun...@lists.isc.org
mailto:bind-users-boun...@lists.isc.org] On Behalf Of
Kevin Darcy
BTW, at the moment I am experimenting a solution usign a
forward zone:
zone dummy.ts IN {
type forward;
forward only;
forwarders { 172.25.32.171; 192.168.2.3; };
};
It seems to work.
I guess that the requests are not sent simultaneously though?
Correct, it's similar to the algorithm that a stub resolver uses:
try one forwarder, if it times
Re: Need help on delegation to subdomain/external servers
What is unfortunate about BIND picking a forwarder based on real,
up-to-date information about the thing that the end-user ultimately
cares about -- how quickly the queries get answered?
Surely this is better than hardcoding a bunch of assumptions into your
forwarding configs, assumptions that can be trivially invalidated by
such factors as nameserver failures, nameserver performance bottlenecks,
network congestion, route flapping and other topographical anomalies,
query usage patterns, etc.
If you want more fine-grained control of your query traffic, for reasons
other than pure query performance (e.g. you might pay per-byte on link A
but a flat rate on link B), then you might have to resort to devices
and/or mechanisms outside of named in order to accomplish it, e.g.
traffic shapers, transparent DNS proxies and the like.
- Kevin
Merton Campbell Crockett wrote:
When I was transferred into our corporate IT Networks group, I
inherited a DNS architecture based on forwarding DNS queries to
regional name servers. The regional name servers had access to the
Internet and were able to provide name and address resolution for both
Intranet and Internet queries.
The designers of the DNS architecture carefully configured the
forwarders statement on each name server so that the name server for
the region was listed first. It was followed by the other regional
name servers ordered by distance from the local name server.
Had this been implemented under BIND 8, it would have worked as the
designers had expected. Unfortunately, it was implemented under BIND
9.3. The list of name servers in the forwarders statement was no
longer treated as a sequential list as it had been in BIND 8. Under
BIND 9.3 and later releases, the selection of name server from the
forwarders list is performed the same way as the selection of name
server for a DNS zone: its round-robin with a preference given to the
name server with the smallest RTT.
Another item that the designers didn't anticipate was how RTT is
calculated. It is not based on the RTT to the forwarder but on the
time that it takes for the forwarder to return a result. Given the
physical locations of the regional name servers, the calculated RTT is
roughly identical even at sites where there is a local name server
co-located with the regional name server. In our particular
environment, the primary forwarder changes approximately every 20-30
seconds.
Given this behavior, I'm not sure what advantage there is in having
online and offline name servers. I would opt for having all name
servers online and let BIND select the more desirable name server.
On 17 Sep 2009, at 11:15:59, Ben Croswell wrote:
I have done some testing of the RTT forwarding and found that as long
as only one, or the other of the two nameservers that you forward
to is active at any given time the switch over is actually very quick.
The exception being the first query when the currently active
forwarder dies and the second comes up. The reason being that the
first query has to wait for a timeout cycle before trying the second
forwarder and readjusting the RTT values for both.
So theoretically if your forwarders are 10.1.1.1 and 10.2.1.1 as long
as only one will answer queries at a given time with their own
right answer it should failover fairly quickly. If both answer
then you will be at the mercy of the RTT as to which answer you will get.
--
-Ben Croswell
On Thu, Sep 17, 2009 at 12:27 PM, Kevin Darcy k...@chrysler.com
mailto:k...@chrysler.com wrote:
RUOFF LARS wrote:
[mailto:bind-users-boun...@lists.isc.org
mailto:bind-users-boun...@lists.isc.org] On Behalf Of
Kevin Darcy
BTW, at the moment I am experimenting a solution usign a
forward zone:
zone dummy.ts IN {
type forward;
forward only;
forwarders { 172.25.32.171; 192.168.2.3; };
};
It seems to work.
I guess that the requests are not sent simultaneously though?
Correct, it's similar to the algorithm that a stub resolver uses:
try one forwarder, if it times out, try another, and so on.
In fact, the way I like to think of forwarding is: when you
forward, you're turning named *into* a stub resolver with a
cache, at least for part of the namespace. If you forward
globally (i.e. in options), and have some authoritative zones
and/or stub zones with forwarders { } defined, then those are
just selective overrides of your stub-resolver+cache function.
And if you have forward first anywhere, then you're just giving
named a second chance to resolve names iteratively, in case the
initial stub-resolver+cache approach fails (because the
Re: Need help on delegation to subdomain/external servers
When I was transferred into our corporate IT Networks group, I
inherited a DNS architecture based on forwarding DNS queries to
regional name servers. The regional name servers had access to the
Internet and were able to provide name and address resolution for both
Intranet and Internet queries.
The designers of the DNS architecture carefully configured the
forwarders statement on each name server so that the name server for
the region was listed first. It was followed by the other regional
name servers ordered by distance from the local name server.
Had this been implemented under BIND 8, it would have worked as the
designers had expected. Unfortunately, it was implemented under BIND
9.3. The list of name servers in the forwarders statement was no
longer treated as a sequential list as it had been in BIND 8. Under
BIND 9.3 and later releases, the selection of name server from the
forwarders list is performed the same way as the selection of name
server for a DNS zone: its round-robin with a preference given to the
name server with the smallest RTT.
Another item that the designers didn't anticipate was how RTT is
calculated. It is not based on the RTT to the forwarder but on the
time that it takes for the forwarder to return a result. Given the
physical locations of the regional name servers, the calculated RTT is
roughly identical even at sites where there is a local name server co-
located with the regional name server. In our particular environment,
the primary forwarder changes approximately every 20-30 seconds.
Given this behavior, I'm not sure what advantage there is in having
online and offline name servers. I would opt for having all name
servers online and let BIND select the more desirable name server.
On 17 Sep 2009, at 11:15:59, Ben Croswell wrote:
I have done some testing of the RTT forwarding and found that as
long as only one, or the other of the two nameservers that you
forward to is active at any given time the switch over is actually
very quick.
The exception being the first query when the currently active
forwarder dies and the second comes up. The reason being that the
first query has to wait for a timeout cycle before trying the second
forwarder and readjusting the RTT values for both.
So theoretically if your forwarders are 10.1.1.1 and 10.2.1.1 as
long as only one will answer queries at a given time with their own
right answer it should failover fairly quickly. If both answer
then you will be at the mercy of the RTT as to which answer you will
get.
--
-Ben Croswell
On Thu, Sep 17, 2009 at 12:27 PM, Kevin Darcy k...@chrysler.com
wrote:
RUOFF LARS wrote:
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
BTW, at the moment I am experimenting a solution usign a forward zone:
zone dummy.ts IN {
type forward;
forward only;
forwarders { 172.25.32.171; 192.168.2.3; };
};
It seems to work.
I guess that the requests are not sent simultaneously though?
Correct, it's similar to the algorithm that a stub resolver uses:
try one forwarder, if it times out, try another, and so on.
In fact, the way I like to think of forwarding is: when you forward,
you're turning named *into* a stub resolver with a cache, at least
for part of the namespace. If you forward globally (i.e. in
options), and have some authoritative zones and/or stub zones with
forwarders { } defined, then those are just selective overrides
of your stub-resolver+cache function. And if you have forward
first anywhere, then you're just giving named a second chance to
resolve names iteratively, in case the initial stub-resolver+cache
approach fails (because the forwarders aren't available/reachable).
Seems like extreme overkill to use a big heavyweight process like
named, to perform a simple stub-resolver function that can otherwise
be accomplished with a few library routines, doesn't it? Well it
*should* seem like overkill, because it's usually the wrong tool for
the job. Forwarding is generally to be avoided, unless you need to
deal with a limited-connectivity situation (e.g. trying to resolve
Internet names to internal clients through a firewalled environment)
or, in certain select cases, to forward to a richly-populated
central cache, with ample capacity, over fast internal links, in
order to speed up the average name resolution time for a local set
of clients.
What delay do I have to expect when only the second server
(192.168.2.3)
is active?
I'm not sure, I'd have to look through the code. I don't believe
this delay is configurable, by the way.
What search policy is applied by default? (round-robin vs sequential?)
Can I modify it?
Obviously I would prefer a policy where we always forward to the last
active, unless we time out; Then try the alternate.
Will check that out.
I believe that forwarder-selection uses the same algorithm as NS-
RE: Need help on delegation to subdomain/external servers
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 ) zone lab.ts/IN: x.lab.ts/NS 'vega-b.x.lab.ts' (out of zone) has no addresses records (A or ) 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
Re: Need help on delegation to subdomain/external servers
On 17.09.09 11:16, RUOFF LARS wrote: 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). not possible with BIND. And, I hope, you won't use this in public (outside of your network). I better wouldn't code such beast since people WOULD use that in public... 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. There are packages that do that, using DNS for that is not good idea. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help on delegation to subdomain/external servers
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 ) zone lab.ts/IN: x.lab.ts/NS 'vega-b.x.lab.ts' (out of zone) has no addresses records (A or ) 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
RE: Need help on delegation to subdomain/external servers
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
[...]
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.
I guess you are right, but that's how the system works. (it's not me who
designed it)
It's the only viable way to find out which one is active at a given
time.
[...]
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.
It stays on a private network. :)
BTW, at the moment I am experimenting a solution usign a forward zone:
zone dummy.ts IN {
type forward;
forward only;
forwarders { 172.25.32.171; 192.168.2.3; };
};
It seems to work.
I guess that the requests are not sent simultaneously though?
What delay do I have to expect when only the second server (192.168.2.3)
is active?
What search policy is applied by default? (round-robin vs sequential?)
Can I modify it?
Obviously I would prefer a policy where we always forward to the last
active, unless we time out; Then try the alternate.
Will check that out.
Lars
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help on delegation to subdomain/external servers
RUOFF LARS wrote:
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
BTW, at the moment I am experimenting a solution usign a forward zone:
zone dummy.ts IN {
type forward;
forward only;
forwarders { 172.25.32.171; 192.168.2.3; };
};
It seems to work.
I guess that the requests are not sent simultaneously though?
Correct, it's similar to the algorithm that a stub resolver uses: try
one forwarder, if it times out, try another, and so on.
In fact, the way I like to think of forwarding is: when you forward,
you're turning named *into* a stub resolver with a cache, at least for
part of the namespace. If you forward globally (i.e. in options),
and have some authoritative zones and/or stub zones with forwarders {
} defined, then those are just selective overrides of your
stub-resolver+cache function. And if you have forward first anywhere,
then you're just giving named a second chance to resolve names
iteratively, in case the initial stub-resolver+cache approach fails
(because the forwarders aren't available/reachable).
Seems like extreme overkill to use a big heavyweight process like named,
to perform a simple stub-resolver function that can otherwise be
accomplished with a few library routines, doesn't it? Well it *should*
seem like overkill, because it's usually the wrong tool for the job.
Forwarding is generally to be avoided, unless you need to deal with a
limited-connectivity situation (e.g. trying to resolve Internet names to
internal clients through a firewalled environment) or, in certain select
cases, to forward to a richly-populated central cache, with ample
capacity, over fast internal links, in order to speed up the average
name resolution time for a local set of clients.
What delay do I have to expect when only the second server (192.168.2.3)
is active?
I'm not sure, I'd have to look through the code. I don't believe this
delay is configurable, by the way.
What search policy is applied by default? (round-robin vs sequential?)
Can I modify it?
Obviously I would prefer a policy where we always forward to the last
active, unless we time out; Then try the alternate.
Will check that out.
I believe that forwarder-selection uses the same algorithm as
NS-selection, i.e. it's based on the historical RTT data. So it might
not switch over as fast as you'd like.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help on delegation to subdomain/external servers
I have done some testing of the RTT forwarding and found that as long as
only one, or the other of the two nameservers that you forward to is
active at any given time the switch over is actually very quick.
The exception being the first query when the currently active forwarder dies
and the second comes up. The reason being that the first query has to wait
for a timeout cycle before trying the second forwarder and readjusting the
RTT values for both.
So theoretically if your forwarders are 10.1.1.1 and 10.2.1.1 as long as
only one will answer queries at a given time with their own right answer
it should failover fairly quickly. If both answer then you will be at the
mercy of the RTT as to which answer you will get.
--
-Ben Croswell
On Thu, Sep 17, 2009 at 12:27 PM, Kevin Darcy k...@chrysler.com wrote:
RUOFF LARS wrote:
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
BTW, at the moment I am experimenting a solution usign a forward zone:
zone dummy.ts IN {
type forward;
forward only;
forwarders { 172.25.32.171; 192.168.2.3; };
};
It seems to work.
I guess that the requests are not sent simultaneously though?
Correct, it's similar to the algorithm that a stub resolver uses: try one
forwarder, if it times out, try another, and so on.
In fact, the way I like to think of forwarding is: when you forward, you're
turning named *into* a stub resolver with a cache, at least for part of the
namespace. If you forward globally (i.e. in options), and have some
authoritative zones and/or stub zones with forwarders { } defined, then
those are just selective overrides of your stub-resolver+cache function.
And if you have forward first anywhere, then you're just giving named a
second chance to resolve names iteratively, in case the initial
stub-resolver+cache approach fails (because the forwarders aren't
available/reachable).
Seems like extreme overkill to use a big heavyweight process like named, to
perform a simple stub-resolver function that can otherwise be accomplished
with a few library routines, doesn't it? Well it *should* seem like
overkill, because it's usually the wrong tool for the job. Forwarding is
generally to be avoided, unless you need to deal with a limited-connectivity
situation (e.g. trying to resolve Internet names to internal clients through
a firewalled environment) or, in certain select cases, to forward to a
richly-populated central cache, with ample capacity, over fast internal
links, in order to speed up the average name resolution time for a local set
of clients.
What delay do I have to expect when only the second server (192.168.2.3)
is active?
I'm not sure, I'd have to look through the code. I don't believe this delay
is configurable, by the way.
What search policy is applied by default? (round-robin vs sequential?)
Can I modify it?
Obviously I would prefer a policy where we always forward to the last
active, unless we time out; Then try the alternate.
Will check that out.
I believe that forwarder-selection uses the same algorithm as NS-selection,
i.e. it's based on the historical RTT data. So it might not switch over as
fast as you'd like.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help on delegation to subdomain/external servers
On Wed, Sep 16, 2009 at 05:20:21PM +0200, 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?
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 ) zone lab.ts/IN: x.lab.ts/NS
'vega-b.x.lab.ts' (out of zone) has no addresses records (A or )
zone lab.ts/IN: loaded serial 2 OK
How can i do it?
Thanks,
Lars
You can use `forward` zone. Check
https://www.isc.org/software/bind/documentation/arm95#zone_statement_grammar:
zone example.com IN {
type forward;
forward only;
forwarders { IPaddr; };
};
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help on delegation to subdomain/external servers
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 ) zone lab.ts/IN: x.lab.ts/NS 'vega-b.x.lab.ts' (out of zone) has no addresses records (A or ) 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
