Measuring

the DNS from

the Users perspec7ve
Geoff Huston
APNIC Labs,
May 2014

Whats the ques7on?

How many users can do <x> with the DNS?

How many users can retrieve a URL using IPv6?
How many users perform DNSSEC valida7on when
they resolve a domain name?
How many users are capable of resolving a name via
DNS over TCP?
How many users follow DNAME chains in the DNS?
etc

Users vs Infrastructure
We oNen measure the network by observing
infrastructure and inferring end user behaviour
because its oNen easier to instrument infrastructure

This approach is aimed at measuring an aspect of

of behaviour within par7cular parameters of the
network infrastructure, but it does not
encompass how the end user assembles a
coherent view of the network

For exampleDNSSEC
We can walk zone les and count the number of
signed zones
Or we could analyze the log les of authorita7ve
name servers for a signed zone and aVempt to
infer something about the number of users who
use DNSSEC to validate DNS responses
But can these sort of approaches measure the
popula7on of end users who are served by
DNSSEC-valida7ng resolvers?

How to measure a million end users

How to measure a million end users

Be Google (or any other massively popular
web service provider)

How to measure a million end users

Be Google (or any other massively popular
web service provider)
or

How to measure a million end users

Be Google (or any other massively popular
web service provider)
or

Get your code to run on a million users
machines through another delivery channel

Ads are ubiquitous

Ads are ubiquitous

Ads are ubiquitous

Ads are implemented in Adobe Flash

Flash includes primi7ves in ac7onscript to
fetch network assets
Typically used to load alternate images, sequences
Not a generalized network stack, subject to
constraints:
Port 80
crossdomain.xml on hos7ng site must match source
name (wildcard syntax)

Flash has asynchronous threads model for

event driven, sprite anima7on

APNICs measurement technique

CraN ash/ac7onscript which fetches network assets to
measure when the ad is displayed
Web Assets are reduced to a no7onal 1x1 image which is
not added to the DOM and is not displayed
Assets can be named to cause specic DNS resolu7on via
local gethostbyname() styled API within the browsers Flash
engine
Encode data transfer in the name of fetched assets
Use the DNS as the informa7on conduit:

Result is returned by DNS name with wildcard

Use HTTP as the informa7on conduit

Result is returned via parameters aVached to an HTTP GET command

Adver7sing placement logic

Fresh Eyeballs == Unique IPs

We have good evidence the adver7sing channel is able to

sustain a constant supply of unique IP addresses

Pay by click, or pay by impression

If you select a preference for impressions, then the channel

tries hard to present your ad to as many unique IPs as possible

Time/Loca7on/Context tuned

Can select for 7me of day, physical loca7on or keyword

contexts (for search-related ads)
But if you dont select, then placement is generalized

Aim to ll budget

If you request $100 of placement a day, then inside 24h

algorithm tries hard to even placement but in the end, will
soak place your ad to achieve enough views, to bill you $100

Adver7sing placement logic

Budget: $100 per day, at $1.00 CPM max
Clicks per millepressions: aim to pay no more than
$1 per click but pay up to $1 for a thousand
impressions

Even distribu7on of ads throughout the day

No constraint on loca7on, 7me
Outcome: 350,000 placements per day, on a
mostly even placement model with end of day
soak to achieve budget goal

Ad Placement Training Day 1

5000

22/Mar

4000

3000

2000

1000

0
00:00

02:00

04:00

06:00

08:00

10:00

12:00

14:00

16:00

18:00

20:00

22:00

16

00:00

Ad Placement Training Day 2

5000

22/Mar
23/Mar

4000

3000

2000

1000

0
00:00

02:00

04:00

06:00

08:00

10:00

12:00

14:00

16:00

18:00

20:00

22:00

17

00:00

Ad Placement Training Day 3

5000

22/Mar
23/Mar
24/Mar

4000

3000

2000

1000

0
00:00

02:00

04:00

06:00

08:00

10:00

12:00

14:00

16:00

18:00

20:00

22:00

18

00:00

