Measuring the DNS from the Users’ perspective

Geoff Huston APNIC Labs, May 2014

What’s the question?

How many users can do with the DNS?

• • • • How many users can retrieve a URL using IPv6?

How many users perform DNSSEC validation 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 often measure the network by observing infrastructure and inferring end user behaviour – because its often easier to instrument infrastructure This approach is aimed at measuring an aspect of of behaviour within particular parameters of the network infrastructure, but it does not encompass how the end user assembles a coherent view of the network

For example…DNSSEC

• • • We can walk zone files and count the number of signed zones Or we could analyze the log files of authoritative name servers for a signed zone and attempt to infer something about the number of users who use DNSSEC to validate DNS responses But can these sort of approaches measure the population of end users who are served by DNSSEC-validating 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

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

How to measure a million end users

• or Be Google (or any other massively popular web service provider) • 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 primitives in ‘actionscript’ to fetch ‘network assets’ – Typically used to load alternate images, sequences – Not a generalized network stack, subject to constraints: • Port 80 • crossdomain.xml on hosting site must match source name (wildcard syntax) Flash has asynchronous ‘threads’ model for event driven, sprite animation

APNIC’s measurement technique

• • • • Craft flash/actionscript which fetches network assets to measure when the ad is displayed Web Assets are reduced to a notional ‘1x1’ image which is not added to the DOM and is not displayed Assets can be named to cause specific DNS resolution via local gethostbyname() styled API within the browser’s Flash engine Encode data transfer in the name of fetched assets – Use the DNS as the information conduit: • Result is returned by DNS name with wildcard – Use HTTP as the information conduit • Result is returned via parameters attached to an HTTP GET command

Advertising placement logic

• • • • Fresh Eyeballs == Unique IPs – We have good evidence the advertising 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/Location/Context tuned – Can select for time of day, physical location or keyword contexts (for search-related ads) – But if you don’t select, then placement is generalized Aim to fill 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

Advertising 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 distribution of ads throughout the day No constraint on location, time 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 4000 3000 2000 1000 23/Mar 24/Mar 25/Mar 26/Mar 27/Mar 28/Mar 29/Mar 30/Mar 31/Mar 01/Apr 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 – http://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 activated and deactivated in real time.

Experiment Server config

• • • There are currently three servers, identically configured (US, Europe, Australia) Server runs Bind, Apache and tcpdump Experiment directs the client to the “closest” server (to reduce rtt-related timeouts) based on simple /8 map of client address to region

Collected Data

• Per Server, Per Day: – http-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 effects of caching We use unique DNS labels and unique URL GET parameters – Ensures that all DNS resolution requests and HTTP fetch requests end up at the experiment’s 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, connection failure rate – DNS behaviours e.g.: DNSSEC use, DNS resolution performance…

The generic approach

• • • Seed a user with a set of tasks that cause identifiable traffic at an instrumented server The user does not contribute measurements The server performs the data collection

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 reporting URL (10 second timer) All DNS is dual stack

Discovering Routing Filters via Ads

Client is given 3 URLs to load: • DNS name that resolves into the test prefix • • DNS name the resolves to a control prefix Result reporting URL (10 second timer)

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 reporting URL (10 second timer)

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 “completion” Web + DNS query log results for clients: – Performed DNSSEC signature validation 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 validation and not resolving DNS names when the DNSSEC signature cannot be validated A further

4.7%

of clients are using a mix of validating and non-validating resolvers, and in the case of a validation failure turn to a non validating resolver!

Where is DNSSEC? – The Top 20

Rank CC Code

17 18 19 20 1 2 3 YE SE SI 4 5 EE VN FI

DNSSEC-validating resolvers

LU 9 TH 10 11 12 13 14 15 16 CL ZA UA ID IE TZ CO DZ PS AZ US

XA Tests Validating (%)

2,279 5,983 5,883 70.8% 67.2% 51.0% 16,198 8,441 5,095 311,740

5,331,072

19.1% 18.5% 18.2% 15.2%

6.7% Mixed (%)

