anycast dns service architecture

8/3/2019 Anycast DNS Service Architecture

1/47

Best Practices in DNS AnycastService-Provision Architecture

Version 1.1March 2006

Bill WoodcockGaurab Raj Upadhaya


2/47


3/47

Reasons for AnycastTransparent fail-over redundancy

Latency reduction

Load balancing

Attack mitigation

Configuration simplicity (for end users)or lack of IP addresses (for the root)


4/47

No Free LunchThe two largest benefits, fail-overredundancy and latency reduction,both require a bit of work to operateas youd wish.


5/47

Fail-Over RedundancyDNS resolvers have their own fail-overmechanism, which works... um... okay.

Anycast is a very large hammer.

Good deployments allow these two

mechanisms to reinforce each other,rather than allowing anycast to foil theresolvers fail-over mechanism.


6/47

Resolvers Fail-Over MechanismDNS resolvers like those in your computers,and in referring authoritative servers, can

and often do maintain alist

of nameserversto which theyll send queries.

Resolver implementations differ in how theyuse that list, but basically, when a serverdoesnt reply in a timely fashion, resolverswill try another server from the list.


7/47

Anycast Fail-Over MechanismAnycast is simply layer-3 routing.

A resolvers query will be routed to thetopologically nearest instance of theanycast server visible in the routing table.

Anycast servers govern their own visibility.

Latency depends upon the delaysimposed by that topologically short path.


8/47

Conflict Between These MechanismsResolvers measure by latency.

Anycast measures by hop-count.

They dont necessarily yield the same answer.

Anycast always trumps resolvers, if its allowed to.

Neither the DNS service provider nor the user arelikely to care about hop-count.

Both care a great deal about latency.


9/47

How The Conflict Plays Out

Client AnycastServers


10/47


Low-latency,

high hop-countdesirable path

High-latency,low hop-countundesirable path

Client AnycastServersns1.foons2.foo

Two servers withthe same routing

policy


11/47


Anycastchoosesthis one

Low-latency,





policy


12/47


Resolverchoosesthis one

Anycastchoosesthis one

Low-latency,





policy


13/47


Anycasttrumps

resolver

Low-latency,





policy


14/47

Resolve the Conflict

The resolver uses different IP addresses for its fail-overmechanism, while anycast uses the same IP addresses.

Low-latency,





15/47


ClientAnycastCloud AAnycastCloud B

Low-latency,high hop-count

desirable path

High-latency,low hop-count

undesirable pathns2.foons1.foo

Split the anycast deployment into clouds of locations, eachcloud using a different IP address and different routing policies.


16/47



desirable path


undesirable path

This allows anycast to present the nearest servers,and allows the resolver to choose the one which performs best.

Client

ns2.foons1.foo

AnycastCloud A

AnycastCloud B


17/47



desirable path


undesirable path

These clouds are usually referred to as A Cloud and B Cloud.The number of clouds depends on stability and scale trade-offs.

Client

ns2.foons1.foo

AnycastCloud A

AnycastCloud B


18/47

Latency ReductionLatency reduction depends upon thenative layer-3 routing of the Internet.

The theory is that the Internet will deliverpackets using the shortest path.

The reality is that the Internet will deliverpackets according to ISPs policies.


19/47

Latency ReductionISPs routing policies differ from shortest-path where theres an economic

incentive to deliver by a longer path.


20/47

ISPs Economic Incentives(Grossly Simplified)

ISPs have high cost to deliver traffic throughtransit.

ISPs have a low cost to deliver traffic through

their peering.

ISPs receive money when they deliver trafficto their customers.


21/47

ISPs Economic Incentives(Grossly Simplified)

Therefore, ISPs will deliver traffic to acustomer across a longer path, before bypeering or transit across a shorter path.

If you are both a customer, and acustomer of a peer or transit provider,this has important implications.


22/47

Normal Hot-Potato Routing

AnycastInstance

West

AnycastInstance

East

ExchangePointWest

ExchangePointEast

Transit Provider Green

If the anycast network is not a customer of large Transit Provider Red...

...but is a customer of large Transit Provider Green...

Transit Provider Red


23/47


AnycastInstance

West

AnycastInstance

East

ExchangePointWest

ExchangePointEast


Traffic from Reds customer...


Red Customer East


24/47



AnycastInstance

West

AnycastInstance

East

ExchangePointWest

ExchangePointEast


Red Customer East...then traffic from Reds customer...

...is delivered from Red to Green via local peering, and reaches the local anycast instance.


25/47

How the Conflict Plays Out

AnycastInstance

West

AnycastInstance

East


ExchangePointWest

ExchangePointEast


But if the anycast network is a customer of both large Transit Provider Red...

... and of large Transit Provider Green, but not at all locations ...


26/47


AnycastInstance

West

AnycastInstance

East

ExchangePointWest

ExchangePointEast


...then traffic from Reds customer...

...will be misdelivered to the remote anycast instance...

Red Customer East


27/47


AnycastInstance

West

AnycastInstance

East

ExchangePointWest

ExchangePointEast



...will be misdelivered to the remote anycast instance, because a customer connection ...

Red Customer East


28/47


AnycastInstance

West

AnycastInstance

East

ExchangePointWest

ExchangePointEast



...will be misdelivered to the remote anycast instance, because a customer connection

is preferred for economic reasons over a peering connection .

Red Customer East


29/47


AnycastInstance

West

AnycastInstance

East

ExchangePointWest

ExchangePointEast

Any two instances of an anycast service IP address musthave the same set of large transit providers at all locations .

This caution is not necessary with small transit providers who dont have the

capability of backhauling traffic to the wrong region on the basis of policy.




30/47

Putting the Pieces Together We need an A Cloud and a B Cloud . We need a redundant pair of the same transit

providers at most or all instances of each cloud.

We need a redundant pair of hidden masters forthe DNS servers.

We need a network topology to carry control andsynchronization traffic between the nodes.


31/47

Redundant Hidden Masters


32/47

An A Cloud and a B Cloud


33/47

A Network TopologyDual Wagon-Wheel

A Ring

B Ring


34/47

Redundant TransitTwo ISPs

ISP RedISP Green


35/47

Redundant Transit

ISP Blue ISP Yellow

Or four ISPs

ISP RedISP Green


36/47

Local PeeringIXP

IXP

IXP

IXP

IXP

IXP

IXP

IXPIXP

IXP


37/47

Resolver-Based Fail-Over

CustomerResolverServerSelection

CustomerResolver

ServerSelection


38/47

Resolver-Based Fail-Over

CustomerResolverServerSelection

CustomerResolver

ServerSelection


39/47

Internal Anycast Fail-Over

CustomerResolver

CustomerResolver


40/47

Global Anycast Fail-Over

CustomerResolver

CustomerResolver


41/47

Unicast Attack Effects

DistributedDenial-of-ServiceAttackers

Traditional unicast server deployment...


42/47




...exposes all servers to all attackers.


43/47



BlockedLegitimate

Users


...exposes all servers to all attackers,leaving no resources for legitimate users.


44/47

Anycast Attack Mitigation



45/47



ImpactedLegitimate

Users


46/47



UnaffectedLegitimate

Users

ImpactedLegitimate

Users


47/47

Thanks, and Questions?

Copies of this presentation can be found

http:// www.pch.net / resources / papers / dns-service-architecture

[email protected]

[email protected]

anycast dns service architecture

Documents