Presentation by Patrick Jones and John Crain at APRICOT 2018 on Monday, 26 February 2018.

1. | 1
DNS & DNSSEC
26 February 2018
APRICOT
Patrick Jones & John Crain

2. | 2| 2
DNSSEC

3. | 3
DNSSEC Overview
How much trust do we put in the Internet?
BCG estimates $4.2 trillion in digital trade, 5%
of GDP for G-20 in 2016
OECD estimates 12% of global consumer
goods trade is via e-commerce

4. | 4
DNSSEC Overview
How much trust do we put in the Internet?
Billions of mobile phones
Internet of Things to Internet of Everything
Depending on estimates, anywhere from 7-17
billion devices connected today, 30+ billion by
2020

5. | 5
What is DNSSEC?
¤ DNSSEC = “DNS Security Extensions”
¤ DNSSEC is a protocol that is currently being
deployed to secure the Domain Name
System (DNS)
¤ DNSSEC adds security to the DNS by
incorporating public key cryptography into
the DNS hierarchy, resulting in a single,
open, global Public Key Infrastructure (PKI)
for domain names
¤ Result of over a decade of community
based, open standards development

6. | 6
DNS History
First, a bit of history
Early networking mid 1960s
Internet 1973
Modern Domain Name System dates back to
early 1980s
DNS designed before security was a
concern

7. | 7
Early issues leading to DNSSEC
First, a bit of history
Major flaws in DNS discovered in 1990s
Trust in Cyberspace published in 1999

8. | 8
DNS Vulnerabilities
Any protocol is likely to have security flaws
Using reverse DNS to impersonate hosts
Software bugs
Bad crypto
Information leaks
Cache poisoning

9. | 9
DNSSEC History
2004 DNS Threat Analysis
Packet interception
ID guessing and query prediction
Name chaining
Betrayal by trusted server
Denial of service

10. | 10
DNS Points of Attack

11. | 11
DNSSEC Beginnings
Adding security to the DNS
DNSSEC RFCs revised in 2005
Sweden (.SE) first registry to adopt DNSSEC
in 2005
Other early adopters include .NL, .BR, .CZ,
.PR
Kaminsky bug announced in 2008

12. | 12
DNSSEC Beginnings
Growth in adoption, 2009-present
.org signed in 2009, first gTLD to implement
Implemented in root zone in 2010
Steady adoption by registry operators since 2010

13. | 13
State of DNSSEC Deployment
Over 90% of top-level domains are signed with
DNSSEC
1544 TLDs in the root, 1407 are signed
About 50% of ccTLDs are signed
Recent adoption in Bhutan, Italy, Guinea-Bissau
2nd level DNSSEC deployment growing slow & steady

14. | 14
How Does DNSSEC Work?
Without DNSSEC
DNS
DNS
majorbank.com
IP address X
majorbank.com
webserver
Attacker’s
webserver
majorbank.com
= IP addressA
majorbank.com
= Attacker IP address X
Attacker’s page
Passwords
DNS
DNS
majorbank.com
IP address A
majorbank.com
webserver
majorbank.com
= IP addressA
majorbank.com
= Attacker IP address X
Passwords
Desired page
With DNSSEC

15. | 15
What does DNSSEC protect?

16. | 16
Other technologies leveraging DNS
Other possible DNS targets
Technologies that use DNS to mitigate spam and
phishing
Stock tickers, RSS feeds
ENUM (mapping telephone numbers to services in the
DNS)

17. | 17
DNSSEC Overview
DNS Security Extensions
Provides digital signatures that allow
validating clients to prove that DNS data
was not modified in transit

18. | 18
DNSSEC Overview
Not designed for
Protection against DDoS attacks
Handling privacy
Public Key Infrastructure
Protection against IP Spoofing

19. | 19
DNSSEC Overview
DNS Security Extensions
Provides origin authentication
Integrity assurance services for DNS data
Authenticated denial of existence of DNS
data

20. | 20
DNSSEC
What is it?
Keys
Signatures
Chain of trust

