RFC 7706: Decreasing Access Time to Root Servers by Running One on Loopback A good idea or not? Petr Špaček • petr.spacek@nic.cz • 2017-09-29.

Slides:



Advertisements
Similar presentations
Review iClickers. Ch 1: The Importance of DNS Security.
Advertisements

L-Root: Expanding Distribution in Africa. 2 One of 13 root name servers containing Internet Protocol addresses Operated by ICANN using anycast technology.
State of DNS Security Extensions Edward Lewis February 26, 2001 APRICOT 2001 Panel.
Measuring DNSSEC validation i.e. how to do it Ólafur Guðmundsson Steve Crocker ogud, steve at shinkuro.com.
DNS Security Extension (DNSSEC). Why DNSSEC? DNS is not secure –Applications depend on DNS ►Known vulnerabilities DNSSEC protects against data spoofing.
1 SecSpider: Distributed DNSSEC Monitoring Eric Osterweil Michael Ryan Dan Massey Lixia Zhang.
© Afilias Limitedwww.afilias.info SM Challenges of Deploying DNSSEC: Prepare your ccTLD with Secondary DNS services LACNIC Meeting May 2010 Presented by:
Domain Name System Security Extensions (DNSSEC) Hackers 2.
Peter Janssen, EURid.eu Ljubljana, RIPE 64, 2012 Peter Janssen, EURid.eu Ljubljana, RIPE 64, April
DNS Workbench Update DNS-OARC Workshop Phoenix, Arizona, USA Sat Oct 5, Jelte Jansen, Antoin Verschuren.
1 DNSSEC at ESnet ESCC/Internet2 Joint Techs Workshop July 19, 2006 R. Kevin Oberman Network Engineer Lawrence Berkeley National Laboratory.
Geoff Huston APNIC Labs
Test cases for domain checks – a step towards a best practice Mats Dufberg,.SE Sandoche Balakrichenan, AFNIC.
70-291: MCSE Guide to Managing a Microsoft Windows Server 2003 Network Chapter 7: Domain Name System.
October 8, 2015 University of Tulsa - Center for Information Security Microsoft Windows 2000 DNS October 8, 2015.
DNS Security Pacific IT Pros Nov. 5, Topics DoS Attacks on DNS Servers DoS Attacks by DNS Servers Poisoning DNS Records Monitoring DNS Traffic Leakage.
Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. DNSSEC An Update Olaf M. Kolkman
DNS Dynamic Update Performance Study The Purpose Dynamic update and XFR is key approach to perform zone data replication and synchronization,
Module 6: Managing and Monitoring Domain Name System (DNS)
1 DNSSEC Transforming a protocol bug into an admin tool Lutz Donnerhacke db089309: 1c1c 6311 ef09 d819 e029 65be bfb6 c9cb.
Measuring DNSSEC Use Geoff Huston APNIC Labs. We all know…
* Agenda  What is the DNS ?  Poisoning the cache  Short term solution  Long term solution.
Rolling the Root Geoff Huston APNIC Labs. Use of DNSSEC in Today’s Internet.
Olaf M. Kolkman. IETF55, November 2002, Atlanta GA. 1 key-signing key flag [1] & wildcard-optimization [2] Olaf Kolkman [1] with.
What if Everyone Did It? Geoff Huston APNIC Labs.
Ch 6: DNSSEC and Beyond Updated DNSSEC Objectives of DNSSEC Data origin authentication – Assurance that the requested data came from the genuine.
&. & DNS and IPv6 IPv6 Summit, Canberra 31st October & 1 st November 2005 Chris Wright, Chief Technology Officer &
DNS Cache Poisoning (pretending to be the authoritative zone) ns.example.co m Webserver ( ) DNS Caching Server Client I want to access
EDNS0 - the need for speed Lawrence Conroy Roke Manor Research This draft has been produced by Lawrence Conroy
Using Digital Signature with DNS. DNS structure Virtually every application uses the Domain Name System (DNS). DNS database maps: –Name to IP address.
Rolling the Root Geoff Huston APNIC Labs March 2016.
Increasing the Zone Signing Key Size for the Root Zone
BIND 10 DNS Project Status + DNS Resolver Status/Plans Shane Kerr 23 January 2013.
High performance recursive DNS solution
Rolling the Root Zone DNSSEC Key Signing Key
A Speculation on DNS DDOS
Geoff Huston APNIC March 2017
DNS Team IETF 99 Hackathon.
DNS Operation And Security Protection
Testing DNS resolvers (as) in real world
State of DNSSEC deployment ISOC Advisory Council
Geoff Huston APNIC Labs
Geoff Huston APNIC Labs September 2017
DNS Session 5 Additional Topics
draft-huston-kskroll-sentinel
DNS Cache Poisoning Attack
CZ.NIC in a nutshell Domain, DNSSEC, Turris Project and others
A Speculation on DNS DDOS
A Longitudinal, End-to-End View of the DNSSEC Ecosystem
Chapter 19 Domain Name System (DNS)
DNSSEC Basics, Risks and Benefits
D* (DNS, and DNSSEC and DDOS)
Re-Engineering the Root of the DNS
Root KSK Roll Update DNS-OARC 27 Matt Larson, VP of Research
A New Approach to DNS Security (DNSSEC)
Measuring KSK Roll Readiness
Casey Deccio Sandia National Laboratories
IETF DNSOP WG Update – and some DPRIVE
Measuring KSK Roll Readiness
“DNS Flag day” A tale of five ccTLDs Hugo Salgado, .CL
Domain Name System: DNS
DNSSEC Status Update in UA
Windows Name Resolution
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?
Securing Your DNS Infrastructure in 5 Minutes
Neda Kianpour - Lead Network Engineer - Salesforce
Presentation transcript:

