SlideShare a Scribd company logo
1 of 37
Download to read offline
Measuring the
Centralization of
DNS Resolution
Geoff Huston, Joao Damas,
APNIC Labs
What are we talking about?
• The DNS is a highly decentralised database that distributes its
contents over much of the Internet
• The DNS data model also includes information replication (secondary
authoritative servers) that attempts to provide resiliency and
scalability by removing critical single choke points within the database
• The DNS name resolution protocol includes query fallback to increase
the robustness of name resolution
• It all sounds as if the DNS highly diverse and extensively
decentralised.
What are we talking about?
• The DNS is a highly decentralised database that distributes its
contents over much of the Internet
• The DNS data model also includes information replication (secondary
authoritative servers) that attempts to provide resiliency ands
scalability by removing critical single choke points within the database
• The DNS name resolution protocol includes query fallback to increase
the robustness of name centralisation
• It all sounds as if the DNS highly diverse and extensively
decentralised.
But
is
it
really
decentralised?
Measuring Centrality
• Various measures have been used in the related space of market
dominance which appear to have some relevance to the study of
market dominance in the DNS
• Australia’s Consumer and Competition agency uses a metric of 70% market
share by a single entity
• Or there is the four-firm concentration ratio which uses the market share of
the four largest firms
• Or there is the Hirfindahl-Hirschman index
Herfindahl-Hirschman Index
• The HHI is used in market analysis to indicate the level of competition
between market entities. It is the average market share of the market,
weighted by market share
• Sum of the square of the market share (%) of the top 50 entities
• Above 25% is often taken as an indicator of market skew
• Above 10% is would be considered as a market showing “moderate
concentration”
The DNS resolution environment
• The question of centrality in the DNS resolution environment is
equivalent to the questions of market dominance and market
concentration
• So lets look at DNS resolution as a market and use these
measurements to assess the degree of concentration in the supply of
DNS resolution services
Looking at concentration in
DNS Name Resolution
Recursive Resolver Authoritative Server
user
I. How centralized is the recursive resolver function?
II. How centralized is the authoritative server function?
Stub-to-Recursive Recursive-to-Authoritative
I Recursive Resolution
Measuring Recursive Resolution
We use Ads to send each user a unique DNS name to resolve.
We use an authoritative server as the data collection point and collect the IP
address of the resolvers asking the authoritative server
We then use the Ad presentation data to match this query to an end user IP
address
Recursive Resolver Authoritative Server
user
Ad placement data
<ID, IPaddr>
DNS query data
<ID, DNS resolver IPaddr>
Measurement
Tuning the measurement
• The Authoritative Server always answers queries immediately with
the A / AAAA records as requested
• The data is unsigned and the responses fit comfortably within 512
octets of DNS payload
• We try to minimise timeouts and requeries by steering users to a DNS
Authoritative server that is (roughly) on the same continent as the
user
Mapping
• We need to map the resolver “helper” addresses to a resolver service
• Which back-end DNS addresses are used by each open resolver?
• RIPE Atlas helped here for those cases where the open resolver operator does
not publish this information
• We map resolvers into a number of categories based on the resolver’s
IP address. The categories we use:
• Resolver is in the same AS as the end user
• It’s a known Open DNS resolver
• Resolver is geo-located to the same CC as the end user
• Resolver is geo-located to a different CC from the end user
Results
June 2020 October 2022
Same AS
Google
Same CC
Cloudflare
Others
Results
• Two-thirds of users direct their queries to the recursive resolver that is
operated by their ISP
• One seventh (15%) of users have their queries resolved by Google’s
Public DNS resolver
• One seventh (15%) of users direct their queries to a recursive resolver
that is geolocated to the same country as they are – probably their ISP
using a resolver in a different AS
• Everything else – nothing more than 3%
• Is the recursive resolver market centralized? Probably not
• Is the open recursive resolver market centralized? That’s a different question!
• But first let’s understand what is being measured here
However, the measurement is not
as simple as it may suggest
• We observe that this single initial query
generates 1 or more queries from a single
recursive resolver IP address just 30% of
the time
• 2 or more different resolvers are queried
in 60% of cases
• Most of the time (90% of cases) these
multiple resolver IP addresses are all in the
same AS
Cumulative Distribution of number of resolver IP
addresses seen to query for a unique DNS name
Multiple resolvers “see”
individual stub queries
• We see an average of 3.23 distinct resolver IP addresses at the
authoritative server for each queried domain name within the first 15
seconds
• What should we do with these “extra” DNS queries?
• In this case we just add them to the count
• So we are measuring who “sees” my DNS queries
What are we measuring here?
• So we thought that maybe we really wanted to know all the resolvers
who might see your query
• But to flush out all of these resolvers we need to adjust this
experiment
Seeing Everything!
• Get the authoritative server to return SERVFAIL all the time
• This way the stub resolver is likely to cycle through all the locally
configured recursive resolvers to find a non-SERVFAIL DNS response
All Recursive Resolvers
• Two-thirds of users direct their queries to
the recursive resolver that is operated by
their ISP
• One seventh (15%) of users have their
queries resolved by Google’s Public DNS
resolver
• One seventh (15%) of users direct their
queries to a recursive resolver that is
geolocated to the same country as they
are – probably their ISP using a resolver in
a different AS
• Everything else – nothing more than 4%
fifth (20%)
sixth (16%)
3%
How many resolvers see the
query now?
• We observe that this single initial
query generates 1 or more queries
from a single recursive resolver IP
address just 12% of the time
• 2 or more different resolvers are
queried in 30% of cases
• Most of the time (75% of cases)
these multiple resolver IP addresses
are all in the same AS
Cumulative Distribution of number of resolver IP
addresses seen to query for a unique DNS name
when the response is SERVFAIL
Are we there yet?
• No, not really
• Perhaps it is also useful to understand which resolver provides the
response that the user will use
Third Pass
• Single query – same as Pass 1
• But only record the first query at the auth server for each unique ID
• We assume that the first recursive resolver to ask the auth server is the first
to provide a response to the stub resolver
• How does this change the measurements?
First Query Results
• Two-thirds of users direct their queries to
the recursive resolver that is operated by
their ISP
• One fifth (20%) of users have their queries
resolved by Google’s Public DNS resolver
• One sixth (18%) of users direct their
queries to a recursive resolver that is
geolocated to the same country as they
are – probably their ISP using a resolver in
a different AS
• Everything else – nothing more than 4%
seventh (15%)
eighth (1%)
2%
What are we looking at?
• Who gets to see my queries?
• Who might get to see my queries?
• Who do I believe for answers?
Concentration Measurements
• Lets look at the “market” of DNS open resolvers using the “all resolvers”
measurements
• Single Entity Dominance:
• Google has 68.7% of the open DNS resolver market
• Four-Firm Concentration:
• Google, Cloudflare, 114DNS and OpenDNS have 91.6% market share
• HHI Index:
• 49%
• So the open resolver market sector is highly centralized.
• But this open resolver activity represents only one third of the total
resolution market, and the HHI Index of the open resolvers as a subset of
the total resolution market is far lower, at 5%
II Authoritative Servers
• Data about the recursive-to-authoritative query set is hard to find
• Recursive resolvers sit in a privileged position in the DNS as they are exposed
to both the identity of the stub resolver (the ‘user’) and the DNS names that
they are querying
• So there are many caveats that apply to access to such data – and rightly so
• At APNIC we have limited access to the data relating to the use of the
1.1.1.1 recursive resolver
• We don’t know who is querying, but we can see query names and query
protocol
• The market share of Cloudflare’s open resolver service is around 3% of users
which is a non-trivial resolver in the open resolver set (ranked #2 in terms of
market share)
Centrality in Authoritative
Servers?
• One way to measure this is to look at the query-count weighted
ranking of the DNS authoritative server providers
• If an authoritative name server hosts a very popular domain name
then it’s likely that the query count will be high
• If a service operator hosts a large number of domains on its
authoritative server infrastructure, then it’s likely that the query
count will be high
• So lets characterise the authoritative service hosting market by their
query-based ‘market share’
What’s a “query”?
Recursive Resolver Authoritative Server
user
Incoming Query
Cache
Outgoing Query
The query count at this point is dependant on
the cache settings
The query count at this point depends on stub
activity rather than cache settings
We use incoming queries to
determine relative weight
Measurement Technique
• Obtain a data set of 24 hours of query name data from the 1.1.1.1 resolver
system
• Group the query names
• Resolve the names to find the “lowest” authoritative name server for the
query name using a local resolution environment
• Take the first name server name
• Discard the query names
• Resolve the name server names to IP address, and discard the name server
names
• Map the IP addresses to AS numbers, and discard the IP addresses
• Group the query counts into AS numbers and rank by query share
Data Set
Rank AS Number Query Share Cumulative Share Name
56 31034 0.06% 89.64% Aruba, IT
57 20446 0.06% 89.70% Stackpath CDN, US
58 199524 0.06% 89.76% Gcore, LU
59 60068 0.05% 89.82% CDN77, GB
Here’s an extract of the resultant data set
A 24 hour data capture identified 26,971 unique AS numbers (out of a total of 75,000 unique AS numbers
in the routing table)
While approximately one third of networks host at least one queried authoritative name server the top 50
ASNs have 89.2% of the query share.
Cumulative Distribution
Cumulative Distribution
Top 10 Auth Server Networks
Rank AS Number Query Share Cumulative Share Name
1 AS16509 35.7% 35.7% Amazon-02, US
2 AS13335 9.3% 45.0% Cloudflare, US
3 AS15169 8.3% 53.3% Google, US
4 AS21342 4.0% 57.3% Akamai – ASN2, US
5 AS8068 3.9% 61.2% Microsoft, US
6 AS397239 3.7% 64.9% UltraDNS, US
7 AS714 3.4% 68.3% Apple, US
8 AS31898 3.1% 71.4% Oracle, US
9 AS* 2.5% 73.9% Root Server System
10 AS62597 2.5% 76.4% NSONE, US
Concentration Measurements
• Lets look at the “market” of DNS authoritative server providers using
query-weighted ranking
• Single Entity Dominance:
• Amazon has 35.7% of the Authoritative Server market
• Four-Firm Concentration:
• Amazon, Cloudflare, Google, and Akamai have 57.3% market share
• HHI Index:
• 15%
• This appears to be a “moderately concentrated” market
Side note
• What’s that root query volume?
• The root servers report that around 2/3 of the queries seen at the root result
in NXDOMAIN responses
• (Duane Wessels, DNS OARC?? 20??)
• But this data indicates that only 2.5% of queries seen by this recursive
resolver are NXDOMAIN queries
• Why?
Geopolitical Centrality?
• There are 10 network entities who host the authoritative name
servers that have a query share of three quarters of the recursive-to-
authoritative DNS query volume
• All 10 networks are attributed to US entities
Caveats
• The query sample set is not completely uniform and there is a
potential bias to enterprise use and some browser use
• Using query volumes as a proxy for some form of market share is not
a universally accepted analytic metric
Thanks!