21. | 21
DNSSEC
Benefits
End User – gain confidence of reaching intended
website
Registrant – fraud mitigation & greater brand protection
Registrar – Comply with industry standards & meet
registrant demands for increased security
Registry – Meet industry best practices & registrar
demands for increased domain security

22. | 22
DNSSEC
Benefits
Protects the directory lookup
Complements other technologies (https)
Provides platform for other security improvements

23. | 23
DNSSEC
Benefits
Attract and retain security & reputation-focused
registrants
Create new service offerings
Adding to trust overall

24. | 24
DNS Resolution
The process for obtaining answers from the
DNS in response to queries
Answers are provided by authoritative servers
Answers cached by recursive servers and clients

25. | 25
DNS Resolution
Queries
Originate with applications
Handled on clients by stub resolvers
Sent to and processed by recursive servers

26. | 26
Cache Poisoning

27. | 27
How can DNSSEC help?

28. | 28
Cryptographic Basics
Confidentiality – keeping data secret
Integrity – is it ”as sent”?
Authenticity – Did it come from the right place?
Non-repudiation – Don’t tell me you didn’t say that.

29. | 29
Cryptographic Basics
DNSSEC uses cryptography for 2 purposes:
Integrity – is it “as sent”?
Authenticity – Did it come from the right place?

30. | 30
Cryptographic Basics
To provide this, we use
Asymmetric cryptography
Digital signatures

31. | 31
Cryptographic Basics
Asymmetric Cryptography involves key
pairs
Public and private keys – data encrypted with one piece
of key can be decrypted and checked for integrity with
other
Unlikely that a person holding the public key can
reverse engineer the private key

32. | 32
Cryptographic Basics
Asymmetric Cryptography involves key
pairs
Data that can be decrypted is guaranteed to be
unaltered since encryption
Since data was decrypted with public portion of known
key pair, the private portion must have been the one to
encrypt

33. | 33
Cryptographic Basics
Examples
MX records – mail.zone. MX such as server1.zone.
NS records – name servers such as 10.20.30.40
AAAA records – IPv6 such as 2001:123:456::1

34. | 34
DNSSEC changes to DNS
New resource record types created for
DNSSEC
DNSKEY – public portion of the cryptographic key
RRSIG – Resource Record Signature
NSEC/NSEC3 – Proof of non-existence
NSEC3PARAM – NSEC3 parameter hint
DS – Delegation Signer

35. | 35
Key Pairs
The zone’s public key is stored in a DNSKEY record
The zone’s private key is kept safe
Ideally stored offline
Perhaps held in a Hardware Security Module

36. | 36
DNSKEY
Key type (ZSK or KSK)
Algorithm used
Key tag
Keying material

37. | 37
DNSKEY

38. | 38
DNSKEY

39. | 39
DNSKEY

40. | 40
Example of domain with unsigned zone

41. | 41
Example of domain with signed zone

42. | 42
DNSSEC changes to DNS
Enabling a chain of trust
Don’t sign the entire zone, sign a RRset
“.” -> .org -> icann.org -> ssac.icann.org
Parent does not sign the child zone. Parent signs a
pointer (hash) to the key used to sign the data of the
child zone

43. | 43
Security status of data
Enabling a chain of trust
Secure – resolver is able to build a chain of signed
DNSKEY and DS RRs from a trusted security anchor to
the RRset
Insecure – resolver knows it has no chain of signed
DNSKEY & DS RRs from any trusted starting point to
RRset

44. | 44
Security status of data
Enabling a chain of trust
Bogus – resolver believes it ought to be able to
establish a chain of trust but is unable to do so, may
indicate an attack, configuration error or data corruption
Indeterminate – no trust anchor to determine if zone and
children should be secure

45. | 45
Deploying DNSSEC
¤ DPS (DNSSEC Policy & Practice Statement)
¤ Operational Processes
¤ Follow documented procedures & checklists
¤ Maintain logs, records and reports of each action
¤ Audited processes – ICANN uses a key ceremony
¤ Involve stakeholders in processes and deployment, including
participation in ceremonies, invite external witnesses
¤ Establish a Policy Management Authority