Ad Placement Training Day 4

5000

22/Mar
23/Mar
24/Mar
25/Mar

4000

3000

2000

1000

0
00:00

02:00

04:00

06:00

08:00

10:00

12:00

14:00

16:00

18:00

20:00

22:00

19

00:00

Ad Placement Training Days 5, 6 & 7

5000

23/Mar
24/Mar
25/Mar
26/Mar
27/Mar
28/Mar
29/Mar
30/Mar
31/Mar
01/Apr

4000

3000

2000

1000

0
00:00

02:00

04:00

06:00

08:00

10:00

12:00

14:00

16:00

18:00

20:00

22:00

20

00:00

Measurement Control Channel

Use Flash code that is executed on ad impression that
retrieves the actual measurement script

Ad carries code to send the client to retrieve an ad-controller

URL
hVp://drongo.rand.apnic.net/measureipv6id.cgi?advertID=9999

Client retrieves set of tests from the ad-controller as a

sequence of URLs to fetch and a result URL to use to pass the
results to the ad-server

This allows us to vary the measurement experiment

without necessarily altering the ad campaign itself the ad,
and its approval to run, remain unchanged so that
measurements can be ac7vated and deac7vated in real
7me.

Experiment Server cong

There are currently three servers, iden7cally
congured (US, Europe, Australia)
Server runs Bind, Apache and tcpdump
Experiment directs the client to the closest
server (to reduce rV-related 7meouts) based
on simple /8 map of client address to region

Collected Data
Per Server, Per Day:
hVp-access log
(successfully completed fetches)

dns.log
(incoming DNS queries)

Packet capture
All packets

Caching
Caching (generally) defeats the intent of the
measurement

Although some measurements are intended to measure

the eects of caching

We use unique DNS labels and unique URL GET

parameters

Ensures that all DNS resolu7on requests and HTTP fetch

requests end up at the experiments servers

We use a common tag across all URLs in a single

experiment

Allows us to join the individual fetches to create the per-

user view of capability

What does this allow?

In providing an end user with a set of URLs to
retrieve we can examine:
Protocol behaviour
e.g.: V4 vs V6, protocol performance, connec7on failure
rate

DNS behaviours
e.g.: DNSSEC use, DNS resolu7on performance

The generic approach

Seed a user with a set of tasks that cause
iden7able trac at an instrumented server
The user does not contribute measurements
The server performs the data collec7on

Measuring IPv6 via Ads

Client is given 5 URLs to load:
Dual Stack object
V4-only object
V6-only object
V6 literal address (no DNS needed)
Result repor7ng URL (10 second 7mer)
All DNS is dual stack

Discovering Rou7ng Filters via Ads

Client is given 3 URLs to load:
DNS name that resolves into the test prex
DNS name the resolves to a control prex
Result repor7ng URL (10 second 7mer)

Measuring DNSSEC via Ads

Client is given 4 URLs to load:

DNSSEC-validly signed DNS name

DNSSEC-invalidly signed DNS name
Unsigned DNS name (control)
Result repor7ng URL (10 second 7mer)

The DNSSEC Experiment

Three URLs:
the good (DNSSEC signed)
the bad (invalid DNSSEC signature)
the control (no DNSSEC at all)

And an online ad system to deliver the test to a
large pseudo-random set of clients

On to Some Results
December 2013
Presented: 5,683,295 experiments
Reported: 4,978,929 experiments that ran to comple7on
Web + DNS query log results for clients:
Performed DNSSEC signature valida7on and did not fetch the
invalidly signed object: 6.8%
Fetched DNSSEC RRs, but then retrieved the invalidly signed
object anyway: 4.7%
Did not have a DNSSEC clue at all - only fetched A RRs: 88.5%

That means
That 6.8% of clients appear to be performing
DNSSEC valida7on and not resolving DNS names
when the DNSSEC signature cannot be validated

A further 4.7% of clients are using a mix of
valida7ng and non-valida7ng resolvers, and in
the case of a valida7on failure turn to a non-
valida7ng resolver!