More Related Content

Similar to Resolver concentration presentation for OARC 40 by Joao Damas and Geoff Huston

RIPE 82: DNS Evolution
RIPE 82: DNS EvolutionRIPE 82: DNS Evolution
RIPE 82: DNS EvolutionAPNIC
 
DNS in IR: Collection, Analysis and Response
DNS in IR: Collection, Analysis and ResponseDNS in IR: Collection, Analysis and Response
DNS in IR: Collection, Analysis and Responsepm123008
 
How DNS works and How to secure it: An Introduction
How DNS works and How to secure it: An IntroductionHow DNS works and How to secure it: An Introduction
How DNS works and How to secure it: An Introductionyasithbagya1
 
IPv6 and the DNS, RIPE 73
IPv6 and the DNS, RIPE 73IPv6 and the DNS, RIPE 73
IPv6 and the DNS, RIPE 73APNIC
 
2nd ICANN APAC-TWNIC Engagement Forum: DNS Oblivion
2nd ICANN APAC-TWNIC Engagement Forum: DNS Oblivion2nd ICANN APAC-TWNIC Engagement Forum: DNS Oblivion
2nd ICANN APAC-TWNIC Engagement Forum: DNS OblivionAPNIC
 
DNS Measurements
DNS MeasurementsDNS Measurements
DNS MeasurementsAFRINIC
 