46. | 46
Deploying DNSSEC
Physical Security
Environmental
Tiers
Access Control
Intrusion Detection
Disaster Recovery
ICANN uses two key facilities, currently in Virginia &
California

47. | 47
Deploying DNSSEC
Physical Security
Decisions are based on your risk profile
Suitable power, air; protection from disaster
Tiers
Tamper evident packaging

48. | 48
Inside a key facility

49. | 49
Key Ceremonies

50. | 50
DNSSEC Deployment
Sharing experiences from other registries
Early adopters: Sweden, Netherlands, Brazil, Czechia
gTLD registries: .org, Verisign, Afilias

51. | 51
State of DNSSEC Deployment
Over 90% of top-level domains are signed with
DNSSEC
1544 TLDs in the root, 1407 are signed
About 50% of ccTLDs are signed
Recent adoption in Bhutan, Italy, Guinea-Bissau
2nd level DNSSEC deployment growing slow & steady

52. | 52
State of DNSSEC Deployment
Adoption rate higher in new top-level domains
.bank & .insurance
.ovh (French ISP)
.frl (Friesland), .amsterdam, .paris
.taxi

53. | 53
State of DNSSEC Deployment
Most DNS recursive resolvers support
DNSSEC validation
Large ISPs enabling DNSSEC validation (Claro in
Brasil, Telia in Sweden, Comcast in US)
DNSSEC validation is at about 12% globally
Successfully migrated Zone Signing Key to 2048-bit
RSA key in 2016
Rollover of Key Signing Key progressing in 2017

54. | 54
State of DNSSEC Deployment

55. | 55
State of DNSSEC Deployment

56. | 56
DNSSEC Adoption
¤ Now need ISPs & application providers to implement
¤ At regional level, looking to banks, infrastructure providers and
government agencies to adopt
¤ Adds level of trust for government domains, banks, ISPs

57. | 57
DNSSEC in Sweden
First registry to adopt
Sweden worked with local ISPs to encourage adoption
Price incentives
Offers technical assistance to registrars to enable
signing
680,000 domains signed in .se (out of 1.4m)

58. | 58
DNSSEC in Netherlands
49% of .NL domains secured with DNSSEC

59. | 59
DNSSEC in Netherlands
.NL domains is a leader on DNSSEC research
SIDN has created a DNS Security Fund
OpenDKIM (Domain Keys Identified Email)
OpenDNSSEC
DNSSEC for instant messaging & VoIP
Dutch Ministry has donated .5m EUR to Internet
Hardening Fund (Dec 2016)
DNSSEC is mandatory for Dutch government domains

60. | 60
DNSSEC in Czechia
Over half of .CZ domains are signed

61. | 61
DNSSEC in Czechia
CZNIC is a leader in DNSSEC
Czech government requires government domains to be
DNSSEC signed (2013)
CZNIC publishes useful tools for community, such as
DNSSEC/Transport Layer Security Association validator
for browsers (puts green key in browser URL bar for
DNSSEC)

62. | 62
DNSSEC in Norway
58% of .NO domains are signed
752,000 domains overall, about 435,000 signed
DNSSEC in .no launched 9 December 2014
Norid has worked closely with their registrars to speed
adoption

63. | 63
DNSSEC in Costa Rica
Sharing experiences from other registries
NIC.cr has become a regional leader in Latin America,
assisting with DNSSEC training for neighboring
countries
Pioneering locally developed technology and signing
processes

64. | 64
DNSSEC in United States
Sharing experiences from other registries
Most US government domains have adopted DNSSEC
Major ISP adoption growing – Comcast (25 million
customers)
Microsoft, Apple adoption in browsers
Google DNS does DNSSEC validation, improving
service for over 130m DNS queries per day at time of
launch

65. | 65
DNSSEC in Brasil
NIC.br was another early adopter
1m domains signed out of 3.9m in .br
See https://registro.br/estatisticas.html

