Optimizing The DNS Resolvers in Your Network To Leverage All CDNs:Edge Computing

Optimizing the DNS Resolvers in Your
Network to Leverage allopportunities

Grow revenue CDNs/Edge with fast, personalized
web experiences and manage complexity from peak
Computing
demand, mobile devices and data collection.
2016 AKAMAI | FASTER FORWARDTM

Optimizing your Network for CDNs
Congrats on the benefiting with Akamais AANP Program.

The next step will be to update your network to be optimized for ALL
CDNs.
Akamai offers a modern DNS Resolver Solution that allows all

Operators to gain the most out of all their CDN partnerships.
It is a solution that works on standard unix systems, does not need

firewalls, does not need load balancers, is DEV ops ready, is cost
effective, security resilient, and has proven deployment in the larges
carriers.

Agenda
ECS Effective CDN Integration
Why AnswerX?
Questions, Clarifications, Gaps
& Planning

ECS Effective CDN Integration
Grow revenue opportunities with fast, personalized

4 Akamai Confidential Internal Use Only
Are you CDN Optimized?
HTTP2 means that transparent caching is not going to work as
expected.
Partnering with many CDN Operators will be
demand, critical
mobile toand
devices customer
data collection.
experience and bandwidth optimization
CDNs should be pushed as close to the customer edge as possible, BUT

the major of Operators are NOT READY!
Akamais AnswerX rDNS Solution CDN Optimizes the network for better
customer experience and bandwidth savings.
How CDNs Work
When content is requested from CDNs, the user is directed to the optimal
server to serve this user
Theres 2 common ways to do that:
BGP Anycast: the content is served from the location the request is received
(easy to build, requires symmetric routing to work well)
DNS based: the CDN decides where to best serve the content from based
on the resolver it receives the request from, and replies with the optimal
server

How DNS based CDNs Work
Users querying a DNS-based CDNs will be returned different A (and

AAAA) records for the same hostname depending on the resolver the
request comes from
This is called mapping
The better the mapping, the better the CDN

How Akamais CDN works
Example of Akamai mapping
Notice the different A records for different locations:
[NYC]% host www.symantec.com

www.symantec.com CNAME e5211.b.akamaiedge.net.
e5211.b.akamaiedge.net. A 207.40.194.46
[Boston]% host www.symantec.com

www.symantec.com CNAME e5211.b.akamaiedge.net.

How Akamais CDN works
Akamai uses multiple criteria to choose the optimal server
These include standard network metrics:

Latency
Throughput
Packet loss
as well as internal ones such as:

CPU load on the server
HD space
network utilization

How 3rd party (open) resolvers typically work
CDN Node A CDN Node B

end-user
request to 101.10.10.10 request from 74.125.190.1
NS 74.125.190.1?
Resolver DNS best cluster = Node B
Akamai NS
Frontend 101.10.10.10
request to 101.20.15.25 Backend 74.125.190.1
Global frontend anycast address, local unique backend address for

recursive queries
CDN can tell which NS location it came from (by backend-ip)
but not which end-user location or network
The Closest CDN node will be mapped to 74.125.190.1 even if there is
a closer Node!

The Solution: EDNS0 Client-Subnet
IETF EDNS0 client-subnet

https://tools.ietf.org/id/draft-ietf-dnsop-edns-client-subnet-04.txt
The recursive resolver includes the end-users prefix in the

request to the authoritative nameserver
This allows the authoritative nameserver (the CDN) to process

this information and optimize the reply not based on the
requesting nameserver but the end-users prefix

The Solution: EDNS0 Client-Subnet (ECS)

request from 74.125.190.1
end-user With ECS 101.20.15.0/24
request to 101.10.10.10
ECS 101.20.15.0/24
Resolver DNS best cluster = A
Akamai NS
NSID Frontend 101.10.10.10
request from101.20.15.25 Backend 74.125.190.1
ECS sends the subnet from the requesting client to the CDN Operator.
Now the CDN operator know which IP subnet to MAP to the closet CDN
This will scale to large geographic deployments.

Scaling EDNS0 Client Subnet is Critical!

end-user With ECS 101.20.15.0/24
request to 101.10.10.10
ECS 101.20.15.0/24
Resolver DNS best cluster = A
Akamai NS
Frontend 101.10.10.10
request to 101.20.15.25 Backend 74.125.190.1
Legacy DNS solutions are bolting on EDNS0 Client Subnet. This