Where is DNSSEC? The Top 20

Rank CC&Code

Tests Validating& Mixed&

(%)
(%)
1
YE
2,279
70.8% 11.2%
2
SE
5,983
67.2%
4.6%
3
SI
5,883
51.0%
6.1%
4
EE
2,132
44.7%
4.4%
% of clients
w
5
VNho 114,996
42.4% 11.8%
41.0%
3.4%
appear 6to use FIonly 3,556
7
CZ
10,468
30.8%
8.4%
DNSSEC-valida@ng
8
LU
1,204
29.8% 11.6%
resolvers
9
TH
110,380
26.8%
8.6%
10
CL
21,167
26.6%
2.8%
11
ZA
12,398
26.2%
5.8%
%
o
f
c
lients
w
ho
u
se
a
12
UA
32,916
25.0%
9.8%
13
ID
89,331
mix of 22.0%
DNSSEC-9.8%
14
IE
7,679
20.7%
3.0%
valida@ng
resolvers
15
TZ
1,724
20.7% 15.6%
and non-valida@ng
16
CO
25,440
20.3%
6.5%
resolvers
17
DZ
16,198
19.1% 37.5%
18
PS
8,441
18.5% 28.3%
19
AZ
5,095
18.2% 18.4%
20
US
311,740
15.2%
3.5%
XA
5,331,072
6.7%
4.8%

None&
(%)
18.0% Yemen/
28.2% Sweden/
42.9% Slovenia/
50.9% Estonia/
45.8% Vietnam
55.6% Finland/
60.9% % o
Czech/Republic
f clients who use
58.6% Luxembourg/
non-valida@ng
64.7% Thailand/
resolvers
70.7% Chile/
68.0% South/Africa
65.2% Ukraine/
68.2% Indonesia/
76.3% Ireland/
63.8% Tanzania
73.3% Colombia/
43.4% Algeria/
53.2% Occupied/Palestinian/T.
63.4% Azerbaijan/
81.3% United/States/of/America
88.5% World

Geo-locate clients to countries, and select countries with more than 1,000
data points

Where is DNSSEC? The Top 20

Rank CC&Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

YE
SE
SI
EE
VN
FI
CZ
LU
TH
CL
ZA
UA
ID
IE
TZ
CO
DZ
PS
AZ
US
XA

Tests Validating& Mixed& None&

(%)
(%)
(%)
2,279
70.8% 11.2% 18.0%
5,983
67.2%
4.6% 28.2%
5,883
51.0%
6.1% 42.9%
2,132
44.7%
4.4% 50.9%
114,996
42.4% 11.8% 45.8%
3,556
41.0%
3.4% 55.6%
10,468
30.8%
8.4% 60.9%
1,204
29.8% 11.6% 58.6%
110,380
26.8%
8.6% 64.7%
21,167
26.6%
2.8% 70.7%
12,398
26.2%
5.8% 68.0%
32,916
25.0%
9.8% 65.2%
89,331
22.0%
9.8% 68.2%
7,679
20.7%
3.0% 76.3%
1,724
20.7% 15.6% 63.8%
25,440
20.3%
6.5% 73.3%
16,198
19.1% 37.5% 43.4%
8,441
18.5% 28.3% 53.2%
5,095
18.2% 18.4% 63.4%
311,740
15.2%
3.5% 81.3%
5,331,072
6.7%
4.8% 88.5%

Yemen/
Sweden/
Slovenia/
Estonia/
Vietnam
Finland/
Czech/Republic
Luxembourg/
Thailand/
Chile/
South/Africa
Ukraine/
Indonesia/
Ireland/
Tanzania
Colombia/
Algeria/
Occupied/Palestinian/T.
Azerbaijan/
United/States/of/America
World

Geo-locate clients to countries, and select countries with more than 1,000
data points

Where is DNSSEC? The boVom 20

Rank CC&Code
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

CN
SA
MD
FR
NZ
BE
PR
LT
SG
BS
HR
OM
TT
ME
LV
PT
MU
BH
AE
JO
QA
KR
XA

