Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in...
Transcript of Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in...
![Page 1: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/1.jpg)
Best Practices in
DNS Service-Provision
Architecture
Version 1.2Bill Woodcock
Packet Clearing House
![Page 2: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/2.jpg)
Nearly all DNS is AnycastLarge ISPs have been anycasting recursive DNS servers for more than twenty years.
Which is a very long time, in Internet years.
All but one of the root nameservers are anycast.
All the large gTLDs are anycast.
![Page 3: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/3.jpg)
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)
![Page 4: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/4.jpg)
No Free LunchThe two largest benefits, fail-over redundancy and latency reduction, both require a bit of work to operate as you’d wish.
![Page 5: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/5.jpg)
Fail-Over RedundancyDNS resolvers have their own fail-over mechanism, 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 the resolvers’ fail-over mechanism.
![Page 6: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/6.jpg)
Resolvers’ Fail-Over MechanismDNS resolvers like those in your computers, and in referring authoritative servers, can and often do maintain a list of nameservers to which they’ll send queries.
Resolver implementations differ in how they use that list, but basically, when a server doesn’t reply in a timely fashion, resolvers will try another server from the list.
![Page 7: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/7.jpg)
Anycast Fail-Over MechanismAnycast is simply layer-3 routing.
A resolver’s query will be routed to the topologically nearest instance of the anycast server visible in the routing table.
Anycast servers govern their own visibility.
Latency depends upon the delays imposed by that topologically short path.
![Page 8: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/8.jpg)
Conflict Between These MechanismsResolvers measure by latency.
Anycast measures by hop-count.
They don’t necessarily yield the same answer.
Anycast always trumps resolvers, if it’s allowed to.
Neither the DNS service provider nor the user are likely to care about hop-count.
Both care a great deal about latency.
![Page 9: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/9.jpg)
How The Conflict Plays Out
Client AnycastServers
![Page 10: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/10.jpg)
How The Conflict Plays Out
Low-latency,high hop-countdesirable path
High-latency,low hop-countundesirable path
Client AnycastServers
ns1.foons2.foo
Two servers with the same routing policy
![Page 11: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/11.jpg)
How The Conflict Plays Out
Anycastchoosesthis one
Low-latency,high hop-countdesirable path
High-latency,low hop-countundesirable path
Client AnycastServers
ns1.foons2.foo
Two servers with the same routing policy
![Page 12: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/12.jpg)
How The Conflict Plays Out
Resolverchoosesthis one
Anycastchoosesthis one
Low-latency,high hop-countdesirable path
High-latency,low hop-countundesirable path
Client AnycastServers
ns1.foons2.foo
Two servers with the same routing policy
![Page 13: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/13.jpg)
How The Conflict Plays Out
Anycasttrumpsresolver
Low-latency,high hop-countdesirable path
High-latency,low hop-countundesirable path
Client AnycastServers
ns1.foons2.foo
Two servers with the same routing policy
![Page 14: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/14.jpg)
Resolve the Conflict
The resolver uses different IP addresses for its fail-over mechanism, while anycast uses the same IP addresses.
Low-latency,high hop-countdesirable path
High-latency,low hop-countundesirable path
Client AnycastServers
ns1.foons2.foo
![Page 15: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/15.jpg)
Resolve the Conflict
ClientAnycastCloud A
AnycastCloud B
Low-latency,high hop-countdesirable path
High-latency,low hop-count
undesirable pathns2.foons1.foo
Split the anycast deployment into “clouds” of locations, each cloud using a different IP address and different routing policies.
![Page 16: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/16.jpg)
Resolve the Conflict
Low-latency,high hop-countdesirable path
High-latency,low hop-count
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
![Page 17: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/17.jpg)
Resolve the Conflict
Low-latency,high hop-countdesirable path
High-latency,low hop-count
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
![Page 18: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/18.jpg)
Latency ReductionLatency reduction depends upon the native layer-3 routing of the Internet.
The theory is that the Internet will deliver packets using the shortest path.
The reality is that the Internet will deliver packets according to ISPs’ policies.
![Page 19: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/19.jpg)
Latency ReductionISPs’ routing policies differ from shortest-path where there’s an economic incentive to deliver by a longer path.
![Page 20: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/20.jpg)
ISPs’ Economic Incentives(Grossly Simplified)
ISPs have high cost to deliver traffic through transit.
ISPs have a low cost to deliver traffic through their peering.
ISPs receive money when they deliver traffic to their customers.
![Page 21: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/21.jpg)
ISPs’ Economic Incentives(Grossly Simplified)
Therefore, ISPs will deliver traffic to a customer across a longer path, before by peering or transit across a shorter path.
If you are both a customer, and a customer of a peer or transit provider, this has important implications.
![Page 22: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/22.jpg)
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
![Page 23: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/23.jpg)
Normal Hot-Potato Routing
AnycastInstance
West
AnycastInstance
East
ExchangePointWest
ExchangePointEast
Transit Provider Green
Traffic from Red’s customer...
Transit Provider Red
Red Customer East
![Page 24: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/24.jpg)
Transit Provider Red
Normal Hot-Potato Routing
AnycastInstance
West
AnycastInstance
East
ExchangePointWest
ExchangePointEast
Transit Provider Green
Red Customer East...then traffic from Red’s customer...
...is delivered from Red to Green via local peering, and reaches the local anycast instance.
![Page 25: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/25.jpg)
How the Conflict Plays Out
AnycastInstance
West
AnycastInstance
East
Transit Provider Red
ExchangePointWest
ExchangePointEast
Transit Provider Green
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...
![Page 26: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/26.jpg)
How the Conflict Plays Out
AnycastInstance
West
AnycastInstance
East
ExchangePointWest
ExchangePointEast
Transit Provider Green
...then traffic from Red’s customer...
...will be misdelivered to the remote anycast instance...
Red Customer East
![Page 27: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/27.jpg)
How the Conflict Plays Out
AnycastInstance
West
AnycastInstance
East
ExchangePointWest
ExchangePointEast
Transit Provider Green
...then traffic from Red’s customer...
...will be misdelivered to the remote anycast instance, because a customer connection...
Red Customer East
![Page 28: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/28.jpg)
How the Conflict Plays Out
AnycastInstance
West
AnycastInstance
East
ExchangePointWest
ExchangePointEast
Transit Provider Green
...then traffic from Red’s customer...
...will be misdelivered to the remote anycast instance, because a customer connectionis preferred for economic reasons over a peering connection.
Red Customer East
![Page 29: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/29.jpg)
Resolve the Conflict
AnycastInstance
West
AnycastInstance
East
ExchangePointWest
ExchangePointEast
Any two instances of an anycast service IP address must have the same set of large transit providers at all locations.
This caution is not necessary with small transit providers who don’t have the capability of backhauling traffic to the wrong region on the basis of policy.
Transit Provider Red
Transit Provider Green
![Page 30: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/30.jpg)
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 for the DNS servers.
• We need a network topology to carry control and synchronization traffic between the nodes.
![Page 31: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/31.jpg)
Redundant Hidden Masters
![Page 32: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/32.jpg)
An A Cloud and a B Cloud
![Page 33: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/33.jpg)
A Network Topology“Dual Wagon-Wheel”
A Ring
B Ring
![Page 34: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/34.jpg)
Redundant TransitTwo ISPs
ISP RedISP Green
![Page 35: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/35.jpg)
Redundant Transit
ISP Blue ISP Yellow
Or four ISPs
ISP RedISP Green
![Page 36: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/36.jpg)
Local Peering
IXP
IXP
IXP
IXP
IXP
IXP
IXP
IXPIXP
IXP
![Page 37: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/37.jpg)
Resolver-Based Fail-Over
CustomerResolverServerSelection
CustomerResolver
ServerSelection
![Page 38: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/38.jpg)
Resolver-Based Fail-Over
CustomerResolverServerSelection
CustomerResolver
ServerSelection
![Page 39: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/39.jpg)
Internal Anycast Fail-Over
CustomerResolver
CustomerResolver
![Page 40: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/40.jpg)
Global Anycast Fail-Over
CustomerResolver
CustomerResolver
![Page 41: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/41.jpg)
Unicast Attack Effects
DistributedDenial-of-ServiceAttackers
Traditional unicast server deployment...
![Page 42: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/42.jpg)
Unicast Attack Effects
DistributedDenial-of-ServiceAttackers
Traditional unicast server deployment...
...exposes all servers to all attackers.
![Page 43: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/43.jpg)
Unicast Attack Effects
DistributedDenial-of-ServiceAttackers
BlockedLegitimate
Users
Traditional unicast server deployment...
...exposes all servers to all attackers,leaving no resources for legitimate users.
![Page 44: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/44.jpg)
Anycast Attack Mitigation
DistributedDenial-of-ServiceAttackers
![Page 45: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/45.jpg)
Anycast Attack Mitigation
DistributedDenial-of-ServiceAttackers
ImpactedLegitimateUsers
![Page 46: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/46.jpg)
Anycast Attack Mitigation
DistributedDenial-of-ServiceAttackers
UnaffectedLegitimate
Users
ImpactedLegitimateUsers
![Page 47: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/47.jpg)
Copies of this presentation can befound in PDF and QuickTime formats at:
https:// pch.net / resources / papers / dns-service-architecture
Bill WoodcockResearch Director
Packet Clearing [email protected]
Thanks, and Questions?
![Page 48: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/48.jpg)
Packet Clearing House
Overview of PCH DNS Anycast Service and Infrastructure
Bill WoodcockMarch, 2016
![Page 49: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/49.jpg)
Packet Clearing House
Overall Topology
![Page 50: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/50.jpg)
Packet Clearing House
Registry
Overall Topology
HiddenMaster
HiddenMaster
![Page 51: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/51.jpg)
Packet Clearing House
Registry
Overall Topology
HiddenMaster
HiddenMaster
IntakeSlave
IntakeSlave
IntakeSlave
OutboundMaster
OutboundMaster
OutboundMaster
PCH
![Page 52: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/52.jpg)
Packet Clearing House
Registry
Overall Topology
HiddenMaster
HiddenMaster
IntakeSlave
IntakeSlave
IntakeSlave
AnycastNode
AnycastNode
AnycastNode
AnycastNode
...
OutboundMaster
OutboundMaster
OutboundMaster
PCH
![Page 53: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/53.jpg)
Packet Clearing House
Registry
Overall Topology
HiddenMaster
HiddenMaster
IntakeSlave
IntakeSlave
IntakeSlave
DNSSEC SigningInfrastructure
AnycastNode
AnycastNode
AnycastNode
AnycastNode
...
OutboundMaster
OutboundMaster
OutboundMaster
PCH
![Page 54: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/54.jpg)
Packet Clearing House
Registry
Overall Topology
HiddenMaster
HiddenMaster
IntakeSlave
IntakeSlave
IntakeSlave
MeasurementSlave
MeasurementSlave
MeasurementProbe
MeasurementProbe
DNSSEC SigningInfrastructure
AnycastNode
AnycastNode
AnycastNode
AnycastNode
...
OutboundMaster
OutboundMaster
OutboundMaster
PCH
![Page 55: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/55.jpg)
Packet Clearing House
130 Locations
![Page 56: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/56.jpg)
Packet Clearing House
Anycast Node Construction135 locations at the moment, adding a new one about every ten days. 70% are “small” 250Mbps 20% are “medium” 20-60Gbps 10% are “large” 60-120GbpsAll installations are preconfigured. Small are self-installed by the local host, while medium and large are installed by PCH staff.
![Page 57: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/57.jpg)
Packet Clearing House
Small (70%)
Cisco 2921 Router250Mbps throughput
Internally-integratedCisco UCS-E160D-M2 x86 server64GB RAM, 2x 1TB SATA drives
2Gbps peering1Gbps transit
All-in-one enclosure, ships preconfigured in a single
shipping crate, requires only three patch cords and one
power cord to bring up.
![Page 58: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/58.jpg)
Packet Clearing House
Medium (20%)
Cisco ASR9001 Router
Two Cisco UCSC-C220-M4S x86 servers768GB RAM, 8x 1TB SAS drives
10-40Gbps peering10-20Gbps transit
CiscoNexus 3548
10Gbps Switch
![Page 59: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/59.jpg)
Packet Clearing House
Large (10%)
Cisco ASR9006 Router
3x-8x CiscoUCSC-C220-M4S
x86 servers768GB RAM
8x 1TB SAS drives
40-80Gbps peering20-40Gbps transit
CiscoNexus 9396 10/40Gbps
Switch
![Page 60: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/60.jpg)
Packet Clearing House
Making Our Own BandwidthEssentially all Internet bandwidth (more than 98%) is produced by “peering” in Internet Exchange Points.
Bandwidth is transported from IXPs to the point of consumption, increasing in cost, and suffering loss and latency along the way. This is called “transit.”
Unlike other DNS service providers, we are not dependent upon transit. We serve data exclusively from within IXPs, producing essentially all of our own bandwidth at higher quality and lower cost.
![Page 61: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/61.jpg)
Packet Clearing House
Nondiscriminatory AccessOther DNS service providers dependency upon transit makes registries’ zone data a pawn in local transit politics.
By contrast, through our open peering, PCH makes the zones of the registries we serve equally available to all networks and users at no cost.
We already have nearly 8,000 direct connections with other networks in 130 locations on six continents, and add more every day.
![Page 62: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/62.jpg)
Packet Clearing House
New Zone AutoconfigurationFrom trusted registries, over authenticated transport, we autoconfigure new zones.
If we see an update pertaining to a zone that we’re not configured for, we automatically configure that zone across our infrastructure.
If the zone goes stale, we check whether it’s delegated to our servers from the root. If not, we deconfigure it and stop serving it.
![Page 63: Best Practices in DNS Service-Provision Architecture · Copies of this presentation can be found in PDF and QuickTime formats at: https:// pch.net / resources / papers / dns-service-architecture](https://reader033.fdocuments.us/reader033/viewer/2022060600/605403e0353363551b2b290d/html5/thumbnails/63.jpg)
Packet Clearing House
AXFR to IXFRWhen registries serve us zone data via AXFR or we perform a DNSSEC full-zone signing, we convert to IXFR within our infrastructure, optimizing performance, particularly to our remotest anycast nodes.