APNIC, profile picture
Uploaded byAPNIC
1,881 views

DNS & DNSSEC

This document provides an overview of DNSSEC (Domain Name System Security Extensions). It begins with some background on the history and vulnerabilities of DNS that led to the development of DNSSEC. It then explains how DNSSEC works by digitally signing DNS data to authenticate its source and ensure its integrity. The document discusses the state of DNSSEC deployment globally and in various top-level domains and country code top-level domains. It also provides examples of DNSSEC implementation strategies used by early adopter registries such as Sweden, the Netherlands, Czechia, and Norway.

Embed presentation

| 1 DNS & DNSSEC 26 February 2018 APRICOT Patrick Jones & John Crain
| 2| 2 DNSSEC
| 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 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 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 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 Early issues leading to DNSSEC First, a bit of history Major flaws in DNS discovered in 1990s Trust in Cyberspace published in 1999
| 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 DNSSEC History 2004 DNS Threat Analysis Packet interception ID guessing and query prediction Name chaining Betrayal by trusted server Denial of service
| 10 DNS Points of Attack
| 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 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 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 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 What does DNSSEC protect?
| 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 DNSSEC Overview DNS Security Extensions Provides digital signatures that allow validating clients to prove that DNS data was not modified in transit
| 18 DNSSEC Overview Not designed for Protection against DDoS attacks Handling privacy Public Key Infrastructure Protection against IP Spoofing
| 19 DNSSEC Overview DNS Security Extensions Provides origin authentication Integrity assurance services for DNS data Authenticated denial of existence of DNS data
| 20 DNSSEC What is it? Keys Signatures Chain of trust
| 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 DNSSEC Benefits Protects the directory lookup Complements other technologies (https) Provides platform for other security improvements
| 23 DNSSEC Benefits Attract and retain security & reputation-focused registrants Create new service offerings Adding to trust overall
| 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 DNS Resolution Queries Originate with applications Handled on clients by stub resolvers Sent to and processed by recursive servers
| 26 Cache Poisoning
| 27 How can DNSSEC help?
| 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 Cryptographic Basics DNSSEC uses cryptography for 2 purposes: Integrity – is it “as sent”? Authenticity – Did it come from the right place?
| 30 Cryptographic Basics To provide this, we use Asymmetric cryptography Digital signatures
| 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 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 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 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 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 DNSKEY Key type (ZSK or KSK) Algorithm used Key tag Keying material
| 37 DNSKEY
| 38 DNSKEY
| 39 DNSKEY
| 40 Example of domain with unsigned zone
| 41 Example of domain with signed zone
| 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 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 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 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 Deploying DNSSEC Physical Security Environmental Tiers Access Control Intrusion Detection Disaster Recovery ICANN uses two key facilities, currently in Virginia & California
| 47 Deploying DNSSEC Physical Security Decisions are based on your risk profile Suitable power, air; protection from disaster Tiers Tamper evident packaging
| 48 Inside a key facility
| 49 Key Ceremonies
| 50 DNSSEC Deployment Sharing experiences from other registries Early adopters: Sweden, Netherlands, Brazil, Czechia gTLD registries: .org, Verisign, Afilias
| 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 State of DNSSEC Deployment Adoption rate higher in new top-level domains .bank & .insurance .ovh (French ISP) .frl (Friesland), .amsterdam, .paris .taxi
| 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 State of DNSSEC Deployment
| 55 State of DNSSEC Deployment
| 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 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 DNSSEC in Netherlands 49% of .NL domains secured with DNSSEC
| 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 DNSSEC in Czechia Over half of .CZ domains are signed
| 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 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 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 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 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 State of DNSSEC Deployment
| 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 KSK Rollover
| 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
Visit us at icann.org | 89 Engage with ICANN – Thank You and Questions

More Related Content

PPTX
DNS spoofing/poisoning Attack
byFatima Qayyum
 
PPTX
DNS Security Presentation ISSA
bySrikrupa Srivatsan
 
PDF
Introduction DNSSec
byAFRINIC
 
PDF
DNSSEC Validation Tutorial
byAPNIC
 
PDF
Intro to DNS
byThousandEyes
 
PDF
DNS Attacks
byHimanshu Prabhakar
 
PPTX
DNS Presentation
byShubham Srivastava
 
DOCX
DNS spoofing/poisoning Attack Report (Word Document)
byFatima Qayyum
 
DNS spoofing/poisoning Attack
byFatima Qayyum
 
DNS Security Presentation ISSA
bySrikrupa Srivatsan
 
Introduction DNSSec
byAFRINIC
 
DNSSEC Validation Tutorial
byAPNIC
 
Intro to DNS
byThousandEyes
 
DNS Attacks
byHimanshu Prabhakar
 
DNS Presentation
byShubham Srivastava
 