66. | 66
State of DNSSEC Deployment

67. | 67
Source Material
¤ Champika Wijayatunga, Matt Larson, ICANN
¤ ICANN DNSSEC deployment statistics
¤ NSRC DNSSEC training material
¤ Olaf Kolkman, Internet Society
¤ ICANN slides on root key rollover
¤ Internet Society Deploy360 programme
¤ IIS (.se)
¤ Nic.cr & SIDN.nl
¤ NTLDstats

68. | 68| 68
KSK Rollover

69. | 69
KSK Rollover: An Overview
¤ The Root Zone DNSSEC Key Signing Key “KSK” is
the top most cryptographic key in the DNSSEC
hierarchy
¤ The KSK is a cryptographic public-private key pair:
o Public part: trusted starting point for DNSSEC
validation
o Private part: signs the Zone Signing Key (ZSK)
¤ Builds a “chain of trust” of successive keys and
signatures to validate the authenticity of any
DNSSEC signed data
ICANN is in the process of performing a Root Zone DNS
Security Extensions (DNSSEC) Key Signing Key (KSK) rollover
Watch video:
DATA

70. | 70
Why is ICANN Rolling the KSK?
¤ As with passwords, the cryptographic keys used in DNSSEC-
signing DNS data should be changed periodically
o Ensures infrastructure can support key change in case of
emergency
¤ This type of change has never before occurred at the root level
o There has been one functional, operational Root Zone
DNSSEC KSK since 2010
¤ The KSK rollover must be widely and carefully coordinated to
ensure that it does not interfere with normal operations

71. | 71
Background
¤ When you validate DNSSEC signed DNS records, you need a Trust Anchor.
¡ A Trust Anchor is a Public Key.
¤ Public Keys should not live forever.
¤ These Trust Anchors probably should be periodically renewed (rolled).
¡ You can do this automatically or manually.
¤ However, there was no way for us (ICANN) to check if you have the right
key configured.
¤ Therefore, a multi-year design and outreach effort ensued:
¡ Design-team, blogs, outreach, presentations in various venues, plans, vendors and
governments were contacted, etc., etc.

72. | 72
The Process
¤ 11 July 2017: Introduce the new KSK-2017.
¡ Monitor if there are fundamental changes in root-server traffic
¡ If not, continue, else fall back.
¤ 10 August 2017: “30 day hold-down period ends”
¡ Monitor if there are fundamental changes in root-server traffic.
¡ If not, continue, else fall back.
¤ 19 September 2017: DNSKEY Response size increased due to standard ZSK roll
¡ Monitor if there are fundamental changes in root-server traffic.
¡ If not, continue, else fall back.

73. | 73
Verisign Public 17
Root Zone Key Tag Signaling −− TA Update Evidence
PercentofSignalers
0
20
40
60
80
100
May Jun Jul Aug Sep Oct
KSK−2017Published
RFC5011HoldDownTimerEnds
KSK−2017Rollover
2010 2010+2017 2017
The timeline in a graph

74. | 74
Who has KSK-2017 configured as a trust anchor?
¤ Until very recently, there was no way to know which trust anchors validators
have configured
¤ Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) is a
recent protocol extension that can provide that information
¡ Reports trust anchor key tags via EDNS option or DNS query
¡ Published as RFC 8145 (April 2017)
¤ Implementations
¡ BIND 9.11 starting with 9.11.0b3 (28 July 2016)
¡ BIND 9.10 starting with 9.10.5b1 (11 January 2017)
¡ Unbound 1.6.4 (27 June 2017)
¡ On by default in BIND (since 28 July 2016) and in Unbound since version 1.6.7 (10
October 2017)
¡ No other known implementations

75. | 75
Looking for key tag signaling
¤ RFC 8145 is so new and validator support so limited that the root KSK roll
project team did not expect to get enough data to help with the first root KSK
Roll.
¡ On average, there are 4.2 Million unique addresses sending queries to root-servers.
¡ Given typical deployment curves, it was assumed the dataset would be too small to
statistically represent all validating resolvers.
¤ However…
¡ Before the introduction of KSK-2017, RFC8145-able resolvers would send KSK-2010 only.
¡ After the hold down period of 30 days, RFC8145-able resolvers would send both KSK-2010
and KSK-2017.
¡ Duane Wessels (Verisign, co-author of 8145) started looking at A & J root traffic for this
signaling

