Subject: [dnsop] DNS Anycast revisited

From: jing shen <[email-masked]>
Date: Fri, 25 Mar 2005 11:41:50 +0800

Hi £¬

I'm trying to set up a anycast DNS server farm for customer service.
In order to improve availability, we plan to install those servers in
one LAN which has the similar structure like :

server-(1,3)---switch1---router-1---(outside)
                 |
                 |
server-(2,4)---switch2---router-2---(outside)

The four unix servers are all unix boxes, switch-1 & switch-2 are
interconnected to guarantee the availability. BIND is to be used as
DNS cache server software, Quagga OSPFD is used to be routing
software.

According to above configuration, both routers will know multiple
paths to dns cache server, while dns cache server should know two
paths to outside network. Here comes my questions:

1) should each dns cache server be configured a static default route
(0.0.0.0/0.0.0.0)? If server-(1,3) is configured statically to use
router-1 as default router, will Quagga make it use router-2 when
router-1 is not reachable?

2) If each server is configured two default router ( router-1 &
router-2), or each server learn route 0.0.0.0/0.0.0.0 by OSPF ( our
border router inject default route into OSPF ); there should be
two equal cost path to 0.0.0.0/0.0.0.0 on each DNS server, the DNS
server should disperse any outgoing packets onto the two paths, will
that do harm to  DNS service ?

3) Is there any requirement on BIND to fit to such multipath routing
situation?

-- 
 -- -- 
Regards

Jing Shen

******************************************
* The sunshine of lifetime is made up of *
* little beams which is bright all the   *
* time.                                  *
******************************************

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Dean Anderson <[email-masked]>
Date: Fri, 25 Mar 2005 12:43:02 -0500 (EST)

Anycast DNS is inadvisable.  DNS is specified to work on TCP, and Anycast
is unsuitable for TCP.

Those few who have been promoting the idea of anycast DNS were found to be
wrong in their assumptions.  See previous discussion on the subject in the
archives.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

.

---

From: [email-masked]
Date: Sun, 27 Mar 2005 11:23:41 +0200

> Anycast DNS is inadvisable.  DNS is specified to work on TCP, and Anycast

Your biases against anycast DNS are well known, and don't really add
anything to the discussion at this point.

> wrong in their assumptions.  See previous discussion on the subject in the

Yes, please do see previous discussions. Many of us operate anycast
DNS without problems, and we are aware of the possible problems with
per-packet load-balancing.

Steinar Haug, Nethelp consulting, [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Mar 2005 09:36:07 +0900

[email-masked] wrote:

> Many of us operate anycast

I think you are aware of a possible problem of PPLB using pathes
with different loss/delay properties badly interact with TCP.

						Masataka Ohta

.

---

From: "Elmar K. Bins" <[email-masked]>
Date: Mon, 28 Mar 2005 11:46:09 +0200

> per-packet load-balancing.

It's also important to differentiate between anycast issues (BGP-based
load balancing, if you like) and site balancing issues (which need to
be done in a connection-consistent way).

Many people mix this (I did, too, in my first design papers).

Elmar.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren."
                          (PLemken, <[email-masked]>)

--------------------------------------------------------------[ ELMI-RIPE ]---

.

---

From: Dean Anderson <[email-masked]>
Date: Sun, 27 Mar 2005 16:49:14 -0500 (EST)

> anything to the discussion at this point.

Biases?  Testing of PPLB and facts are not mere "biases".  Seems you just
want to ignore certain facts.

> per-packet load-balancing.

Yet you don't want to notify others of those problems. Indeed, you object
to them being so notified.  Strange, I think.

Many people run UDP only DNS.  UDP only is fine with anycast.  I suppose
that's OK. But this group is supposed to move people forward. Forward
means that people need to be able to use DNS over TCP, and so they should
know when they are shooting themselves in the foot so far as the future is
concerned.

Joe Shen has no compelling need of anycast DNS.  It is a bad operational
decision to deploy it. And he should get good advice from the DNSOP
working group.

.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 29 Mar 2005 03:55:14 +1000 (EST)

> server-(2,4)---switch2---router-2---(outside)

I'm assuming that the above servers 1-4 each have two (possibly virtual)
interfaces, one being the server's unique, administrative address, and one
being the anycast, public address, and that the 'outside' in both cases is
the same.

