Root KSK Roll Update DNS-OARC 27 Matt Larson, VP of Research

Slides:



Advertisements
Similar presentations
IANA Status Update ARIN XXVI meeting, Atlanta Barbara Roseman October 2010.
Advertisements

1.ORG DNSSEC Testbed Deployment Edmon Chung Creative Director Afilias Perth, AU 2 March, 2006.
Chapter 23: ARP, ICMP, DHCP IS333 Spring 2015.
70-293: MCSE Guide to Planning a Microsoft Windows Server 2003 Network, Enhanced Chapter 7: Planning a DNS Strategy.
Domain Name System | DNSSEC. 2  Internet Protocol address uniquely identifies laptops or phones or other devices  The Domain Name System matches IP.
Tyre Kicking the DNS Testing Transport Considerations of Rolling Roots Geoff Huston APNIC.
Rev Mats Dufberg TeliaSonera, Sweden Resolving DNSsec.
© 2015 ISC November 2013 Sunset for the DLV?. © 2015 ISC Background (c) Interested
Triggers A Quick Reference and Summary BIT 275. Triggers SQL code permits you to access only one table for an INSERT, UPDATE, or DELETE statement. The.
Root Zone KSK: The Road Ahead Edward Lewis | DNS-OARC & RIPE DNSWG | May 2015
Rolling the Keys of the DNS Root Zone Geoff Huston APNIC Labs.
Port and Message ID Analysis of Resolvers Querying.com/.net Name Servers David Blacka Matt Larson September 24, 2008 DNS OARC Meeting, Ottawa, Canada.
1 Madison, Wisconsin 9 September14. 2 Security Overlays on Core Internet Protocols – DNSSEC and RPKI Mark Kosters ARIN Engineering.
© 2015 ISC November 2013 Sunset for the DLV?. © 2015 ISC Background (c) Interested
Rolling the Root Geoff Huston APNIC Labs. Use of DNSSEC in Today’s Internet.
DNS Measurement at a Root Server Nevil Brownlee, kc Claffy and Evi Nemeth Presented by Zhengxiang Pan Mar. 27 th, 2003.
Log on to Your user name will be the same as your current address except after sign you must enter “irs-mos.org”.
Using Workflow With Dataforms Tim Borntreger, Director of Client Services.
Root Zone KSK Maintenance Jaap Akkerhuis | ENOG -10 | October 2015.
Root Zone KSK: After 5 years Elise Gerich | APNIC 40 | September 2015.
DNSSec.TLD is signed! What next? V.Dolmatov November 2011.
System Administration(SAD622S) Name of Presenter: Shadreck Chitauro Lecturer 18 July 2016 Faculty of Computing and Informatics.
Rolling the Root Geoff Huston APNIC Labs March 2016.
Increasing the Zone Signing Key Size for the Root Zone
Rolling the Root Zone DNSSEC Key Signing Key
KSK Rollover Update David Conrad, CTO ICANN 59 – ccNSO Members Meeting
Finance Brief June 2016.
IP and MAC Addresses, DNS Servers
Agenda DNSSEC automation overview How to implement it in FRED
DNS Team IETF 99 Hackathon.
KSK Rollover Update David Conrad, CTO ICANN 59 – GAC 29 June 2017.
Containers: The new network endpoint
Root Zone KSK Rollover: delay and next steps
Living on the Edge: (Re)focus DNS Efforts on the End-Points
Training Demo: Mary Kay Vendor Clients
Geoff Huston APNIC Labs September 2017
Root Zone KSK Rollover Update
draft-huston-kskroll-sentinel
Hervey Allen Chris Evans Phil Regnauld September 3 – 4, 2009
CZ.NIC in a nutshell Domain, DNSSEC, Turris Project and others
The Last Link in the DNSSEC Chain of Trust
DANE: The Future of Transport Layer Security (TLS)
R. Kevin Oberman ESnet February 5, 2009
nsd a Name Service Daemon
Root KSK Rollover Update (or, We're really doing it this time)
New Functionality in ARIN Online
Peter Solagna – EGI Foundation
Prizes and Awards (PandA)
Budget Prep FY2019 Lessons Learned and Future Enhancements
Repetition Structures
Measuring KSK Roll Readiness
The Scientific Method.
Troubleshooting beyond what you understand
Staying Drug Free.
How to keep your Enterprise GIS Project on Track
Geoff Huston APNIC Labs
Orchestrating Intelligent Systems
We know who they are and what they do, but how do we help them?
Measuring KSK Roll Readiness
CBMS Transformation Address Tip Sheet
“DNS Flag day” A tale of five ccTLDs Hugo Salgado, .CL
DNS operator transfers with DNSSEC
DNSSEC & KSK Rollover Patrick Jones Middle East DNS Forum & APTLD 75
The Troubleshooting theory
LO1 – Understand Computer Hardware
DNS Security The Domain Name Service (DNS) translates human-readable names to IP addresses E.g., thesiger.cs.ucla.edu translates to DNS.
The Curious Case of the Crippling DS record
Trust Anchor Signals from Custom Applications
What part of “NO” is so hard for the DNS to understand?
Neda Kianpour - Lead Network Engineer - Salesforce
Presentation transcript:

Root KSK Roll Update DNS-OARC 27 Matt Larson, VP of Research 29 September 2017

Further analysis by OCTO Research ICANN OCTO Research did an analysis similar to Duane’s Analyzed query data from B, D, F and L Combined with Verisign’s A & J data For 1 September 2017 through 25 September 2017 Results: Total number of unique addresses reporting key tag data: 11,692 Total number that only ever reports KSK-2010: 577 4.93% of reporting validators are not ready for the KSK roll on 11 October 2017 Analysis is complicated Dynamic IPs make the situation look worse by inflating true number of sources Forwarders make the situation look better if they obscure multiple validators behind the forwarder BIND reports trust anchors even if not validating

Why do validators report just KSK-2010? Multiple reasons suspected or confirmed: BIND reports trust anchors even if not validating Old configurations pre-dating automatic update support E.g., BIND’s trusted-keys instead of managed-keys or dnssec-validation auto Bugs in automatic update or key tag signaling support 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

Issues and thoughts 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 data will help Query data from TLD or other popular zones would also help Mitigation is hard We’ve already had a multi-year campaign to reach operators Implementation-specific problems don’t make the problem easier

What we just announced We postponed the root KSK roll until we can gather more information and understand the situation better The delay will be at least one quarter We have not yet determined how many quarters to delay We will at least partially mitigate

Next steps: you can help Please work with us to identify and investigate sources reporting only KSK-2010 We will publish the entire list of sources publicly Want to track down as many as possible to understand behavior Old configuration, bug, operator error, something else? If you run a resolver that forwards, please start logging RFC 8145 queries We want to talk with you Please help us as we reduce the number of sources reporting only KSK-2010 We recognize not all validators are equal We have already been working with vendors to get issues addressed If you are familiar with a 5011 or 8145 implementation, please look carefully at that code for edge cases

Engage with ICANN – Thank You and Questions