11.2% 4.6% 6.1% 2,132 114,996 3,556 10,468 1,204 110,380 29.8% 26.8% 11.6% 8.6% 21,167 26.6% 2.8% 12,398 32,916 26.2% 25.0% 5.8% 9.8% 25,440 44.7% 42.4% 41.0% 30.8% 22.0% 20.7% 20.7% 4.4% 11.8% 3.4% 8.4% 9.8% 3.0% 15.6% 6.5% 37.5% 28.3% 18.4% 3.5%

4.8% None (%)

18.0% 28.2% 42.9% 43.4% 53.2% 63.4% 81.3%

88.5%

Yemen Sweden Slovenia 50.9% 45.8% Estonia Vietnam 55.6% Finland 60.9%

% of clients who use

58.6% 64.7% 70.7%

non-validating resolvers

Chile 68.0% 65.2% 68.2% 76.3% 63.8% 73.3% 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 Top 20

YE SE SI DZ PS AZ US

XA

EE VN FI CZ LU TH CL ZA UA ID IE TZ CO 1 2 3 12 13 14 15 16 4 5 6 7 8 9 10 11 17 18 19 20

Rank CC Code Tests Validating (%)

2,279 5,983 5,883 70.8% 67.2% 51.0% 2,132 114,996 3,556 10,468 1,204 110,380 21,167 12,398 32,916 89,331 7,679 1,724 25,440 16,198 8,441 5,095 311,740

5,331,072

19.1% 18.5% 18.2% 15.2%

6.7%

44.7% 42.4% 41.0% 30.8% 29.8% 26.8% 26.6% 26.2% 25.0% 22.0% 20.7% 20.7% 20.3%

Mixed (%)

11.2% 4.6% 6.1% 4.4% 11.8% 3.4% 8.4% 11.6% 8.6% 2.8% 5.8% 9.8% 9.8% 3.0% 15.6% 6.5% 37.5% 28.3% 18.4% 3.5%

4.8% None (%)

18.0% 28.2% 42.9% 50.9% 45.8% 55.6% 60.9% 58.6% 64.7% 70.7% 68.0% 65.2% 68.2% 76.3% 63.8% 73.3% 43.4% 53.2% 63.4% 81.3%

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 bottom 20

Rank CC Code

MU BH AE JO QA KR

XA

CN SA MD FR NZ BE PR LT SG BS HR OM TT ME LV PT 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118

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 (%)

1.9% 1.7% 1.6% 1.6% 1.6% 1.5% 1.5% 1.4% 1.4% 1.4% 1.4% 1.3% 1.3% 1.3% 1.2% 1.2% 1.1% 1.1% 1.0% 0.9% 0.4% 0.3%

6.7% Mixed (%)

2.1% 2.1% 1.9% 1.0% 15.0% 3.8% 13.0% 1.7% 4.8% 2.7% 1.2% 2.0% 3.4% 3.5% 3.3% 2.0% 1.7% 5.7% 1.0% 1.3% 0.8% 0.4%

4.8% None (%)

96.0% 96.2% 96.5% 97.4% 83.4% 94.7% 85.5% 96.9% 93.8% 95.9% 97.5% 96.7% 95.3% 95.3% 95.4% 96.8% 97.2% 93.2% 98.0% 97.9% 98.8% 99.3%

88.5%

China Saudi Arabia Republic of Moldova France New Zealand Belgium Puerto Rico Lithuania Singapore Bahamas Croatia Oman Trinidad and Tobago Montenegro Latvia Portugal Mauritius Bahrain United Arab Emirates Jordan Qatar Republic of Korea

World

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

Most importantly…

Rank CC Code 35 101 AU NZ Tests 22,173 31,683 Validating Mixed None Country 10.72

1.57

2.68

86.6

Australia 15.04

83.39

New Zealand

The Mapped view of DNSSEC Use

http://gronggrong.rand.apnic.net/cgi-bin/worldmap (May 2014) Fraction of users who use DNSSEC-validating resolvers

Why…

is it that 7% of users performing DNSSEC validation is about 3 times the number of users who are capable of using IPv6?

has DNSSEC deployment been so successful compared to IPv6?