> router-1 is not reachable?

The simple answer is 'rely on Quagga to set the default routes, but use
statics to your master machine, so you can get to your servers if/when
Quagga dies.'

> that do harm to  DNS service ?

Unless you explicitly enable per-packet load balancing on your servers,
the TCP/IP stack on your servers will round-robin streams between the two
equal-cost default routes, not round-robin packets.  There will not be any
DNS issues on that level.

Enabling per-packet load balancing on your servers is not a useful
optimisation; there is little benefit to be gained, and it is far better
to do such on a device with full routing tables.

> 3) Is there any requirement on BIND to fit to such multipath routing

Since you are referring to cache servers, there is only the minor issue of
telling BIND to explicitly listen on the anycasted public server address.

If you were serving authoritative zones, there are other issues to do with
keeping each server in sync (pull zones via administrative addresses, not
the anycasted address).

--==--
Bruce.
.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 29 Mar 2005 04:15:49 +1000 (EST)

> telling BIND to explicitly listen on the anycasted public server address.

Something else that to me is obvious, but is not necessarily so to others,
is that you will also need to configure BIND to make outgoing queries from
its unique administrative address, not the shared anycast address.

Otherwise, answers to your server's queries may be sent to other servers,
leaving to your customer resolvers requerying.

--==--
Bruce.
.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 29 Mar 2005 10:56:57 +0200

<...> Forward means that people need to be able to use DNS over TCP

The way forward to what?

	jaap
.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 29 Mar 2005 14:17:07 +0200 (CEST)

>     <...> Forward means that people need to be able to use DNS over TCP

``Forward to a point in time where typical DNS utilises TCP more than it
  does now, as is likely with DNSSEC (due to the increased packet size).''

However, Dean... ``Put up, or shut up'' [1].

Phrased more elequontly, I think both sides would find it beneficial if
you would put all of the PPLB-specific issues into an Internet Draft, and
submitted it via the normal processes.  That gives both sides something to
reference rather than just ``check the archives'', and it will be far, far
better than this issue continually coming up on this list with no clear
conclusion being accepted by either side.

Heres a few starting points for your draft Dean, being my possibly
biased[2] summary of the periodic PPLB rehash:

	In '6 months', DNSSEC will be introduced.  Likely, this will
	increase the number of TCP DNS queries from SMALL% to
	SLIGHTLY-LESS-SMALL% .  UDP queries will, quite likely, remain
	at HIGH% of total queries.

	As Per-Packet Load Balancing is known to break TCP streams under
	certain conditions, this draft outlines the conditions and
	recommendations for end-sites and zone administrators where
	BGP-anycasted nameservers are in use.

	Outline of PPLB and TCP problems... blah blah blah.

	Outline of PPLB and specific DNS TCP problems... blah blah blah.

	Recommendations for End-Sites:

		PPLB over multiple links to the same upstream AS are not
		seen to be a problem, except when used with time-critical
		application (such as VoIP), which have issues with packets
		arriving out of order.

		PPLB over multiple links to differing upstream ASes can be
		a problem if the remote end of the TCP connection has been
		BGP-anycasted.  Where possible, end-sites should not use
		PPLB for protocols which are likely to be BGP-anycasted,
		such as DNS.

	Recommendations for zone administrators:

		If your listed, authoritative servers are utilising
		BGP-anycast, try to have at least one listed server for
		the zone which is unicast.  This will continue to provide
		service to PPLB-using end-sites which have not turned off
		PPLB for specific protocols such as DNS.

		Remember that excessively long records will, quite likely,
		cause clients to flip from UDP to DNS.  Try to avoid this
		on very popular zones by taking advantage of name
		compression or other tricks.

--==--
Bruce.

[1] Bound to get me in Dean's list of people to complain about. ;)
[2] Yes, I have been involved with a root server being anycasted.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Elmar K. Bins" <[email-masked]>
Date: Tue, 29 Mar 2005 16:29:51 +0200

Bruce :)

> 	Recommendations for End-Sites:
...
> 		PPLB for protocols which are likely to be BGP-anycasted,

Shouldn't one avoid this for all protocols? It adds quite some uncertainty
to the end site's routing, and most network operators will abstain anyway.
Think of debugging _any_ connectivity issue...