Tests
1,215,241
45,243
3,168
86,888
31,683
15,243
3,521
14,984
36,420
1,158
8,856
6,147
2,497
3,552
2,041
17,641
3,452
4,231
47,996
10,527
15,975
668,885
5,331,072

Validating& Mixed& None&

(%)
(%)
(%)
1.9%
2.1% 96.0%
1.7%
2.1% 96.2%
1.6%
1.9% 96.5%
1.6%
1.0% 97.4%
1.6% 15.0% 83.4%
1.5%
3.8% 94.7%
1.5% 13.0% 85.5%
1.4%
1.7% 96.9%
1.4%
4.8% 93.8%
1.4%
2.7% 95.9%
1.4%
1.2% 97.5%
1.3%
2.0% 96.7%
1.3%
3.4% 95.3%
1.3%
3.5% 95.3%
1.2%
3.3% 95.4%
1.2%
2.0% 96.8%
1.1%
1.7% 97.2%
1.1%
5.7% 93.2%
1.0%
1.0% 98.0%
0.9%
1.3% 97.9%
0.4%
0.8% 98.8%
0.3%
0.4% 99.3%
6.7%
4.8% 88.5%

China2
Saudi2Arabia
Republic2of2Moldova
France2
New2Zealand
Belgium2
Puerto2Rico
Lithuania2
Singapore2
Bahamas2
Croatia2
Oman2
Trinidad2and2Tobago
Montenegro
Latvia2
Portugal2
Mauritius
Bahrain2
United2Arab2Emirates
Jordan2
Qatar2
Republic2of2Korea
World

Geo-locate clients to countries, and select countries with more than 1,000
data points

Most importantly
Rank CC&Code

Tests

Validating

Mixed

None

Country
Australia&

35

AU

22,173

10.72

2.68

86.6

101

NZ

31,683

1.57

15.04

83.39

New&Zealand

The Mapped view of DNSSEC Use

Frac7on of users who use

DNSSEC-valida7ng resolvers
hVp://gronggrong.rand.apnic.net/cgi-bin/worldmap (May 2014)

Why
is it that 7% of users performing DNSSEC valida7on is
about 3 7mes the number of users who are capable of
using IPv6?

has DNSSEC deployment been so successful compared
to IPv6?

Is Googles P-DNS a Factor?

Another observa7on from the data

Clients who used Googles Public DNS servers: 10.4%
Exclusively Used Googles P-DNS: 5.4%
Used a mix of Googles P-DNS and other resolvers: 5.0%

Is Googles P-DNS a Factor?

DNSSEC&Validation&
Google&Public&DNS
Rank CC&Code
Tests Validating
All& Mixed
None
1
YE
2,279
70.8%
6.5%
5.0% 88.5% Yemen1
2
SE
5,983
67.2%
2.1%
0.4% 97.5% Sweden1
3
SI
5,883
51.0%
5.0%
0.4% 94.7% Slovenia1
%
o
f
v
alida@ng
4
EE
2,132
44.7%
4.2%
1.1% 94.8% Estonia1
5
VN
42.4%
98.7%
1.3%
0.1% Vietnam
clients 114,996
who
6
FI
3,556
2.1%
0.8% 97.1% Finland1
exclusively
use 41.0%
% oCzech1Republic
f clients who do not
7
CZ
10,468
30.8%
13.8%
6.5% 79.7%
Googles
P
-DNS
8
LU
1,204
29.8%
15.9%
0.8% 83.3% use
Luxembourg1
Googles P-DNS
9
TH
110,380
26.8%
15.9%
5.9% 78.3% Thailand1
10
CL
21,167
26.6%
6.2%
0.4% 93.4% Chile1 service
11
ZA
12,398
26.2%
8.0%
3.0% 89.0% South1Africa
12
UA
32,916% of 25.0%
20.1%
clients w
ho use 3.0%
a 76.9% Ukraine1
13
ID
89,331
22.0%
72.2%
8.1% 19.8% Indonesia1
mix
o
f
G
oogles
P
-DNS
14
IE
7,679
20.7%
17.0%
1.1% 81.9% Ireland1
15
TZ
1,724 and
20.7%
5.1%
0.6% Tanzania
other r94.4%
esolvers
16
CO
25,440
20.3%
12.7%
1.5% 85.8% Colombia1
17
DZ
16,198
19.1%
71.2% 27.7%
1.1% Algeria1
18
PS
8,441
18.5%
51.8% 29.2% 19.0% Occupied1Palestinian1T.
19
AZ
5,095
18.2%
68.5%
9.6% 21.9% Azerbaijan1
20
US
311,740
15.2%
10.6%
2.9% 86.4% United1States1of1America
XA
5,331,072
6.7%
50.2%
7.3% 42.5% World