76. | 76
Verisign Public 17
Root Zone Key Tag Signaling −− TA Update Evidence
PercentofSignalers
0
20
40
60
80
100
May Jun Jul Aug Sep Oct
KSK−2017Published
RFC5011HoldDownTimerEnds
KSK−2017Rollover
2010 2010+2017 2017
Hey! There’s data! Wait. What?

77. | 77
Further analysis by OCTO Research
¤ ICANN OCTO Research did an analysis similar to Duane’s
¡ Analyzed query data from B, D, F and L root servers
¡ For the entire month of September and October (until the 24th)
¤ Results:
¡ Total number of unique addresses reporting key tag data: 27,084 (out of 4.2 million,
0.57%)
¡ Total number that only ever reports KSK-2010: 1631
¡ 6.02% of reporting validators were not ready for the KSK roll on 11 October
2017
¡ Non-zero percentage of reporting validators were announcing only KSK-2017 (?!)
¤ Analysis is complicated
¡ Dynamic resolver IPs make the situation look worse by inflating true number of
sources
¡ Resolvers behind forwarders make the situation look better as they obscure multiple
validators behind the forwarder

78. | 78
Why do validators report just KSK-2010?
¤ Multiple reasons suspected or confirmed:
1. BIND reports trust anchors even if not validating
2. Old configurations pre-dating automatic update support
• E.g., BIND’s trusted-keys instead of managed-keys or dnssec-validation auto
3. Bugs in automatic update or key tag signaling support
• E.g., announce key tags even if DNSSEC not enabled (DO=0)
4. Operator error
• E.g., Docker container keeps booting up with only KSK-2010 and starts 5011 all
over again
¤ We always knew old configurations would be an issue but never had objective data until now
¤ We worried bugs and operator error were possible but didn’t have evidence until now
¤ Analysis is ongoing
¡ Hired a contractor to try to figure out reasons for misconfiguration

79. | 79
Back to the plan and process
¤ 19 September 2017: DNSKEY Response size increased due to standard ZSK
roll
¡ Monitor if there are fundamental changes in root-server traffic.
¡ If not, continue, else fall back.
¤ We had received Verisign’s report and corroborated it with our own data.
¤ From the Operational Plan:
“The Root Zone Management Partners might also decide to extend any phase for additional
quarters. For example, if new information indicates that the next phase may lead to
complications, the current phase would be prolonged. This is referred to as an extend scenario.”
¤ 27 September 2017: “Extend” scenario kicks in
¡ ICANN Announces that the root KSK Rollover is delayed

80. | 80
Issues
¤ We do not know how representative the set of validators reporting key tag
data is compared to the set of all validators
¤ Validators != end users (or “end systems”), and the impact on end users is
what is most important
¡ The design team recognized this
¤ Determining number of end users/systems for a given resolver is hard
¡ APNIC’s Google Ad experiment platform-based data will help
¤ Mitigation is hard
¡ We’ve already had a multi-year campaign to reach operators
¡ Implementation-specific problems don’t make the problem easier

81. | 81
Key roll
¤ We postponed the root KSK rollover in September 2017 until we could
gather more information and understand the situation better
¤ Study & Analysis conducted August 2017-February 2018
¤ Public comment period launched on 1 February 2018 through 1 April 2018
on revised date (11 October 2018)
¤ Comments have been limited but few respondents in favor of going
forward with key roll

82. | 82
DNS Software
Developers &
Distributors
Network
Operators
Root Server
Operators
Internet
Service
Providers
Who Will Be Impacted?
System
Integrators
End Users
(if no action taken by
resolver operators)