> 		PPLB for specific protocols such as DNS.

I believe, almost nobody's crazy enough to go solely for anycast; alright,
alright, we all know the "bad guys", but apart from them, I've seen no-one
doing it.

There's still the issue of traffic "balancing" - consider a DNS setup with
one anycast NS and four unicast NS. Overall, _all anycast instances
together_ will receive about 1/5 to 1/4 (if lucky) of the entire query
traffic. That's quite a problem, and I'm not yet sure how to solve it
correctly.

But, using only anycast NS surely solves this economic problem.

> 		cause clients to flip from UDP to DNS.  Try to avoid this
                                                  ^^^
						  TCP

Elmar.

--

.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 29 Mar 2005 10:14:27 -0500 (EST)

>   does now, as is likely with DNSSEC (due to the increased packet size).''

Yes. that.

> However, Dean... ``Put up, or shut up'' [1].

Fair enough.  I'll start work on it.

.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 29 Mar 2005 10:08:12 -0500 (EST)

>     <...> Forward means that people need to be able to use DNS over TCP

You mean the road to hell? ;-)  The ability to support DNS over TCP for
large packets...

Though, perhaps, if DNSSEC doesn't require TCP, perhaps we don't really
need TCP...  But as long as we are operating on the assumption that TCP is
a needed future facility, we should be working to make sure it can be
deployed by not choosing architectures that prevent its deployment. Or at
the very least, making very well informed decisions about what it is we
are sacrificing by those decisions.

		--Dean

.

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Mar 2005 09:35:29 -0800

Dean,

>> Anycast DNS is inadvisable.  DNS is specified to work on TCP, and

Can you provide your empirical data that demonstrates using shared
unicast is unsuitable for DNS over TCP?

> decision to deploy it.

Since you indicate you know Joe Shen's needs, can you describe why he
has no compelling need for anycast DNS or why it would be a bad
decision to deploy it?

In my experience, shared unicast DNS provides quite a few benefits,
particularly in the context of ISPs or services that need to be highly
available, at the cost of some additional routing configuration
complexity.  There are, of course, situations in which the costs of
shared unicast DNS outweigh the benefits, but I've found those
situations to be rare in larger networks.

Rgds,
-drc
.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 28 Mar 2005 15:50:12 -0500 (EST)

> unicast is unsuitable for DNS over TCP?

The anycast RFC notes that TCP protocols aren't suitable for anycast.
ISC started promoting the idea that TCP could also be anycast.

PPLB on BGP was tested by [email-masked]. He reports it works: Packets
are sent over each link on a per-packet basis.  I have to find who
confirmed it worked on OSPF links.  (that might actually be cisco)

Once you know that (TCP) packets will take different paths on a per-packet
basis, then its a simple matter to show that different anycast
versions of the same root server may be reached by different paths. I have
a drawing that I used to discuss the issue with Iljitsch van Beijnum and
others on the dnsop and ietf list. (forwarded to dnsop just now)

> has no compelling need for anycast DNS or why it would be a bad

He can add more nameservers to his list of authoritative servers.

Root servers, by contrast, could no longer add authoritative servers since
13 is the maximum.  Another method was needed to continue to expand the
number of root servers. (I think there were other alternatives for root
servers, however, the root operators had some justification, whereas Shen
has none.)

> complexity.

Anicast servers offer no benefits for high availability which aren't
offered by simple failover. Remember that anycast has two different paths
to the same IP address, frequently in different physical locations,
whereas simple failover has a single path to a same ethernet where there
are two servers which can take over the same IP address.  If an anycast
server fails, it won't respond for that packets using that path, forcing a
lookup against a different server.

Certainly some improved availability can be obtained with ordinary
failover methods where there are not multiple paths.  I don't object to
that. But that isn't anycast.  Simple failover is when two servers share a
same lan, and one server can take over the IP address of another if it
fails. Simple failover is distinguished from anycast.  Of course, if the
path fails, then both servers are unavailble.

Given the Joe's situation, he should use either simple failover (and
single path), or he should add additional authoritative servers (he has
only two) with different IP addresses and possibly different paths.

> There are, of course, situations in which the costs of

.

---

From: Paul Vixie <[email-masked]>
Date: 29 Mar 2005 22:46:27 +0000