Is Google’s P-DNS a Factor?

Another observation from the data

Clients who used Google’s Public DNS servers:

10.4%

– Exclusively Used Google’s P-DNS:

5.4%

– Used a mix of Google’s P-DNS and other resolvers:

5.0%

Is Google’s P-DNS a Factor?

12 13 14 15 16 17 18 19 20

Rank CC Code

1 YE 2 3 4

DNSSEC Validation Tests Validating

2,279 SE 5,983 SI EE 5,883 2,132 70.8% 67.2% 51.0% 44.7% 5 6 7 8 9 10 11 VN FI 114,996 3,556 CZ LU 10,468 1,204 TH CL ZA 110,380 21,167 12,398 42.4% 41.0% 30.8% 29.8% 26.8% 26.6% 26.2% UA ID IE TZ CO DZ PS AZ US

XA

32,916 89,331 7,679 1,724 25,440 16,198 8,441 5,095 311,740

5,331,072 Google Public DNS All Mixed

6.5% 5.0%

None

88.5% 2.1% 5.0% 4.2% 0.4% 0.4% 1.1% 97.5% 94.7% 94.8% 98.7% 2.1% 13.8% 15.9% 15.9% 6.2% 8.0% 1.3% 0.8% 6.5% 0.8% 5.9% 0.4% 3.0% Yemen Sweden Slovenia Estonia 0.1% Vietnam 97.1% 79.7% Finland Czech Republic 83.3% 78.3% 93.4% 89.0% Luxembourg Chile South Africa

% of clients who use a

22.0% 72.2% 8.1%

mix of Google’s P-DNS

20.7% 20.3% 19.1% 18.5% 18.2% 15.2%

6.7%

94.4% 12.7% 71.2% 51.8% 68.5% 10.6%

50.2%

5.1% 1.5% 27.7% 29.2% 9.6% 2.9%

7.3%

76.9% 19.8% 81.9% 0.6% 85.8% 1.1% 19.0% 21.9% 86.4%

42.5%

Ukraine Indonesia Ireland Tanzania Colombia Algeria Occupied Palestinian T.

Azerbaijan United States of America

World

Of those clients who perform DNSSEC validation, what resolvers are they using: All Google P-DNS? Some Google P-DNS? No Google P DNS?

Is Google’s P-DNS a Factor?

12 13 14 15 16 17 18 19 20

Rank CC Code

1 YE 2 3 4 SE SI EE 5 6 7 8 9 10 11 VN FI CZ LU TH CL ZA UA ID IE TZ CO DZ PS AZ US

XA DNSSEC Validation Tests Validating

2,279 70.8% 5,983 5,883 2,132 67.2% 51.0% 44.7% 114,996 3,556 10,468 1,204 110,380 21,167 12,398 42.4% 41.0% 30.8% 29.8% 26.8% 26.6% 26.2% 32,916 89,331 7,679 1,724 25,440 16,198 8,441 5,095 311,740

5,331,072

25.0% 22.0% 20.7% 20.7% 20.3% 19.1% 18.5% 18.2% 15.2%

6.7% Google Public DNS All Mixed

6.5% 5.0%

None

88.5% 2.1% 5.0% 4.2% 0.4% 0.4% 1.1% 97.5% 94.7% 94.8% 98.7% 2.1% 13.8% 15.9% 15.9% 6.2% 8.0% 1.3% 0.8% 6.5% 0.8% 5.9% 0.4% 3.0% 0.1% 97.1% 79.7% 83.3% 78.3% 93.4% 89.0% 20.1% 72.2% 17.0% 94.4% 12.7% 71.2% 51.8% 68.5% 10.6%

50.2%

3.0% 8.1% 1.1% 5.1% 1.5% 27.7% 29.2% 9.6% 2.9%

7.3%

76.9% 19.8% 81.9% 0.6% 85.8% 1.1% 19.0% 21.9% 86.4%

42.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

Of those clients who perform DNSSEC validation, what resolvers are they using: All Google P-DNS? Some Google P-DNS? No Google P DNS?

Is Google’s P-DNS a Factor?