83. | 83
Why You Need to Prepare
If you have enabled DNSSEC validation, you must
update your systems with the new KSK to help ensure
trouble-free Internet access for users
¤ Currently, 25 percent of global Internet users, or 750 million
people, use DNSSEC-validating resolvers that could be
affected by the KSK rollover
¤ If these validating resolvers do not have the new key when
the KSK is rolled, end users relying on those resolvers will
encounter errors and be unable to access the Internet

84. | 84
Be aware whether DNSSEC is enabled in your servers
Be aware of how trust is evaluated in your operations
Test/verify your set ups
Inspect configuration files, are they (also) up to date?
If DNSSEC validation is enabled or planned in your system
o Have a plan for participating in the KSK rollover
o Know the dates, know the symptoms, solutions
What Do Operators Need to Do?

85. | 85
How To Update Your System
If your software supports
automated updates of DNSSEC
trust anchors (RFC 5011):
¤ The KSK will be updated
automatically at the appropriate
time
¤ You do not need to take
additional action
o Devices that are offline during
the rollover will have to be
updated manually if they are
brought online after the rollover
is finished
If your software does not support
automated updates of DNSSEC
trust anchors (RFC 5011) or is
not configured to use it:
¤ The software’s trust anchor file
must be manually updated
¤ The new root zone KSK is now
available here after March 2017:
Root Anchors
data.iana.org/ root-anchors/

86. | 86
Check to See If Your Systems Are Ready
ICANN is offering a test bed for operators or any interested parties to
confirm that their systems handle the automated update process correctly.
Check to make sure your systems are ready by visiting:
go.icann.org/KSKtest
Automated Trust Anchor Update Testbed
The root zone Key Signing Key (KSK) is changing, or rolling, on 11 October 2017.
Operators of recursive resolvers with DNSSEC validation enabled will need to ensure that
their systems are updated with the new root zone KSK configured as a trust anchor before
that date. If a recursive resolver supports RFC 5011, “Automated Updates of DNS Security
(DNSSEC) Trust Anchors”, and this feature is properly configured, the new KSK should
automatically be installed as a trust anchor and DNSSEC validation should continue
without problems.
If a validating resolver’s implementation or configuration of the RFC 5011 automated trust
anchor update protocol is incorrect for any reason, then its configuration might not be
properly updated during the root zone KSK roll and resolution would fail after 11 October
2017.
This testbed allows operators of validating resolvers to test their implementation and
confirm its ability to properly follow a KSK roll and update its trust anchor configuration.
This test protocol assumes that you understand the upcoming KSK change, and at least
some about RFC 5011.
Text in the callout
box isn’t correct -
check
Purpose of This Testbed
The test system described here allows the operator of a validating
recursive resolver to test its support for the RFC 5011 automated trust
anchor update protocol and therefore its readiness for the root zone KSK
roll. The test operates in real time and should not affect the resolver’s
normal operation. The testbed works by starting a KSK roll in a new zone
each week. These test zones are not used for any other purpose. For
example, the current zone name is 2017-03-26.automated-ksk-
test.research.icann.org. Because this zone is used only for the testbed
and contains no names any

87. | 87
Three Steps to Recovery
Stop the tickets
It's OK to turn off DNSSEC validation while you fix (but remember to turn
it back on!)
Debug
If the problem is the trust anchor, find out why it isn't correct
o Did RFC 5011 fail? Did configuration tools fail to update the key?
o If the problem is fragmentation related, make sure TCP is enabled
and/or make other transport adjustments
Test the recovery
Make sure your fixes take hold
If your DNSSEC validation fails after the key role:

88. | 88
For More Information
Join the conversation online
o Use the hashtag #KeyRoll
o Sign up to the mailing list
https://mm.icann.org/listinfo/ksk-rollover
Attend an event
o Visit
https://features.icann.org/calendar
to find upcoming KSK rollover
presentations in your region
Ask a question to
globalsupport@icann.org
o Subject line: “KSK Rollover”
Learn more
https://icann.org/kskroll

89. Visit us at icann.org
| 89
Engage with ICANN – Thank You and Questions