Of those clients who perform DNSSEC valida@on, what resolvers

are they using: All Google P-DNS? Some Google P-DNS? No Google P-
DNS?

Is Googles P-DNS a Factor?

DNSSEC&Validation&
Rank CC&Code
Tests Validating
1
YE
2,279
70.8%
2
SE
5,983
67.2%
3
SI
5,883
51.0%
4
EE
2,132
44.7%
5
VN
114,996
42.4%
6
FI
3,556
41.0%
7
CZ
10,468
30.8%
8
LU
1,204
29.8%
9
TH
110,380
26.8%
10
CL
21,167
26.6%
11
ZA
12,398
26.2%
12
UA
32,916
25.0%
13
ID
89,331
22.0%
14
IE
7,679
20.7%
15
TZ
1,724
20.7%
16
CO
25,440
20.3%
17
DZ
16,198
19.1%
18
PS
8,441
18.5%
19
AZ
5,095
18.2%
20
US
311,740
15.2%
XA
5,331,072
6.7%

Google&Public&DNS
All& Mixed
None
6.5%
5.0% 88.5%
2.1%
0.4% 97.5%
5.0%
0.4% 94.7%
4.2%
1.1% 94.8%
98.7%
1.3%
0.1%
2.1%
0.8% 97.1%
13.8%
6.5% 79.7%
15.9%
0.8% 83.3%
15.9%
5.9% 78.3%
6.2%
0.4% 93.4%
8.0%
3.0% 89.0%
20.1%
3.0% 76.9%
72.2%
8.1% 19.8%
17.0%
1.1% 81.9%
94.4%
5.1%
0.6%
12.7%
1.5% 85.8%
71.2% 27.7%
1.1%
51.8% 29.2% 19.0%
68.5%
9.6% 21.9%
10.6%
2.9% 86.4%
50.2%
7.3% 42.5%

Yemen1
Sweden1
Slovenia1
Estonia1
Vietnam
Finland1
Czech1Republic
Luxembourg1
Thailand1
Chile1
South1Africa
Ukraine1
Indonesia1
Ireland1
Tanzania
Colombia1
Algeria1
Occupied1Palestinian1T.
Azerbaijan1
United1States1of1America
World

Of those clients who perform DNSSEC valida@on, what resolvers

are they using: All Google P-DNS? Some Google P-DNS? No Google P-
DNS?

Is Googles P-DNS a Factor?

DNSSEC&Validation&
Rank CC&Code
Tests Validating
1
YE
2,279
70.8%
2
SE
5,983
67.2%
3
SI
5,883
51.0%
4
EE
2,132
44.7%
5
VN
114,996
42.4%
6
FI
3,556
41.0%
7
CZ
10,468
30.8%
8
LU
1,204
29.8%
9
TH
110,380
26.8%
10
CL
21,167
26.6%
11
ZA
12,398
26.2%
12
UA
32,916
25.0%
13
ID
89,331
22.0%
14
IE
7,679
20.7%
15
TZ
1,724
20.7%
16
CO
25,440
20.3%
17
DZ
16,198
19.1%
18
PS
8,441
18.5%
19
AZ
5,095
18.2%
20
US
311,740
15.2%
XA
5,331,072
6.7%