DoH vs DoT presentation by Geoff Huston and Joao Damos
DoH vs DoT presentation by Geoff Huston and Joao DamosDoH vs DoT presentation by Geoff Huston and Joao Damos
DoH vs DoT presentation by Geoff Huston and Joao DamosAPNIC
 
Domain Name System and Dynamic Host Configuration Protocol.pptx
Domain Name System and Dynamic Host Configuration Protocol.pptxDomain Name System and Dynamic Host Configuration Protocol.pptx
Domain Name System and Dynamic Host Configuration Protocol.pptxUsmanAhmed269749
 
IGF 2023: DNS Privacy
IGF 2023: DNS PrivacyIGF 2023: DNS Privacy
IGF 2023: DNS PrivacyAPNIC
 
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119APNIC
 
RIPE 86: DNSSEC — Yes or No?
RIPE 86: DNSSEC — Yes or No?RIPE 86: DNSSEC — Yes or No?
RIPE 86: DNSSEC — Yes or No?APNIC
 
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff HustonDNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff HustonAPNIC
 
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]APNIC
 
Presentation on 'The Path to Resolverless DNS' by Geoff Huston
Presentation on 'The Path to Resolverless DNS'  by Geoff HustonPresentation on 'The Path to Resolverless DNS'  by Geoff Huston
Presentation on 'The Path to Resolverless DNS' by Geoff HustonAPNIC
 
IETF 100: A signalling mechanism for trusted keys in the DNS
IETF 100: A signalling mechanism for trusted keys in the DNSIETF 100: A signalling mechanism for trusted keys in the DNS
IETF 100: A signalling mechanism for trusted keys in the DNSAPNIC
 
Measuring the End User
Measuring the End User Measuring the End User
Measuring the End User APNIC
 