DNS spoofing/poisoning Attack Report (Word Document)
byFatima Qayyum
 

What's hot

PDF
DNSSEC - Domain Name System Security Extensions
byPeter R. Egli
 
PDF
Active Directory Trusts
byn|u - The Open Security Community
 
PPTX
Dhcp
byChinmoy Jena
 
PDF
Presentation on Domain Name System
byChinmay Joshi
 
PDF
Network Address Translation (NAT)
byJoud Khattab
 
PPTX
Domain name system
bymahakant sharma
 
PPT
Fortigate Training
byNCS Computech Ltd.
 
PPTX
Domain name system
bySiddharth Chandel
 
PPTX
Domain name system (dns)
byAtikur Rahman
 
PPT
Next generation firewall(ngfw)feature and benefits
byAnthony Daniel
 
PPTX
Dns presentation
byAnurag Pandey
 
PPT
Dns ppt
byBizuworkk Jemaneh
 
PPT
Virtual Private Network
byRajan Kumar
 
PPTX
Telnet & SSH
byNetProtocol Xpert
 
PDF
Attacker's Perspective of Active Directory
bySunny Neo
 
PDF
Encrypted DNS - DNS over TLS / DNS over HTTPS
byAlex Mayrhofer
 
PPT
Virtual private network
bySowmia Sathyan
 
PPTX
Dns server
bySubrata Kumer Paul
 
PPT
Domain Name System
byABDUL GAFOOR K V
 
PPTX
DHCP & DNS
byNetProtocol Xpert
 
DNSSEC - Domain Name System Security Extensions
byPeter R. Egli
 
Active Directory Trusts
byn|u - The Open Security Community
 
Dhcp
byChinmoy Jena
 
Presentation on Domain Name System
byChinmay Joshi
 
Network Address Translation (NAT)
byJoud Khattab
 
Domain name system
bymahakant sharma
 
Fortigate Training
byNCS Computech Ltd.
 
Domain name system
bySiddharth Chandel
 
Domain name system (dns)
byAtikur Rahman
 
Next generation firewall(ngfw)feature and benefits
byAnthony Daniel
 
Dns presentation
byAnurag Pandey
 
Dns ppt
byBizuworkk Jemaneh
 
Virtual Private Network
byRajan Kumar
 
Telnet & SSH
byNetProtocol Xpert
 
Attacker's Perspective of Active Directory
bySunny Neo
 
Encrypted DNS - DNS over TLS / DNS over HTTPS
byAlex Mayrhofer
 
Virtual private network
bySowmia Sathyan
 
Dns server
bySubrata Kumer Paul
 
Domain Name System
byABDUL GAFOOR K V
 
DHCP & DNS
byNetProtocol Xpert
 

Similar to DNS & DNSSEC

PDF
8 technical-dns-workshop-day4
byDNS Entrepreneurship Center
 
PDF
Understanding and Deploying DNSSEC, by Champika Wijayatunga [APRICOT 2015]
byAPNIC
 
PPTX
ION Malta - Introduction to DNSSEC
byDeploy360 Programme (Internet Society)
 
PDF
DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]
byAPNIC
 
PDF
ION Trinidad and Tobago - The Business Case for DNSSEC
byDeploy360 Programme (Internet Society)
 
PPTX
dnssec_networking_improvement_for_security.pptx
bypipopopo3
 
PDF
ION Islamabad - Deploying DNSSEC
byDeploy360 Programme (Internet Society)
 
PDF
An Overview of DNSSEC
byCarlos Martinez Cagnazzo
 
PDF
ION Hangzhou - Why Deploy DNSSEC?
byDeploy360 Programme (Internet Society)
 
PPTX
ION Bucharest - Deploying DNSSEC
byDeploy360 Programme (Internet Society)
 
PDF
Understanding the DNS & DNSSEC
byICANN
 
PPTX
DNSandDNSSecurity (1).pptx
byAisha Siddiqui
 
PDF
DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)
byDeploy360 Programme (Internet Society)
 
PDF
DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)
byInternet Society
 
PPTX
DNS Security (DNSSEC) With BIG-IP Global Traffic Manager
byDSorensenCPR
 
PDF
DNS Security
byjohnmcclure00
 
PDF
CNIT 40: 6: DNSSEC and beyond
bySam Bowne
 
PPTX
AEP Netwrorks Keyper HSM & ICANN DNSSEC
byChin Wan Lim
 
PDF
Hardening the Core of the Internet
byRIPE NCC
 
PPTX
Phreebird Suite 1.0: Introducing the Domain Key Infrastructure
byDan Kaminsky
 
8 technical-dns-workshop-day4
byDNS Entrepreneurship Center
 
Understanding and Deploying DNSSEC, by Champika Wijayatunga [APRICOT 2015]
byAPNIC
 
ION Malta - Introduction to DNSSEC
byDeploy360 Programme (Internet Society)
 
DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]
byAPNIC
 
ION Trinidad and Tobago - The Business Case for DNSSEC
byDeploy360 Programme (Internet Society)
 
dnssec_networking_improvement_for_security.pptx
bypipopopo3
 
ION Islamabad - Deploying DNSSEC
byDeploy360 Programme (Internet Society)
 
An Overview of DNSSEC
byCarlos Martinez Cagnazzo
 
ION Hangzhou - Why Deploy DNSSEC?
byDeploy360 Programme (Internet Society)
 
ION Bucharest - Deploying DNSSEC
byDeploy360 Programme (Internet Society)
 
Understanding the DNS & DNSSEC
byICANN
 
DNSandDNSSecurity (1).pptx
byAisha Siddiqui
 
DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)
byDeploy360 Programme (Internet Society)
 
DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)
byInternet Society
 
DNS Security (DNSSEC) With BIG-IP Global Traffic Manager
byDSorensenCPR
 
DNS Security
byjohnmcclure00
 
CNIT 40: 6: DNSSEC and beyond
bySam Bowne
 
AEP Netwrorks Keyper HSM & ICANN DNSSEC
byChin Wan Lim
 
Hardening the Core of the Internet
byRIPE NCC
 
Phreebird Suite 1.0: Introducing the Domain Key Infrastructure
byDan Kaminsky
 

More from APNIC

PPTX
APNIC Report, presented at APAN 60 by Thy Boskovic
byAPNIC
 
PDF
APNIC Update, presented at PHNOG 2025 by Shane Hermoso
byAPNIC
 
PDF
RPKI Status Update, presented by Makito Lay at IDNOG 10
byAPNIC
 
PDF
The Internet -By the Numbers, Sri Lanka Edition
byAPNIC
 
PDF
Triggering QUIC, presented by Geoff Huston at IETF 123
byAPNIC
 
PDF
DNSSEC Made Easy, presented at PHNOG 2025
byAPNIC
 
PDF
BGP Security Best Practices that Matter, presented at PHNOG 2025
byAPNIC
 
PDF
APNIC's Role in the Pacific Islands, presented at Pacific IGF 2205
byAPNIC
 
PDF
IPv6 Deployment and Best Practices, presented by Makito Lay
byAPNIC
 
PDF
Cleaning up your RPKI invalids, presented at PacNOG 35
byAPNIC
 
PDF
The Internet - By the numbers, presented at npNOG 11
byAPNIC
 
PDF
Transmission Control Protocol (TCP) and Starlink
byAPNIC
 
PDF
DDoS in India, presented at INNOG 8 by Dave Phelan
byAPNIC
 
PDF
Global Networking Trends, presented at the India ISP Conclave 2025
byAPNIC
 
PDF
Make DDoS expensive for the threat actors
byAPNIC
 
PDF
Fast Reroute in SR-MPLS, presented at bdNOG 19
byAPNIC
 
PDF
DDos Mitigation Strategie, presented at bdNOG 19
byAPNIC
 
PDF
ICP -2 Review – What It Is, and How to Participate and Provide Your Feedback
byAPNIC
 
PDF
APNIC Update - Global Synergy among the RIRs: Connecting the Regions
byAPNIC
 
PDF
Measuring Starlink Protocol Performance, presented at LACNIC 43
byAPNIC
 
APNIC Report, presented at APAN 60 by Thy Boskovic
byAPNIC
 
APNIC Update, presented at PHNOG 2025 by Shane Hermoso
byAPNIC
 
RPKI Status Update, presented by Makito Lay at IDNOG 10
byAPNIC
 
The Internet -By the Numbers, Sri Lanka Edition
byAPNIC
 
Triggering QUIC, presented by Geoff Huston at IETF 123
byAPNIC
 
DNSSEC Made Easy, presented at PHNOG 2025
byAPNIC
 
BGP Security Best Practices that Matter, presented at PHNOG 2025
byAPNIC
 
APNIC's Role in the Pacific Islands, presented at Pacific IGF 2205
byAPNIC
 
IPv6 Deployment and Best Practices, presented by Makito Lay
byAPNIC
 
Cleaning up your RPKI invalids, presented at PacNOG 35
byAPNIC
 
The Internet - By the numbers, presented at npNOG 11
byAPNIC
 
Transmission Control Protocol (TCP) and Starlink
byAPNIC
 
DDoS in India, presented at INNOG 8 by Dave Phelan
byAPNIC
 
Global Networking Trends, presented at the India ISP Conclave 2025
byAPNIC
 
Make DDoS expensive for the threat actors
byAPNIC
 
Fast Reroute in SR-MPLS, presented at bdNOG 19
byAPNIC
 
DDos Mitigation Strategie, presented at bdNOG 19
byAPNIC
 