Google&Public&DNS
All& Mixed
None
6.5%
5.0% 88.5%
2.1%
0.4% 97.5%
5.0%
0.4% 94.7%
4.2%
1.1% 94.8%
98.7%
1.3%
0.1%
2.1%
0.8% 97.1%
13.8%
6.5% 79.7%
15.9%
0.8% 83.3%
15.9%
5.9% 78.3%
6.2%
0.4% 93.4%
8.0%
3.0% 89.0%
20.1%
3.0% 76.9%
72.2%
8.1% 19.8%
17.0%
1.1% 81.9%
94.4%
5.1%
0.6%
12.7%
1.5% 85.8%
71.2% 27.7%
1.1%
51.8% 29.2% 19.0%
68.5%
9.6% 21.9%
10.6%
2.9% 86.4%
50.2%
7.3% 42.5%

Yemen1
Sweden1
Slovenia1
Estonia1
Vietnam
Finland1
Czech1Republic
Luxembourg1
Thailand1
Chile1
South1Africa
Ukraine1
Indonesia1
Ireland1
Tanzania
Colombia1
Algeria1
Occupied1Palestinian1T.
Azerbaijan1
United1States1of1America
World

Of those clients who perform DNSSEC valida@on, what resolvers

are they using: All Google P-DNS? Some Google P-DNS? No Google P-
DNS?

DNSSEC by Networks the Top 25

Rank
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

ASN Tests
AS22047
AS16232
AS37457
AS39651
AS12912
AS29562
AS23944
AS45629
AS45758
AS36925
AS7679
AS6849
AS34779
AS198471
AS5466
AS28220
AS5610
AS5603
AS7922
AS51737
AS3249
AS5645
AS1257
AS719
AS1759

DNSSEC&Validation
Validating Mixed None

Google&P3DNS
All Mixed None

5,376
1,818
2,051
860
613
1,263
749
8,759
15,833
1,012
551
6,301
1,043
722
1,463
563
2,094
1,505
43,438
753
1,093
1,993
880
655
1,080

98%
98%
97%
97%
96%
95%
94%
94%
93%
93%
93%
92%
91%
91%
90%
89%
88%
88%
87%
87%
84%
83%
83%
82%
82%

1%
1%
1%
1%
1%
1%
1%
3%
4%
2%
1%
3%
3%
4%
3%
2%
3%
3%
3%
9%
5%
2%
1%
2%
4%

1%
1%
2%
2%
2%
4%
5%
4%
3%
5%
6%
5%
6%
6%
6%
9%
9%
9%
9%
4%
10%
14%
16%
16%
15%

1%
2%
1%
1%
2%
2%
3%
1%
0%
25%
1%
5%
2%
95%
3%
5%
6%
0%
3%
97%
3%
3%
1%
2%
0%

5,331,072

7%

5%

88%

5%

% of clients who
appear to use
DNSSEC-valida@ng
resolvers

% of clients who use a

mix of DNSSEC-
valida@ng resolvers
and non-valida@ng
resolvers

% of clients who do
not use Googles P-
DNS

0%
0%
0%
1%
0%
1%
1%
1%
2%
1%
0%
3%
0%
2%
1%
1%
7%
1%
1%
2%
1%
0%
1%
2%
0%

99%
98%
99%
98%
98%
97%
96%
97%
98%
74%
99%
92%
98%
4%
97%
94%
87%
99%
96%
1%
97%
96%
99%
96%
99%