12 13 14 15 16 17 18 19 20

Rank CC Code

1 YE 2 3 4 SE SI EE 5 6 7 8 9 10 11 VN FI CZ LU TH CL ZA UA ID IE TZ CO DZ PS AZ US

XA DNSSEC Validation Tests Validating

2,279 70.8% 5,983 5,883 2,132 67.2% 51.0% 44.7% 114,996 3,556 10,468 1,204 110,380 21,167 12,398 42.4% 41.0% 30.8% 29.8% 26.8% 26.6% 26.2% 32,916 89,331 7,679 1,724 25,440 16,198 8,441 5,095 311,740

5,331,072

25.0% 22.0% 20.7% 20.7% 20.3% 19.1% 18.5% 18.2% 15.2%

6.7% Google Public DNS All Mixed

6.5% 5.0%

None

88.5% 2.1% 5.0% 4.2% 0.4% 0.4% 1.1% 97.5% 94.7% 94.8% 98.7% 2.1% 13.8% 15.9% 15.9% 6.2% 8.0% 1.3% 0.8% 6.5% 0.8% 5.9% 0.4% 3.0% 0.1% 97.1% 79.7% 83.3% 78.3% 93.4% 89.0% 20.1% 72.2% 17.0% 94.4% 12.7% 71.2% 51.8% 68.5% 10.6%

50.2%

3.0% 8.1% 1.1% 5.1% 1.5% 27.7% 29.2% 9.6% 2.9%

7.3%

76.9% 19.8% 81.9% 0.6% 85.8% 1.1% 19.0% 21.9% 86.4%

42.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

Of those clients who perform DNSSEC validation, what resolvers are they using: All Google P-DNS? Some Google P-DNS? No Google P DNS?

Rank

DNSSEC by Networks – the Top 25

ASN Tests DNSSEC Validation Validating Mixed None Google P-DNS All Mixed None

% of clients who do not use Google’s P DNS

17 18 19 20 21 22 23 24 25 1 2 3 4 AS22047 AS16232 AS37457 AS39651 AS12912 5,376 1,818 2,051 860 613 6 7 AS29562 AS23944 1,263 749 9 10 11 12 13 14 15 16 AS45629 AS45758

resolvers

AS7679 AS6849 AS34779 AS198471 AS5466 AS28220 8,759 15,833 1,012 551 6,301 1,043 722 1,463 563 98% 98% 97% 97% 96% 95% 94% 94% 93% 93% 93% 92% 91% 91% 90% 89% 1% 3% 3% 4% 3% 2% 1% 1% 1% 1% 1% 1% 1% 3% 4% 2% AS5610 2,094 88% 3% 9% AS7922 AS51737 43,438 753 87% 87% 3% 3% 9% 9% 9% 4% 10% AS3249 AS5645 1,093 1,993 84% 83% 5% 2% AS1257

and non-validating

AS719 AS1759 655 1,080 82% 82% 2% 4% 14% 16% 16% 15% 6% 5% 6% 6% 6% 9% 1% 1% 2% 2% 2% 4% 5% 4% 3% 5% 6% 0% 3% 97% 3% 3% 1% 2% 0% 1% 2% 1% 1% 2% 2% 3% 1% 0% 25% 1% 5% 2% 95% 3% 5% 0% 3% 0% 2% 1% 1% 0% 0% 0% 1% 0% 1% 1% 1% 2% 1% 1% 1% 2% 1% 0% 1% 2% 0% 99% 98% 99% 98% 98% 97% 96% 97% 98% 74% 99% 92% 98% 4% 97% 94% VTR BANDA ANCHA S.A., CL, Chile ASN-TIM TIM (Telecom Italia Mobile) Autonomous System, IT, Italy Telkom-Internet, ZA, South Africa COMHEM-SWEDEN Com Hem Sweden, SE, Sweden ERA Polska Telefonia Cyfrowa S.A., PL, Poland KABELBW-ASN Kabel BW GmbH, DE, Germany SKYBB-AS-AP AS-SKYBroadband SKYCable Corporation, PH, Philippines JASTEL-NETWORK-TH-AP JasTel Network International Gateway, TH, Thailand ASMedi, MA, Morocco