[email-masked] (David Conrad) writes:

> shared unicast DNS outweigh the benefits, but I've found those situations
> to be rare in larger networks.

i figure this is as good a time to mention this as any.  david conrad was
the first voice for wide scale ipv4 anycast of root name servers, and when
f-root started deploying this (in the months before the october 2002 ddos)
it was because david and i had been sharing an office and talking about it.
("and it makes for great security/resiliency slideware.")

for the record, i remain convinced that unowned anycast (where the prefix
being advertised isn't solely controlled by a single entity worldwide) is
dangerous and should not be done except in cases like AS112 (www.as112.net).
("but it makes for great socialist-internet slideware.")

while i'm on the subject, i also remain convinced that using anycast to do
distributed load balancing for applications like WWW, on the assumption
that the path you heard a dns query on is instructive as to what content
would be best to answer with, is silly, and will more often do harm or do
nothing than do good.  (and i've told akamai and speedera this many times.)
("but it makes for great marketing slideware.")

lest anyone be confused, ultradns's anycast for .ORG is completely coherent
and doesn't admit the possibility of giving out different responses from
different anycast nodes for policy reasons or any other reason, and so it's
an example of "good" anycast the way i count such things.

finally, a word about tcp.  even the most pessimistic route-change
measurements (from verisign and IIJ) wouldn't affect tcp performance for
transactions as short-lived as occur with dns queries.  but that's not a
justification for switching to tcp.  if we believe that EDNS0's buffer
size management isn't good enough, then we can bring back the MD bit from
an old EDNS1 proposal.  but we won't be holding full tcp session state in
dns servers.  nope nope nope.
-- 
Paul Vixie
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: jing shen <[email-masked]>
Date: Wed, 30 Mar 2005 19:10:54 +0800

Hi Dean£¬

Maybe I did not explain my situation clearly in previous message.

In fact, what I'm facing is to set up a public DNS service system
which consist Cache Server ONLY. We do have authoritative servers, but
those server only serves  a few domain name.

Each of the four DNS cache servers we are using has unique IP address,
which is known to our customers ( some of them designate dns server,
some of them use DNS server distributed by BRAS). The reason which
makes me thought anycast may do some help is :

1) it could be used to set up a distributed server system which may
improve availability;

2) it could be used to balance load on servers in one site while we do
not need pay for dedicated load balancer(which may be another point of
 failure);

3) It could do some help to improve security level because we
could hide the whole system from DDoS attacker.

4) It could maintein an unique user interface, customers could
keep the original resolver settings while enjoying better service;(
they do not need to re-config their computer)

5) It may ease system administration because we could
offline any server for maintenance at any time.

I'm not sure whether analysis above is correct, and , as you pointed
out, anycast do have some problem with TCP based service. Althought we
only need to provide cacheing service, we have to open TCP/53 for
incoming requests because we are not sure whether our customer's
computer use UDP for domain resolution ONLY. And, ECMP in our network
is a common situation ( nearly any of two node has two or more equal
cost routing paths); so, I'm not sure whether this will do harm to
service validity & availibilty. So, I push the question to dnsop.

-- 
 -- -- 
Regards

Joe Shen

.

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 30 Mar 2005 14:02:30 +0200 (CEST)

> those server only serves  a few domain name.

Hence, adding additional authoritative servers does not help, nor does
adding extra servers to your customer's resolv.confs or equivilant.

> makes me thought anycast may do some help is :

In your situation, you want to shy away from using the unqualified term
'anycast' on this list.  As is somewhat obvious, certain people on this
list have kneejerk reactions to the term.  Using 'load balancing', 'load
distribution' and 'server redundancy' is better.

Ideally, your customers are all configured with the same IP address as
their first resolver.  This IP address is announced by multiple machines
in your local infrastructure to your routers via your preferred IGP (I
like OSPF myself).

Assuming that you have a good IGP mesh between all of your routers, then
when one machine goes down and withdraws the route for the specific IP
address to its local router, that router will forward requests for that IP
address to another router which has a connected machine.

> 1) it could be used to set up a distributed server system which may

Yes.

> not need pay for dedicated load balancer(which may be another point of

You'll be using your routers as load balancers.  If you run into issues,
look into memory usage on the routers first.

> could hide the whole system from DDoS attacker.

Security through obscurity may make you sleep better at night, but do not
rely upon this.

> they do not need to re-config their computer)