VTR2BANDA2ANCHA2S.A.,2CL,2Chile2
ASN>TIM2TIM2(Telecom2Italia2Mobile)2Autonomous2System,2IT,2Italy2
Telkom>Internet,2ZA,2South2Africa
COMHEM>SWEDEN2Com2Hem2Sweden,2SE,2Sweden2
ERA2Polska2Telefonia2Cyfrowa2S.A.,2PL,2Poland2
KABELBW>ASN2Kabel2BW2GmbH,2DE,2Germany2
SKYBB>AS>AP2AS>SKYBroadband2SKYCable2Corporation,2PH,2Philippines2
JASTEL>NETWORK>TH>AP2JasTel2Network2International2Gateway,2TH,2Thailand2
TRIPLETNET>AS>AP2TripleT2Internet2Internet2service2provider2Bangkok,2TH,2Thailand2
ASMedi,2MA,2Morocco2
QTNET2Kyushu2Telecommunication2Network2Co.,2Inc.,2JP
UKRTELNET2JSC2UKRTELECOM,2,2UA
T>2>AS2T>2,22d.o.o.,2SI
LINKEM>AS2Linkem2spa,2IT,2Italy2
EIRCOM2Eircom2Limited,2IE,2Ireland2
CABO2SERVICOS2DE2TELECOMUNICACOES2LTDA,2BR,2Brazil2
TO2>CZECH>REPUBLIC2Telefonica2Czech2Republic,22a.s.,2CZ
SIOL>NET2Telekom2Slovenije2d.d.,2SI,2Slovenia2
COMCAST>79222>2Comcast2Cable2Communications,22Inc.,2US
SUPERLINK>AS2SuperLink2Communications2Co,2PS,2Occupied2Palestinian2Territory
ESTPAK2Elion2Enterprises2Ltd.,2EE,2Estonia2
TEKSAVVY>TOR2TekSavvy2Solutions2Inc.2Toronto,2CA,2Canada2
TELE2,2SE,2Sweden2
ELISA>AS2Elisa2Oyj,2FI,2Finland2
TSF>IP>CORE2TeliaSonera2Finland2IP2Network,2FI,2Finland2

5%

90%

Internet

% of clients who
use Googles P-
DNS and other
resolvers

% of clients who use

non-valida@ng
resolvers

% of clients who
exclusively use
Googles P-DNS

Map client IP to origin AS, and select origin ASs with more than 500 data
points

DNSSEC by Networks the Top 25

Rank
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

ASN Tests
AS22047
AS16232
AS37457
AS39651
AS12912
AS29562
AS23944
AS45629
AS45758
AS36925
AS7679
AS6849
AS34779
AS198471
AS5466
AS28220
AS5610
AS5603
AS7922
AS51737
AS3249
AS5645
AS1257
AS719
AS1759

DNSSEC&Validation
Validating Mixed None

Google&P3DNS
All Mixed None

5,376
1,818
2,051
860
613
1,263
749
8,759
15,833
1,012
551
6,301
1,043
722
1,463
563
2,094
1,505
43,438
753
1,093
1,993
880
655
1,080

98%
98%
97%
97%
96%
95%
94%
94%
93%
93%
93%
92%
91%
91%
90%
89%
88%
88%
87%
87%
84%
83%
83%
82%
82%

1%
1%
1%
1%
1%
1%
1%
3%
4%
2%
1%
3%
3%
4%
3%
2%
3%
3%
3%
9%
5%
2%
1%
2%
4%

1%
1%
2%
2%
2%
4%
5%
4%
3%
5%
6%
5%
6%
6%
6%
9%
9%
9%
9%
4%
10%
14%
16%
16%
15%

1%
2%
1%
1%
2%
2%
3%
1%
0%
25%
1%
5%
2%
95%
3%
5%
6%
0%
3%
97%
3%
3%
1%
2%
0%

0%
0%
0%
1%
0%
1%
1%
1%
2%
1%
0%
3%
0%
2%
1%
1%
7%
1%
1%
2%
1%
0%
1%
2%
0%

99%
98%
99%
98%
98%
97%
96%
97%
98%
74%
99%
92%
98%
4%
97%
94%
87%
99%
96%
1%
97%
96%
99%
96%
99%