% of clients who use Google’s P-DNS

QTNET Kyushu Telecommunication Network Co., Inc., JP UKRTELNET JSC UKRTELECOM, , UA

and other resolvers

T-2-AS T-2, d.o.o., SI LINKEM-AS Linkem spa, IT, Italy EIRCOM Eircom Limited, IE, Ireland CABO SERVICOS DE TELECOMUNICACOES LTDA, BR, Brazil 87% TO2-CZECH-REPUBLIC Telefonica Czech Republic, a.s., CZ 99% 96% 1% 97% SIOL-NET Telekom Slovenije d.d., SI, Slovenia

resolvers % of clients who

96% 99% 96% 99% TEKSAVVY-TOR TekSavvy Solutions Inc. Toronto, CA, Canada TELE2, SE, Sweden

Google’s P-DNS

ELISA-AS Elisa Oyj, FI, Finland TSF-IP-CORE TeliaSonera Finland IP Network, FI, Finland

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

DNSSEC by Networks – the Top 25

Rank ASN Tests DNSSEC Validation Validating Mixed None Google P-DNS All Mixed None

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 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 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% 9% 9% 9% 4% 10% 14% 6% 5% 6% 6% 6% 9% 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% VTR BANDA ANCHA S.A., CL, Chile ASN-TIM TIM (Telecom Italia Mobile) Autonomous System, IT, Italy Telkom-Internet, ZA, South Africa COMHEM-SWEDEN Com Hem Sweden, SE, Sweden ERA Polska Telefonia Cyfrowa S.A., PL, Poland KABELBW-ASN Kabel BW GmbH, DE, Germany SKYBB-AS-AP AS-SKYBroadband SKYCable Corporation, PH, Philippines JASTEL-NETWORK-TH-AP JasTel Network International Gateway, TH, Thailand TRIPLETNET-AS-AP TripleT Internet Internet service provider Bangkok, TH, Thailand ASMedi, MA, Morocco QTNET Kyushu Telecommunication Network Co., Inc., JP UKRTELNET JSC UKRTELECOM, , UA T-2-AS T-2, d.o.o., SI LINKEM-AS Linkem spa, IT, Italy EIRCOM Eircom Limited, IE, Ireland CABO SERVICOS DE TELECOMUNICACOES LTDA, BR, Brazil TO2-CZECH-REPUBLIC Telefonica Czech Republic, a.s., CZ SIOL-NET Telekom Slovenije d.d., SI, Slovenia COMCAST-7922 - Comcast Cable Communications, Inc., US SUPERLINK-AS SuperLink Communications Co, PS, Occupied Palestinian Territory ESTPAK Elion Enterprises Ltd., EE, Estonia TEKSAVVY-TOR TekSavvy Solutions Inc. Toronto, CA, Canada TELE2, SE, Sweden ELISA-AS Elisa Oyj, FI, Finland TSF-IP-CORE TeliaSonera Finland IP Network, FI, Finland

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 national view of Poland

http://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 effective DDOS amplifier Is relying on BCP38 going to work?

– – Do we need to think about DNS over TCP again?

But how many resolvers/firewalls/other middleware stuff support using TCP for DNS?

– What’s the impact on the authoritative server load and caching recursive resolver load when moving from UDP to TCP?

Some things to think about

SERVFAIL is not just a “DNSSEC validation 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 validation failure

Some things to think about

• • Why do some 84% of queries have EDNS0 and the DNSSEC OK flag set, yet only 6% of clients perform DNSSEC validation?

How come we see relatively more queries with the DNSSEC OK flag set for queries to domains in signed zones?

Some things to think about

• Google’s Public DNS is currently handling queries from ~16% of the Internet’s end client population – That’s around 1 in 6 users – In this time 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 Google’s 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 observations

• • • Measuring what happens at the user level by measuring some artifact 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 objective, for certain kinds of behaviours relating to the DNS and to URL fetching

Questions?

APNIC Labs: Geoff Huston

[email protected]