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 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 <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
Merton Campbell Crockett
m.c.crock...@roadrunner.com <mailto:m.c.crock...@roadrunner.com>
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Merton Campbell Crockett
m.c.crock...@roadrunner.com
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