VTR2BANDA2ANCHA2S.A.,2CL,2Chile2
ASN>TIM2TIM2(Telecom2Italia2Mobile)2Autonomous2System,2IT,2Italy2
Telkom>Internet,2ZA,2South2Africa
COMHEM>SWEDEN2Com2Hem2Sweden,2SE,2Sweden2
ERA2Polska2Telefonia2Cyfrowa2S.A.,2PL,2Poland2
KABELBW>ASN2Kabel2BW2GmbH,2DE,2Germany2
SKYBB>AS>AP2AS>SKYBroadband2SKYCable2Corporation,2PH,2Philippines2
JASTEL>NETWORK>TH>AP2JasTel2Network2International2Gateway,2TH,2Thailand2
TRIPLETNET>AS>AP2TripleT2Internet2Internet2service2provider2Bangkok,2TH,2Thailand2
ASMedi,2MA,2Morocco2
QTNET2Kyushu2Telecommunication2Network2Co.,2Inc.,2JP
UKRTELNET2JSC2UKRTELECOM,2,2UA
T>2>AS2T>2,22d.o.o.,2SI
LINKEM>AS2Linkem2spa,2IT,2Italy2
EIRCOM2Eircom2Limited,2IE,2Ireland2
CABO2SERVICOS2DE2TELECOMUNICACOES2LTDA,2BR,2Brazil2
TO2>CZECH>REPUBLIC2Telefonica2Czech2Republic,22a.s.,2CZ
SIOL>NET2Telekom2Slovenije2d.d.,2SI,2Slovenia2
COMCAST>79222>2Comcast2Cable2Communications,22Inc.,2US
SUPERLINK>AS2SuperLink2Communications2Co,2PS,2Occupied2Palestinian2Territory
ESTPAK2Elion2Enterprises2Ltd.,2EE,2Estonia2
TEKSAVVY>TOR2TekSavvy2Solutions2Inc.2Toronto,2CA,2Canada2
TELE2,2SE,2Sweden2
ELISA>AS2Elisa2Oyj,2FI,2Finland2
TSF>IP>CORE2TeliaSonera2Finland2IP2Network,2FI,2Finland2

5,331,072

7%

5%

88%

5%

5%

90%

Internet

Map client IP to origin AS, and select origin ASs with more than 500 data
points

A na7onal view of Poland

hVp://gronggrong.rand.apnic.net/cgi-bin/ccpage?c=PL (May 2014)

Some things to think about

DNSSEC generates very large responses from very
small queries
Which makes it a highly eec7ve DDOS amplier
Is relying on BCP38 going to work?
Do we need to think about DNS over TCP again?
But how many resolvers/rewalls/other middleware
stu support using TCP for DNS?
Whats the impact on the authorita7ve server load
and caching recursive resolver load when moving
from UDP to TCP?

Some things to think about

SERVFAIL is not just a DNSSEC valida7on is busted
signal
clients start walking through their resolver set asking the
same query
Which delays the client and loads the server
The moral argument: Failure should include a visible cost!
The expedient argument: nothing to see here, move along!

Maybe we need some richer signaling in the DNS for
DNSSEC valida7on failure

Some things to think about

Why do some 84% of queries have EDNS0 and
the DNSSEC OK ag set, yet only 6% of clients
perform DNSSEC valida7on?
How come we see rela7vely more queries
with the DNSSEC OK ag set for queries to
domains in signed zones?

Some things to think about

Googles Public DNS is currently handling
queries from ~16% of the Internets end client
popula7on
Thats around 1 in 6 users
In this 7me of heightened awareness about
corporate and state surveillance, and issues
around online anonymity and privacy, what do we
think about this level of use of Googles Public
DNS Service?

Some things to think about

Some things to think about

$ dig +short TXT google-public-dns-a.google.com!

"http://xkcd.com/1361/"!

A few observa7ons
Measuring what happens at the user level by
measuring some ar7fact or behaviour in the
infrastructure and inferring some form of user
behaviour is going to be a guess of some form
If you really want to measure user behaviour
then its useful to trigger the user to behave in the
way you want to study or measure
The technique of embedding code behind ads is
one way of achieving this objec7ve, for certain
kinds of behaviours rela7ng to the DNS and to
URL fetching

Ques7ons?

APNIC Labs:
c.net
Geo Huston research@apni