RFC 7706: Decreasing Access Time to Root Servers by Running One on Loopback A good idea or not? Petr Špaček • petr.spacek@nic.cz • 2017-09-29

Talk outline Problems with RFC 7706 Comparison with RFC 8198 theoretical experimental Possible improvements Shameless self-promotion

RFC 7706: Root on loopback "Because of the significant operational risks described in this document, distributions of recursive DNS servers MUST NOT include configuration for the design described here." Is it worth the trouble?

RFC 7706: Root on loopback recap Primary goals faster negative responses preventing queries from being visible faster positive responses Side effects higher resiliency? maybe?

RFC 8198: Aggressive cache recap Primary goals faster negative responses faster positive responses (wildcards) Depends on data in cache Side effects preventing queries from being visible

RFC 7706 and 8198 overlap RFC 8198 almost provides what 7706 calls for How effective is 8198? Gut feeling: good Measurements?

Experimental setup Replay PCAP to Knot Resolver Log cache accesses Replay cache accesses to RFC 2308 & 8198 simulator Record hit/miss for nodes in the root zone

Data sets 4+ days of traffic in PCAP Public Open Resolver ran by CZ.NIC ("big") 3500 q/second anonymised Two households in Czech Republic ("small") dominated by "noise"

Tools Knot Resolver 1.3 patched to log cache access Drool to replay traffic RFC 2308 & 8198 simulator: https://github.com/pspacek/dnscache_simulator unlimited cache size

Results for root zone data Households = noise (no further analysis) Public resolver = RFC 8198 show case only 0,25 % cache misses for root zone data About 3300 cache misses per day 73 % of root zone ~ 6600 UDP packets Public resolver 4 days of data: 300 milions user queries 784 milions cache accesses 5 milion cache accesses for root data

Data from the public resolver Data from the public resolver. Data from households not shown because these are dominated by noise.

4th minute 2nd minute 4th minute Data from the public resolver. Data from households not shown because these are dominated by noise. 2nd minute

Root zone content Minimal TTL = 1 day 1548 nodes with NSEC RR 4497 non-glue non-RRSIG RRs AXFR 388 TCP packets 1 363 891 bytes

RFC 7706's goals except for 0,25 % of queries ☑ Faster negative responses ☑ Preventing queries from being visible ☑ Provided by RFC 8198 except for 0,25 % of queries ☐ Higher resiliency not provided by RFC 8198 but ...

Leftovers after RFC 8198 0,25 % cache miss rate caused by empty/expired cache Pre-fill cache to get to 0 % Min TTL 1 day = 1 AXFR/day AXFR/day requires just 6 % of packets for queries Higher resiliency use a variant of draft-tale-dnsop-serve-stale-01

Is RFC 7706 worth the trouble? NO! Replace it with RFC 8198 cache pre-fill open question: AXFR from where? a variant of draft serve-stale Watch out for Knot Resolver in 2018!

Thanks to Ondřej Surý!

Stay tuned for Knot news!

Knot news for October 2017 Knot DNS 2.6 Knot Resolver 2.0 Automatic DNSSEC algorithm rollover In-line signing on slave Knot Resolver 2.0 RFC 8198 aka Aggressive Use of DNSSEC-Validated Cache