afterthought engineering has performance implications.
Operators need IPv4 ECS subnets at the /26, /27, and /28 ranges to
meet the IPv4 sacristy challenges.
Operators need IPv6 ECS to work on all subnet ranges.
Legacy DNS solutions have trouble with these long IPv4 ranges (longer
then /22s) and IPv6 ranges.
ECS Privacy Concerns
Only prefix, not full IP transmitted

CDN already gets your full IP anyways (in the subsequent HTTP request)
Set source-netmask/address to 0.0.0.0/0

Google DNS honors forwarding request with 0.0.0.0/0
OpenDNS currently ignores
Do not use client-subnet capable resolver if intention is to hide client origin

ECS Security Concerns
Scanning/walking the mapping algorithm

Double whitelist (at recursive resolver & authoritative NS)
Enforced replacement of client-tagged edns0 option by Google &
OpenDNS before being sent to Akamai
Amplification
Double whitelist
Echoing request in reply
Standard rate limiting methods work
Cache pollution of recursive resolver

Separate reply stored for each prefix

ECS Prefix-Length
Google and OpenDNS currently always send client-subnet as /24

(for privacy/caching-efficiency reasons)
Mapping system has view of Internet from its partners with differing
prefix-lengths
Client-subnet more specific than Akamai

E.g. Akamai has /20 from partner can be mapped
Scope-netmask send to resolver for caching purposes
Client-subnet less specific than Akamai
E.g. Akamai has /26s from partner in different locations no clear choice to
map will take first match
Also send scope-netmask to resolver for information

Improvements with ECS
average&distance&
Open&DNS&India&
2"Jan& 9"Jan& 16"Jan& 23"Jan& 30"Jan& 6"Feb& 13"Feb& 20"Feb& 27"Feb&

Additional ECS Use-Case
Can be used within a partners network instead of

distributed DNS architecture
A partner might have a widespread network (especially

in countries spanning large geographical areas and/or
different islands)
Would like to deploy clusters around the network to
localize traffic
But central DNS infrastructure makes mapping traffic
accurately difficult

Example for Distributed Architecture
Delhi
Kolkata
Mumbai (NS)
Bangalore Chennai
Nameserver
Akamai Cluster

CDN Solutions
Deploy additional NS in all locations (buy more rDNS servers)

Benefit: better DNS responses, can use anycast frontend IP to simplify
administration/failover (announcing same frontend IP to all end-users)
Drawback: additional CAPEX & support-costs
Virtual IPs on existing NS given to different geographic sets of end-users

Benefit: no additional CAPEX, easy to implement
Drawback: more difficult to administer, will require manual allocation of IPs to clusters on
CDN side, no clear fallback
OPEX and Customer Support cost increases
ECS within the providers network

Benefit: no additional CAPEX, only software change on the NS, can dynamically adapt by
changing announcements, can scale for very small clusters in remote places
Drawback: needs compatible NS software

Question for the Operator
Is your network Ready for CDN Optimization
Is your network set up for CDNs?

Is you Akamai, Facebook, Netflix, and other traffic staying on on your
local CDN nodes, or going off to the Internet?
Deploying a modern rDNS solution with scalable ECS is your first
step.

ECS Challenges with 3rd Party rDNS

The Problem: 3rd Party DNS servers
When end-users use 3rd party DNS services (rather than own ISPs DNS):
28 locations worldwide 20 locations worldwide

DNS-based CDN does not know the identity of the originating network
Best case, can serve the request in a rough geographic area

How 3rd party (open) resolvers typically work
end-user
NS 74.125.190.1?
best cluster = ?
3RD party DNS Akamai NS
End-User IP frontend 8.8.8.8
192.0.2.24 backend 74.125.190.1
Global rDNS frontend anycast address in the SP or Cloud

Which is closer to the content when the SP or Cloud rDNS is in some other part
of the network (or some other country)?
What is needed is a way for the CDN operators to see the end-users IP
address.

Use of 3rd party DNS servers
Relatively small numbers (less than 1%) in most countries

with mature Internet ecosystems. Examples include:
U.S Germany Netherlands Singapore

But very high percentage of users in developing countries and/or
countries performing some form of DNS-based web-filtering:
Brazil 12% Turkey 22% Indonesia 22% Bangladesh 25%

Use of 3rd party DNS servers in India
ISP DNS Google OpenDNS Others