NZNOG 2013 - Experiments in DNSSEC
NZNOG 2013 - Experiments in DNSSECNZNOG 2013 - Experiments in DNSSEC
NZNOG 2013 - Experiments in DNSSECAPNIC
 
Measuring the end user
Measuring the end userMeasuring the end user
Measuring the end userAPNIC
 

Similar to Resolver concentration presentation for OARC 40 by Joao Damas and Geoff Huston (20)

RIPE 82: DNS Evolution
RIPE 82: DNS EvolutionRIPE 82: DNS Evolution
RIPE 82: DNS Evolution
 
DNS in IR: Collection, Analysis and Response
DNS in IR: Collection, Analysis and ResponseDNS in IR: Collection, Analysis and Response
DNS in IR: Collection, Analysis and Response
 
DNS
DNSDNS
DNS
 
How DNS works and How to secure it: An Introduction
How DNS works and How to secure it: An IntroductionHow DNS works and How to secure it: An Introduction
How DNS works and How to secure it: An Introduction
 
IPv6 and the DNS, RIPE 73
IPv6 and the DNS, RIPE 73IPv6 and the DNS, RIPE 73
IPv6 and the DNS, RIPE 73
 
2nd ICANN APAC-TWNIC Engagement Forum: DNS Oblivion
2nd ICANN APAC-TWNIC Engagement Forum: DNS Oblivion2nd ICANN APAC-TWNIC Engagement Forum: DNS Oblivion
2nd ICANN APAC-TWNIC Engagement Forum: DNS Oblivion
 
DNS Measurements
DNS MeasurementsDNS Measurements
DNS Measurements
 
DoH vs DoT presentation by Geoff Huston and Joao Damos
DoH vs DoT presentation by Geoff Huston and Joao DamosDoH vs DoT presentation by Geoff Huston and Joao Damos
DoH vs DoT presentation by Geoff Huston and Joao Damos
 
Domain Name System and Dynamic Host Configuration Protocol.pptx
Domain Name System and Dynamic Host Configuration Protocol.pptxDomain Name System and Dynamic Host Configuration Protocol.pptx
Domain Name System and Dynamic Host Configuration Protocol.pptx
 
IGF 2023: DNS Privacy
IGF 2023: DNS PrivacyIGF 2023: DNS Privacy
IGF 2023: DNS Privacy
 
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
 
RIPE 86: DNSSEC — Yes or No?
RIPE 86: DNSSEC — Yes or No?RIPE 86: DNSSEC — Yes or No?
RIPE 86: DNSSEC — Yes or No?
 
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff HustonDNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
 
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
 
Dns
DnsDns
Dns
 
Presentation on 'The Path to Resolverless DNS' by Geoff Huston
Presentation on 'The Path to Resolverless DNS'  by Geoff HustonPresentation on 'The Path to Resolverless DNS'  by Geoff Huston
Presentation on 'The Path to Resolverless DNS' by Geoff Huston
 
IETF 100: A signalling mechanism for trusted keys in the DNS
IETF 100: A signalling mechanism for trusted keys in the DNSIETF 100: A signalling mechanism for trusted keys in the DNS
IETF 100: A signalling mechanism for trusted keys in the DNS
 
Measuring the End User
Measuring the End User Measuring the End User
Measuring the End User
 
NZNOG 2013 - Experiments in DNSSEC
NZNOG 2013 - Experiments in DNSSECNZNOG 2013 - Experiments in DNSSEC
NZNOG 2013 - Experiments in DNSSEC
 
Measuring the end user
Measuring the end userMeasuring the end user
Measuring the end user
 

More from APNIC

APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0APNIC
 
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...APNIC
 
APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53APNIC
 
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024APNIC
 
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...APNIC
 
On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024APNIC
 
Networking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOGNetworking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOGAPNIC
 
IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119APNIC
 
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119APNIC
 
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119APNIC
 
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119APNIC
 
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...APNIC
 
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC
 
NANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff HustonNANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff HustonAPNIC
 
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, ThailandAPAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, ThailandAPNIC
 
Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6APNIC
 
AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!APNIC
 
CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023APNIC
 
AFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet developmentAFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet developmentAPNIC
 
AFNOG 1: Afghanistan IP Deployment Status
AFNOG 1: Afghanistan IP Deployment StatusAFNOG 1: Afghanistan IP Deployment Status
AFNOG 1: Afghanistan IP Deployment StatusAPNIC
 

More from APNIC (20)

APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
 
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
 
APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53
 
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
 
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
 
On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024
 
Networking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOGNetworking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOG
 
IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119
 
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
 
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
 
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
 
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
 
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
 
NANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff HustonNANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff Huston
 
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, ThailandAPAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
 
Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6
 
AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!
 
CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023
 
AFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet developmentAFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet development
 
AFNOG 1: Afghanistan IP Deployment Status
AFNOG 1: Afghanistan IP Deployment StatusAFNOG 1: Afghanistan IP Deployment Status
AFNOG 1: Afghanistan IP Deployment Status
 

Recently uploaded

20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
20240509 QFM015 Engineering Leadership Reading List April 2024.pdf20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
20240509 QFM015 Engineering Leadership Reading List April 2024.pdfMatthew Sinclair
 
20240508 QFM014 Elixir Reading List April 2024.pdf
20240508 QFM014 Elixir Reading List April 2024.pdf20240508 QFM014 Elixir Reading List April 2024.pdf
20240508 QFM014 Elixir Reading List April 2024.pdfMatthew Sinclair
 
一比一原版(Flinders毕业证书)弗林德斯大学毕业证原件一模一样
一比一原版(Flinders毕业证书)弗林德斯大学毕业证原件一模一样一比一原版(Flinders毕业证书)弗林德斯大学毕业证原件一模一样
一比一原版(Flinders毕业证书)弗林德斯大学毕业证原件一模一样ayvbos
 
75539-Cyber Security Challenges PPT.pptx
75539-Cyber Security Challenges PPT.pptx75539-Cyber Security Challenges PPT.pptx
75539-Cyber Security Challenges PPT.pptxAsmae Rabhi
 
PowerDirector Explination Process...pptx
PowerDirector Explination Process...pptxPowerDirector Explination Process...pptx
PowerDirector Explination Process...pptxgalaxypingy
 
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime NagercoilNagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoilmeghakumariji156
 
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...kajalverma014
 
Trump Diapers Over Dems t shirts Sweatshirt
Trump Diapers Over Dems t shirts SweatshirtTrump Diapers Over Dems t shirts Sweatshirt
Trump Diapers Over Dems t shirts Sweatshirtrahman018755
 
Best SEO Services Company in Dallas | Best SEO Agency Dallas
Best SEO Services Company in Dallas | Best SEO Agency DallasBest SEO Services Company in Dallas | Best SEO Agency Dallas
Best SEO Services Company in Dallas | Best SEO Agency DallasDigicorns Technologies
 
pdfcoffee.com_business-ethics-q3m7-pdf-free.pdf
pdfcoffee.com_business-ethics-q3m7-pdf-free.pdfpdfcoffee.com_business-ethics-q3m7-pdf-free.pdf
pdfcoffee.com_business-ethics-q3m7-pdf-free.pdfJOHNBEBONYAP1
 
一比一原版(Offer)康考迪亚大学毕业证学位证靠谱定制
一比一原版(Offer)康考迪亚大学毕业证学位证靠谱定制一比一原版(Offer)康考迪亚大学毕业证学位证靠谱定制
一比一原版(Offer)康考迪亚大学毕业证学位证靠谱定制pxcywzqs
 
Power point inglese - educazione civica di Nuria Iuzzolino
Power point inglese - educazione civica di Nuria IuzzolinoPower point inglese - educazione civica di Nuria Iuzzolino
Power point inglese - educazione civica di Nuria Iuzzolinonuriaiuzzolino1
 
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
2nd Solid Symposium: Solid Pods vs Personal Knowledge GraphsEleniIlkou
 
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrStory Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrHenryBriggs2
 
哪里办理美国迈阿密大学毕业证(本硕)umiami在读证明存档可查
哪里办理美国迈阿密大学毕业证(本硕)umiami在读证明存档可查哪里办理美国迈阿密大学毕业证(本硕)umiami在读证明存档可查
哪里办理美国迈阿密大学毕业证(本硕)umiami在读证明存档可查ydyuyu
 
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac RoomVip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Roommeghakumariji156
 
20240507 QFM013 Machine Intelligence Reading List April 2024.pdf
20240507 QFM013 Machine Intelligence Reading List April 2024.pdf20240507 QFM013 Machine Intelligence Reading List April 2024.pdf
20240507 QFM013 Machine Intelligence Reading List April 2024.pdfMatthew Sinclair
 
在线制作约克大学毕业证(yu毕业证)在读证明认证可查
在线制作约克大学毕业证(yu毕业证)在读证明认证可查在线制作约克大学毕业证(yu毕业证)在读证明认证可查
在线制作约克大学毕业证(yu毕业证)在读证明认证可查ydyuyu
 
Real Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirtReal Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirtrahman018755
 
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查ydyuyu
 

Recently uploaded (20)

20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
20240509 QFM015 Engineering Leadership Reading List April 2024.pdf20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
 