This is a big plus, although I think you mean 'consistent user interface'.
Maintaining seperate settings per customer is a support nightmare.

> offline any server for maintenance at any time.

This is also a big plus.

> computer use UDP for domain resolution ONLY.

Most routers, when used as load balancers in this situation, will perform
per-flow load balancing, not per-packet ( At least this is the case with
cisco and juniper).  _Short_ TCP sessions will flow to the same machine as
chosen originally, resulting in no breakage.

Longer TCP sessions, in the order of minutes, may have issues.  As
mentioned previously, don't expect large zone AXFRs to work consistently
if requested from a distributed IP address.

--==--
Bruce.
.

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 30 Mar 2005 15:27:50 +0200 (CEST)

On Mon, 28 Mar 2005, Dean Anderson wrote:

> offered by simple failover.

Simple failover does not scale.

The traffic requirement for each nameserver is 1/number-of-listed-servers .
The traffic requirement for each (BGP) anycasted site of an anycasted
nameserver is ( 1/number-of-listed-servers ) / number-of-anycast-sites ,
several orders of magnitude lower than the non-anycasted situation.

As more anycast sites are added to a given name, the traffic requirement
per site goes down.  With simple failover, the limit is the number of
listed nameservers that can be added.  With anycast, the limit is how much
pollution you wish to add to the routing tables.

( The above is simplified, as it assumes careful placement of anycast
  sites within a non-complex mesh.  In any anycast deployment, certain
  anycast sites will receive more traffic than the above, but always less
  than 1/number-of-listed-servers . )

> Remember that anycast has two different paths

So, you're saying that in the simple failover situation, the local
administrators have configured all the checking required to detect the
failure of a given machine, and initiate the subsequent takeover ?

How is this different from the anycast site administrators configuring
checks to detect the failure of the site, and to initiate the withdrawal
of the route from that site ?

The only valid point you have in the above is that when a serious failure
occurs and the replacement/route withdrawal is done by the heartbeat
timers of the other machines/peering routers, the interval for anycast is
very likely to be greater (BGP keepalive) than for simple failover.

I will also point out that you've implied that simple failover has
TCP-state preservation, avoiding TCP session reset and clients trying
their lookup against other servers.  Preserving TCP state between machines
even at the same site is expensive juju; I would not bother doing it with
DNS as the client side will retry.

--==--
Bruce.

.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 30 Mar 2005 15:27:21 -0500 (EST)

> Simple failover does not scale.

Failover is a high availability(HA) technology.  It is not meant to scale,
nor is it appropriate to use HA to scale up transactions per second.

DNS scales up by adding nameservers, and additional delegated zones. And 
of course, faster servers and networks capable of handling more 
transactions.

> per site goes down.  

It does not go down faster than 1/number-of-servers.  The total load on
anycast servers is not less than the original total load.  And anycast
load is not divided evenly.  Up to the limit of 13 servers, it is better
to have 13 servers than it is to have 13 anycast servers. The perceived 
benefit is when you add the 14th server. (below)

> With simple failover, the limit is the number of listed nameservers that
> can be added.  With anycast, the limit is how much pollution you wish to
> add to the routing tables.
> 
>   sites within a non-complex mesh. 

> In any anycast deployment, certain

Err, sort of. The issues with roots is that a limit of 13 was reached.  
Thus, to have a 14th server, you had to anycast.  The load on a server
would be seems to be 1/14 of the total load. (Actually, as you note, it
won't be exactly 1/14 due to path load complexity, but its probably
smaller than 1/13.)  You don't have the option of adding another listed
server. Seems like an improvement, though at some cost.

However, if you have 4 servers, the load on any server will be 1/4 of the 
total offered load.   But you can add another listed server, and the load 
will be 1/5 of the total offered load. If you add an anycast server, the 
load is still 1/5.  No benefit. (And again, due to path load complexities, 
it won't quite be 1/5 with anycast, but it will be smaller than 1/4). In 
Joe Shen's case, Anycast is worse than adding another listed server.

I think Joe plans to have 2 listed servers, with 2 additional anycast
servers. His server load probably won't be 1/4 but will be smaller than
1/2.  If they are both on the same site, he would be off with 4 listed 
servers (which will give him 1/4 on each) and then dividing them into 2 
failover sets in case a server fails, its IP will be taken over by its 
failover partner)