ISP A 85.9% 6.4% 1.5% 6.2%
ISP B 81.3% 9.4% 2.7% 6.6%
ISP C 80.1% 5.8% 0.8% 13.2%
ISP D 76.0% 4.6% 0.4% 18.9%
ISP E 71.2% 1.9% 0.0% 26.9%
ISP F 64.9% 4.4% 0.2% 30.5%

Is 3rd Party rDNS a Problem?
Is your rDNS a performance problem?
End Users will move to a 3rd Party rNDS for two reasons Speed
and bypass censorship.
Fast Resolution times are critical. Many times Google DNS and other
3rd party rDNS systems are faster than the local Operators rDNS.
This includes the mapping to the CDNs from the 3rd parties.

AnswerX Quick Review

Akamais DNS Products
Auth DNS Service Recursive DNS Technology Recursive DNS Service
Fast DNS AnswerX Licensed AnswerX
Managed | Cloud
Authoritative
DNS
Recursive
DNS
150 PoPs, 85
cities and 29 Serving >50M subscribers
First Managed Live
countries >10 Trillion Queries per Month
Q1 2017
>400B Queries per Day
The Quick Review AnswerX Update
AnswerX is Winning vs the Competition
AnswerX is the only modern rDNS solution in the market that works on
common off the shelf & virtualized architectures.
We have the features & functions that work for the industry.
We have business models that scale for the NEW FUTURE of
NETWORKING!
OLD SCHOOL of BOXED rDNS NEW SCHOOL of MULTIPLE rDNS

Try AnswerX Today!
Where to find AnswerX and Get a Trial?
www.akamai.com/dns - Akamais DNS

Page
Details on AnswerX -
https://www.akamai.com/us/en/solutions/p
roducts/network-operator/answerx-
intelligent-dns.jsp
AnswerX Trials E-mail to
answerx-questions@akamai.com

ECS & DNS scaling
Tech Talk based on studies done by Akamai to review the effectiveness of
ECS.
Ramesh
Fangfei Chen Marcelo Torres
Sitaraman
Akamai Akamai
UMass & Akamai
Matt LeBourgeois
Akamai
EDNS0 client subnet extension (ECS)
ECS extension: DNS request-response for a specific client subnet.
Mapping
LDNS b.akamai.net
for 1.2.3.0/24
72.246.9.228
DNS Query for 1.2.3.0/24
b.akamai.net
72.246.9.228
HTTP
Client reques Content
1.2.3.4 t Server
Content 72.246.9.228

Carrier DNS Infrastructure
Cornerstone of the Internet
Critical resources:
DNS cache
CPU/Interface cycles to respond to
queries
Cost burden for most ISPs

Attack capacity
Operators cut corners
Centralization helps reduce scaling needs

*Data collected by F5

DNS Scaling to Support ECS
DNS records by hostname X CIDR block
Scaling of recursive DNS

Carriers are
Increase in query rate
Increase in demands on DNS cache
reticent to adopt
View from Google and OpenDNS ECS rollout:
ECS!
Increase in DNS query rate during Increase in DNS query rate by
rollout hostname
1000
Factor increase in query rate

7e+05
More popular domain name and LDNS pairs

100 saw more increase.
hits
5e+05 8x-10x increase on average

Increase
due to
ECS 10
3e+05 rollout
1
Jan Feb Mar Apr May Jun Jul
date 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Popularity of Domain name and LDNS pairs (in queries per TTL)
variable edns0 other 2016 AKAMAI | FASTER FORWARDTM
Request rate -> DNS query rate
Requests
TTL !# TTL !$ TTL !% TTL !& TTL
Induced DNS queries
System alternates between two states

TTL - active record in cache
!" - Wait for next request subsequent to TTL expiry