20240508 QFM014 Elixir Reading List April 2024.pdf
20240508 QFM014 Elixir Reading List April 2024.pdf20240508 QFM014 Elixir Reading List April 2024.pdf
20240508 QFM014 Elixir Reading List April 2024.pdf
 
一比一原版(Flinders毕业证书)弗林德斯大学毕业证原件一模一样
一比一原版(Flinders毕业证书)弗林德斯大学毕业证原件一模一样一比一原版(Flinders毕业证书)弗林德斯大学毕业证原件一模一样
一比一原版(Flinders毕业证书)弗林德斯大学毕业证原件一模一样
 
75539-Cyber Security Challenges PPT.pptx
75539-Cyber Security Challenges PPT.pptx75539-Cyber Security Challenges PPT.pptx
75539-Cyber Security Challenges PPT.pptx
 
PowerDirector Explination Process...pptx
PowerDirector Explination Process...pptxPowerDirector Explination Process...pptx
PowerDirector Explination Process...pptx
 
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime NagercoilNagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
 
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
 
Trump Diapers Over Dems t shirts Sweatshirt
Trump Diapers Over Dems t shirts SweatshirtTrump Diapers Over Dems t shirts Sweatshirt
Trump Diapers Over Dems t shirts Sweatshirt
 
Best SEO Services Company in Dallas | Best SEO Agency Dallas
Best SEO Services Company in Dallas | Best SEO Agency DallasBest SEO Services Company in Dallas | Best SEO Agency Dallas
Best SEO Services Company in Dallas | Best SEO Agency Dallas
 
pdfcoffee.com_business-ethics-q3m7-pdf-free.pdf
pdfcoffee.com_business-ethics-q3m7-pdf-free.pdfpdfcoffee.com_business-ethics-q3m7-pdf-free.pdf
pdfcoffee.com_business-ethics-q3m7-pdf-free.pdf
 
一比一原版(Offer)康考迪亚大学毕业证学位证靠谱定制
一比一原版(Offer)康考迪亚大学毕业证学位证靠谱定制一比一原版(Offer)康考迪亚大学毕业证学位证靠谱定制
一比一原版(Offer)康考迪亚大学毕业证学位证靠谱定制
 
Power point inglese - educazione civica di Nuria Iuzzolino
Power point inglese - educazione civica di Nuria IuzzolinoPower point inglese - educazione civica di Nuria Iuzzolino
Power point inglese - educazione civica di Nuria Iuzzolino
 
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
 
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrStory Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
 
哪里办理美国迈阿密大学毕业证(本硕)umiami在读证明存档可查
哪里办理美国迈阿密大学毕业证(本硕)umiami在读证明存档可查哪里办理美国迈阿密大学毕业证(本硕)umiami在读证明存档可查
哪里办理美国迈阿密大学毕业证(本硕)umiami在读证明存档可查
 
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac RoomVip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
 
20240507 QFM013 Machine Intelligence Reading List April 2024.pdf
20240507 QFM013 Machine Intelligence Reading List April 2024.pdf20240507 QFM013 Machine Intelligence Reading List April 2024.pdf
20240507 QFM013 Machine Intelligence Reading List April 2024.pdf
 
在线制作约克大学毕业证(yu毕业证)在读证明认证可查
在线制作约克大学毕业证(yu毕业证)在读证明认证可查在线制作约克大学毕业证(yu毕业证)在读证明认证可查
在线制作约克大学毕业证(yu毕业证)在读证明认证可查
 
Real Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirtReal Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirt
 
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
 