> of the route from that site ?

Its different in that TCP connections can be established even in the face 
of PPLB coming in over the different paths to the servers.

> very likely to be greater (BGP keepalive) than for simple failover.

Uhh, no. BGP keepalive has no relevancy. PPLB means that packets may come 
in on both links on a per-packet basis.  That was the original wrong 
assumption made by ISC: That different paths are taken only as a result of 
BGP routing changes, and that these changes only happen every few minutes 
or few hours.  

> DNS as the client side will retry.

Err, no.  It is well known that a Failover event may break TCP connections
at the time of the failure.  You're right that there is work underway to
try to attempt state preservation (not just TCP, but process state as
well). I agree that this is expensive (or at least complicated) juju.  
But in most cases, server failures are rare, and Failover methods
typically used in production services are meant to get services back
quickly after a failure. There is no guarantee that the failure will not 
be detectable, only that it will be recovered quickly.

Anycast doesn't help with failover.  If there are separate paths to an
anycast server (eg they are on different physical sites), then failure of
anycast server means it won't respond on that path, and the resolver will
have to try another listed server.

Indeed, if you want to have high availability, you need to add failover 
facilities to your anycast servers.

		--Dean

.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 30 Mar 2005 15:48:54 -0500 (EST)

> > those server only serves  a few domain name.

Ah. Well, anycast DNS has been mostly thought about wrt authoritative
servers.  But a cache may also need to make TCP connections for large
packets, someday. So the anycast issues are similar and you shouldn't
ignore the issue.

The load issues are usually a lot different.  You can have hundreds of 
caching servers if you please. Every linux and windows machine can have 
its own cache, if it wanted. Authoritative servers have a maximum limit of 
13.

> adding extra servers to your customer's resolv.confs or equivilant.

Cache only servers are found though resolv.conf (and equivalent) on your
clients.  Adding additional servers to your clients resolv.conf would
help.  I don't know why Bruce would say it wouldn't help. That seems to
need more explanation.

Different resolvers do different things with their resolv.conf 
configuration. Some use the first until it doesn't respond quickly enough, 
and then goes to the second. (most unix resolvers) Some make a random 
selection (Windows?).  

I usually configure the clients to use the closest server, network-wise
first. Then the next closest, etc.  If there is a cache on their lan,
that's the best one for them to use.  If that's down, if there's one on a
high-speed link to that lan, thats the second best. And so on. And unix
resolvers do that.  A simple script can take a client IP address and order
the resolv.conf.

Where order is used by the resolver, it reduces offsite WAN traffic, and
responds at ethernet speeds, rather than, say, T1 speeds on routers that
might otherwise be congested.

.

---

From: jing shen <[email-masked]>
Date: Thu, 31 Mar 2005 13:06:34 +0800

Hi £¬

thanks for all your kindly help.

> server. Seems like an improvement, though at some cost.

To my knowledge, BIND choose root server by comparing response speed
of those root servers. While, some other dns server choose randomly.
On the other hand, as almost all root severs are anycasted load on
each server may differ much.

> will be 1/5 of the total offered load.

No, this is not our situation. In fact, one of four server experience
heavier load than others because of historical reasons ( many
customers know its address). We need to balance load on those four
servers while improving system availablity.

> If you add an anycast server, the

In the first plan, we hope to maintein the original four IP addresses
announced because we do not know how customers use them. By doing
anycast, we think requests will be served by a server group in
which incoming concurrent requests  is shared equally by its member;
on the other hand, by establishing more server groups total load is
divided.

OSPF convergence time may be a problem, and packet forwarding
mechanism inside router may be another problem. I checked cisco's
router, it seems the router decide outgoing path by hashing based on
source IP inside packets,  Juniper do similarly. But there are other
vendors products inside our network, if they behave differently there
may be problem with TCP based application. Is there any possible
problem with UDP based DNS resolve requests?

> facilities to your anycast servers.

Thanks. I'm considering Solaris's IP multi-path function which
will improve availability of link between DNS server and router. But,
I'm not clear how to integrate it with anycast.

-- 
 -- -- 
Regards

Joe Shen

.