ICP -2 Review – What It Is, and How to Participate and Provide Your Feedback
byAPNIC
 
APNIC Update - Global Synergy among the RIRs: Connecting the Regions
byAPNIC
 
Measuring Starlink Protocol Performance, presented at LACNIC 43
byAPNIC
 

DNS & DNSSEC

  • 1.
    | 1 DNS &DNSSEC 26 February 2018 APRICOT Patrick Jones & John Crain
  • 2.
  • 3.
    | 3 DNSSEC Overview Howmuch 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 Howmuch 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 isDNSSEC? ¤ 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 issuesleading to DNSSEC First, a bit of history Major flaws in DNS discovered in 1990s Trust in Cyberspace published in 1999
  • 8.
    | 8 DNS Vulnerabilities Anyprotocol is likely to have security flaws Using reverse DNS to impersonate hosts Software bugs Bad crypto Information leaks Cache poisoning
  • 9.
    | 9 DNSSEC History 2004DNS Threat Analysis Packet interception ID guessing and query prediction Name chaining Betrayal by trusted server Denial of service
  • 10.
    | 10 DNS Pointsof Attack
  • 11.
    | 11 DNSSEC Beginnings Addingsecurity 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 Growthin 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 ofDNSSEC 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 DoesDNSSEC 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 doesDNSSEC protect?
  • 16.
    | 16 Other technologiesleveraging 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 DNSSecurity Extensions Provides digital signatures that allow validating clients to prove that DNS data was not modified in transit
  • 18.
    | 18 DNSSEC Overview Notdesigned for Protection against DDoS attacks Handling privacy Public Key Infrastructure Protection against IP Spoofing
  • 19.
    | 19 DNSSEC Overview DNSSecurity Extensions Provides origin authentication Integrity assurance services for DNS data Authenticated denial of existence of DNS data
  • 20.
    | 20 DNSSEC What isit? 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 thedirectory lookup Complements other technologies (https) Provides platform for other security improvements
  • 23.
    | 23 DNSSEC Benefits Attract andretain security & reputation-focused registrants Create new service offerings Adding to trust overall
  • 24.
    | 24 DNS Resolution Theprocess 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 Originatewith applications Handled on clients by stub resolvers Sent to and processed by recursive servers
  • 26.
  • 27.
    | 27 How canDNSSEC 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 DNSSECuses cryptography for 2 purposes: Integrity – is it “as sent”? Authenticity – Did it come from the right place?
  • 30.
    | 30 Cryptographic Basics Toprovide this, we use Asymmetric cryptography Digital signatures
  • 31.
    | 31 Cryptographic Basics AsymmetricCryptography 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 AsymmetricCryptography 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 MXrecords – 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 changesto 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 Thezone’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.
  • 38.
  • 39.
  • 40.
    | 40 Example ofdomain with unsigned zone
  • 41.
    | 41 Example ofdomain with signed zone
  • 42.
    | 42 DNSSEC changesto 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 statusof 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 statusof 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 PhysicalSecurity Environmental Tiers Access Control Intrusion Detection Disaster Recovery ICANN uses two key facilities, currently in Virginia & California
  • 47.
    | 47 Deploying DNSSEC PhysicalSecurity Decisions are based on your risk profile Suitable power, air; protection from disaster Tiers Tamper evident packaging
  • 48.
    | 48 Inside akey facility
  • 49.
  • 50.
    | 50 DNSSEC Deployment Sharingexperiences from other registries Early adopters: Sweden, Netherlands, Brazil, Czechia gTLD registries: .org, Verisign, Afilias
  • 51.
    | 51 State ofDNSSEC 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 ofDNSSEC Deployment Adoption rate higher in new top-level domains .bank & .insurance .ovh (French ISP) .frl (Friesland), .amsterdam, .paris .taxi
  • 53.
    | 53 State ofDNSSEC 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 ofDNSSEC Deployment
  • 55.
    | 55 State ofDNSSEC 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 inSweden 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 inNetherlands 49% of .NL domains secured with DNSSEC
  • 59.
    | 59 DNSSEC inNetherlands .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 inCzechia Over half of .CZ domains are signed
  • 61.
    | 61 DNSSEC inCzechia 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 inNorway 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 inCosta 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 inUnited 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 inBrasil NIC.br was another early adopter 1m domains signed out of 3.9m in .br See https://registro.br/estatisticas.html
  • 66.
    | 66 State ofDNSSEC 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 KSKRollover
  • 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 isICANN 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 ¤ Whenyou 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 Public17 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 hasKSK-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 forkey 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 Public17 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 analysisby 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 dovalidators 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 tothe 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 ¤ Wedo 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 YouNeed 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 awarewhether 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 ToUpdate 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 toSee 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 Stepsto 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 MoreInformation 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 aticann.org | 89 Engage with ICANN – Thank You and Questions