Basic Poisson model
Exploit renewal process theory and memoryless nature of Poisson arrival process
Critical parameters: Poisson request rate ('), TTL (()
Recurrent Renewal process

Time between arrivals that generate two queries is a renewal
Renewal period = ( + time to next arrival.
C !" = #D
D
DNS query rate =
DJK#
DJ
In-cache prob =
DJK#
Mappers NSD algorithm depends on this logic to estimate request rates behind recursive
TT
!#
TT
!$
TT
!%
TT
!&
TT
L L L L L
resolvers

ECS Poisson Model
ECS Query rate ratio
ECS Query Rate N

Interested in ratio:
Regular Query Rate
Example:
N client CIDR blocks, each generating requests at
D
identical rate T.
Critical parameter: '( (number of expected arrivals in TTL period)
ratio
Conclusions:
The larger the critical parameter, the higher the impact
on the ratio.
The ratio is related to the number of active CIDRs
directly.

ECS Poisson Model Part II
ECS Query rate ratio
1/(1-)
May not be possible to identify a specific set of CIDRs

that are active in a uniform way.
Poisson model extension offers following insight:
Order CIDRs by request rate.

Suppose nth CIDR has request rate:
ratio
'U WU X '
Then ECS query rate ratio is no worse than
(1 W)]#
Popularity distribution across CIDRs may exhibit

exponential decay.

What do we want to study
Empirical analysis of AnswerX data

Quantify scaling of DNS burden due to ECS adoption
What % DNS records are subject to scaling?
How does DNS query rate scale?
How does DNS cache bloat?
Do Poisson Models help us understand scaling
Does empirical data suggest they apply?
Are their adaptations that make sense?
Distributional nature of hostname popularity
Is popularity concentrated in small numbers of CIDR blocks?
What do statistics look like across hostnames?
Do temporal biases matter?
How does this bear upon DNS infrastructure scaling?

Optimizing The DNS Resolvers in Your Network To Leverage All CDNs:Edge Computing

Uploaded by

Copyright:

Available Formats

Optimizing The DNS Resolvers in Your Network To Leverage All CDNs:Edge Computing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Optimizing The DNS Resolvers in Your Network To Leverage All CDNs:Edge Computing

Uploaded by

Copyright:

Available Formats

Optimizing the DNS Resolvers in Your

Network to Leverage allopportunities

2016 AKAMAI | FASTER FORWARDTM

Congrats on the benefiting with Akamais AANP Program.

Akamai offers a modern DNS Resolver Solution that allows all

It is a solution that works on standard unix systems, does not need

2016 AKAMAI | FASTER FORWARDTM

ECS Effective CDN Integration

Questions, Clarifications, Gaps

2016 AKAMAI | FASTER FORWARDTM

2016 AKAMAI | FASTER FORWARDTM

CDNs should be pushed as close to the customer edge as possible, BUT

Theres 2 common ways to do that:

2016 AKAMAI | FASTER FORWARDTM

Users querying a DNS-based CDNs will be returned different A (and

This is called mapping

The better the mapping, the better the CDN

2016 AKAMAI | FASTER FORWARDTM

Example of Akamai mapping

Notice the different A records for different locations:

[NYC]% host www.symantec.com

[Boston]% host www.symantec.com

2016 AKAMAI | FASTER FORWARDTM

Akamai uses multiple criteria to choose the optimal server

These include standard network metrics:

as well as internal ones such as:

2016 AKAMAI | FASTER FORWARDTM

CDN Node A CDN Node B

Global frontend anycast address, local unique backend address for

2016 AKAMAI | FASTER FORWARDTM

IETF EDNS0 client-subnet

The recursive resolver includes the end-users prefix in the

This allows the authoritative nameserver (the CDN) to process

2016 AKAMAI | FASTER FORWARDTM

CDN Node A CDN Node B

This will scale to large geographic deployments.

2016 AKAMAI | FASTER FORWARDTM

CDN Node A CDN Node B

Legacy DNS solutions are bolting on EDNS0 Client Subnet. This

Only prefix, not full IP transmitted

Set source-netmask/address to 0.0.0.0/0

Do not use client-subnet capable resolver if intention is to hide client origin

2016 AKAMAI | FASTER FORWARDTM

Scanning/walking the mapping algorithm

Cache pollution of recursive resolver

2016 AKAMAI | FASTER FORWARDTM

Google and OpenDNS currently always send client-subnet as /24

Client-subnet more specific than Akamai

2016 AKAMAI | FASTER FORWARDTM

2"Jan& 9"Jan& 16"Jan& 23"Jan& 30"Jan& 6"Feb& 13"Feb& 20"Feb& 27"Feb&

2016 AKAMAI | FASTER FORWARDTM

Can be used within a partners network instead of

A partner might have a widespread network (especially

2016 AKAMAI | FASTER FORWARDTM

2016 AKAMAI | FASTER FORWARDTM

Deploy additional NS in all locations (buy more rDNS servers)

Virtual IPs on existing NS given to different geographic sets of end-users

ECS within the providers network

2016 AKAMAI | FASTER FORWARDTM