Resolver concentration presentation for OARC 40 by Joao Damas and Geoff Huston

  • 1. Measuring the Centralization of DNS Resolution Geoff Huston, Joao Damas, APNIC Labs
  • 2. What are we talking about? • The DNS is a highly decentralised database that distributes its contents over much of the Internet • The DNS data model also includes information replication (secondary authoritative servers) that attempts to provide resiliency and scalability by removing critical single choke points within the database • The DNS name resolution protocol includes query fallback to increase the robustness of name resolution • It all sounds as if the DNS highly diverse and extensively decentralised.
  • 3. What are we talking about? • The DNS is a highly decentralised database that distributes its contents over much of the Internet • The DNS data model also includes information replication (secondary authoritative servers) that attempts to provide resiliency ands scalability by removing critical single choke points within the database • The DNS name resolution protocol includes query fallback to increase the robustness of name centralisation • It all sounds as if the DNS highly diverse and extensively decentralised. But is it really decentralised?
  • 4. Measuring Centrality • Various measures have been used in the related space of market dominance which appear to have some relevance to the study of market dominance in the DNS • Australia’s Consumer and Competition agency uses a metric of 70% market share by a single entity • Or there is the four-firm concentration ratio which uses the market share of the four largest firms • Or there is the Hirfindahl-Hirschman index
  • 5. Herfindahl-Hirschman Index • The HHI is used in market analysis to indicate the level of competition between market entities. It is the average market share of the market, weighted by market share • Sum of the square of the market share (%) of the top 50 entities • Above 25% is often taken as an indicator of market skew • Above 10% is would be considered as a market showing “moderate concentration”
  • 6. The DNS resolution environment • The question of centrality in the DNS resolution environment is equivalent to the questions of market dominance and market concentration • So lets look at DNS resolution as a market and use these measurements to assess the degree of concentration in the supply of DNS resolution services
  • 7. Looking at concentration in DNS Name Resolution Recursive Resolver Authoritative Server user I. How centralized is the recursive resolver function? II. How centralized is the authoritative server function? Stub-to-Recursive Recursive-to-Authoritative
  • 9. Measuring Recursive Resolution We use Ads to send each user a unique DNS name to resolve. We use an authoritative server as the data collection point and collect the IP address of the resolvers asking the authoritative server We then use the Ad presentation data to match this query to an end user IP address Recursive Resolver Authoritative Server user Ad placement data <ID, IPaddr> DNS query data <ID, DNS resolver IPaddr> Measurement
  • 10. Tuning the measurement • The Authoritative Server always answers queries immediately with the A / AAAA records as requested • The data is unsigned and the responses fit comfortably within 512 octets of DNS payload • We try to minimise timeouts and requeries by steering users to a DNS Authoritative server that is (roughly) on the same continent as the user
  • 11. Mapping • We need to map the resolver “helper” addresses to a resolver service • Which back-end DNS addresses are used by each open resolver? • RIPE Atlas helped here for those cases where the open resolver operator does not publish this information • We map resolvers into a number of categories based on the resolver’s IP address. The categories we use: • Resolver is in the same AS as the end user • It’s a known Open DNS resolver • Resolver is geo-located to the same CC as the end user • Resolver is geo-located to a different CC from the end user
  • 12. Results June 2020 October 2022 Same AS Google Same CC Cloudflare Others
  • 13. Results • Two-thirds of users direct their queries to the recursive resolver that is operated by their ISP • One seventh (15%) of users have their queries resolved by Google’s Public DNS resolver • One seventh (15%) of users direct their queries to a recursive resolver that is geolocated to the same country as they are – probably their ISP using a resolver in a different AS • Everything else – nothing more than 3% • Is the recursive resolver market centralized? Probably not • Is the open recursive resolver market centralized? That’s a different question! • But first let’s understand what is being measured here
  • 14. However, the measurement is not as simple as it may suggest • We observe that this single initial query generates 1 or more queries from a single recursive resolver IP address just 30% of the time • 2 or more different resolvers are queried in 60% of cases • Most of the time (90% of cases) these multiple resolver IP addresses are all in the same AS Cumulative Distribution of number of resolver IP addresses seen to query for a unique DNS name
  • 15. Multiple resolvers “see” individual stub queries • We see an average of 3.23 distinct resolver IP addresses at the authoritative server for each queried domain name within the first 15 seconds • What should we do with these “extra” DNS queries? • In this case we just add them to the count • So we are measuring who “sees” my DNS queries
  • 16. What are we measuring here? • So we thought that maybe we really wanted to know all the resolvers who might see your query • But to flush out all of these resolvers we need to adjust this experiment
  • 17. Seeing Everything! • Get the authoritative server to return SERVFAIL all the time • This way the stub resolver is likely to cycle through all the locally configured recursive resolvers to find a non-SERVFAIL DNS response
  • 18. All Recursive Resolvers • Two-thirds of users direct their queries to the recursive resolver that is operated by their ISP • One seventh (15%) of users have their queries resolved by Google’s Public DNS resolver • One seventh (15%) of users direct their queries to a recursive resolver that is geolocated to the same country as they are – probably their ISP using a resolver in a different AS • Everything else – nothing more than 4% fifth (20%) sixth (16%) 3%
  • 19. How many resolvers see the query now? • We observe that this single initial query generates 1 or more queries from a single recursive resolver IP address just 12% of the time • 2 or more different resolvers are queried in 30% of cases • Most of the time (75% of cases) these multiple resolver IP addresses are all in the same AS Cumulative Distribution of number of resolver IP addresses seen to query for a unique DNS name when the response is SERVFAIL
  • 20. Are we there yet? • No, not really • Perhaps it is also useful to understand which resolver provides the response that the user will use
  • 21. Third Pass • Single query – same as Pass 1 • But only record the first query at the auth server for each unique ID • We assume that the first recursive resolver to ask the auth server is the first to provide a response to the stub resolver • How does this change the measurements?
  • 22. First Query Results • Two-thirds of users direct their queries to the recursive resolver that is operated by their ISP • One fifth (20%) of users have their queries resolved by Google’s Public DNS resolver • One sixth (18%) of users direct their queries to a recursive resolver that is geolocated to the same country as they are – probably their ISP using a resolver in a different AS • Everything else – nothing more than 4% seventh (15%) eighth (1%) 2%
  • 23. What are we looking at? • Who gets to see my queries? • Who might get to see my queries? • Who do I believe for answers?
  • 24. Concentration Measurements • Lets look at the “market” of DNS open resolvers using the “all resolvers” measurements • Single Entity Dominance: • Google has 68.7% of the open DNS resolver market • Four-Firm Concentration: • Google, Cloudflare, 114DNS and OpenDNS have 91.6% market share • HHI Index: • 49% • So the open resolver market sector is highly centralized. • But this open resolver activity represents only one third of the total resolution market, and the HHI Index of the open resolvers as a subset of the total resolution market is far lower, at 5%
  • 25. II Authoritative Servers • Data about the recursive-to-authoritative query set is hard to find • Recursive resolvers sit in a privileged position in the DNS as they are exposed to both the identity of the stub resolver (the ‘user’) and the DNS names that they are querying • So there are many caveats that apply to access to such data – and rightly so • At APNIC we have limited access to the data relating to the use of the 1.1.1.1 recursive resolver • We don’t know who is querying, but we can see query names and query protocol • The market share of Cloudflare’s open resolver service is around 3% of users which is a non-trivial resolver in the open resolver set (ranked #2 in terms of market share)
  • 26. Centrality in Authoritative Servers? • One way to measure this is to look at the query-count weighted ranking of the DNS authoritative server providers • If an authoritative name server hosts a very popular domain name then it’s likely that the query count will be high • If a service operator hosts a large number of domains on its authoritative server infrastructure, then it’s likely that the query count will be high • So lets characterise the authoritative service hosting market by their query-based ‘market share’
  • 27. What’s a “query”? Recursive Resolver Authoritative Server user Incoming Query Cache Outgoing Query The query count at this point is dependant on the cache settings The query count at this point depends on stub activity rather than cache settings We use incoming queries to determine relative weight
  • 28. Measurement Technique • Obtain a data set of 24 hours of query name data from the 1.1.1.1 resolver system • Group the query names • Resolve the names to find the “lowest” authoritative name server for the query name using a local resolution environment • Take the first name server name • Discard the query names • Resolve the name server names to IP address, and discard the name server names • Map the IP addresses to AS numbers, and discard the IP addresses • Group the query counts into AS numbers and rank by query share
  • 29. Data Set Rank AS Number Query Share Cumulative Share Name 56 31034 0.06% 89.64% Aruba, IT 57 20446 0.06% 89.70% Stackpath CDN, US 58 199524 0.06% 89.76% Gcore, LU 59 60068 0.05% 89.82% CDN77, GB Here’s an extract of the resultant data set A 24 hour data capture identified 26,971 unique AS numbers (out of a total of 75,000 unique AS numbers in the routing table) While approximately one third of networks host at least one queried authoritative name server the top 50 ASNs have 89.2% of the query share.
  • 32. Top 10 Auth Server Networks Rank AS Number Query Share Cumulative Share Name 1 AS16509 35.7% 35.7% Amazon-02, US 2 AS13335 9.3% 45.0% Cloudflare, US 3 AS15169 8.3% 53.3% Google, US 4 AS21342 4.0% 57.3% Akamai – ASN2, US 5 AS8068 3.9% 61.2% Microsoft, US 6 AS397239 3.7% 64.9% UltraDNS, US 7 AS714 3.4% 68.3% Apple, US 8 AS31898 3.1% 71.4% Oracle, US 9 AS* 2.5% 73.9% Root Server System 10 AS62597 2.5% 76.4% NSONE, US
  • 33. Concentration Measurements • Lets look at the “market” of DNS authoritative server providers using query-weighted ranking • Single Entity Dominance: • Amazon has 35.7% of the Authoritative Server market • Four-Firm Concentration: • Amazon, Cloudflare, Google, and Akamai have 57.3% market share • HHI Index: • 15% • This appears to be a “moderately concentrated” market
  • 34. Side note • What’s that root query volume? • The root servers report that around 2/3 of the queries seen at the root result in NXDOMAIN responses • (Duane Wessels, DNS OARC?? 20??) • But this data indicates that only 2.5% of queries seen by this recursive resolver are NXDOMAIN queries • Why?
  • 35. Geopolitical Centrality? • There are 10 network entities who host the authoritative name servers that have a query share of three quarters of the recursive-to- authoritative DNS query volume • All 10 networks are attributed to US entities
  • 36. Caveats • The query sample set is not completely uniform and there is a potential bias to enterprise use and some browser use • Using query volumes as a proxy for some form of market share is not a universally accepted analytic metric