- DNSSEC and RPKI are protocols that aim to secure the core of the Internet by adding authentication and integrity to DNS and routing data.
- DNSSEC works by digitally signing DNS records with private keys, and publishing the signatures and corresponding public keys. It builds a chain of trust from the root zone down by including fingerprints of child keys in parent zones.
- RPKI uses a similar approach to secure routing by digitally signing routing announcements and filtering invalid routes. It establishes a framework for routers to validate the authenticity and authorization of routing information.
This document provides an overview of DNSSEC (Domain Name System Security Extensions). It discusses cryptography concepts used in DNSSEC like public-key cryptography, hashing algorithms, and digital signatures. It explains how DNSSEC uses these concepts to provide data integrity and authentication for DNS responses through the use of new resource records like RRSIG, DNSKEY, DS, and NSEC. It also discusses how DNSSEC establishes trust chains to validate signatures up to the root zone, and how "denial of existence" responses are signed using NSEC records.
Signing DNSSEC answers on the fly at the edge: challenges and solutionsAPNIC
Signing DNSSEC answers on the fly at the edge: challenges and solutions, by Jono Bergquist.
A presentation given at the APNIC 40 APOPS 2 session on Tue, 8 Sep 2015.
This document provides an overview of how DNS lookups generally work, with a focus on DNS security (DNSSEC). It explains the standard DNS lookup process, where a user's request is recursively resolved through root servers, TLD servers, and name servers until an IP address is returned. It then discusses DNSSEC in more detail, explaining the new record types it introduces like DNSKEY, RRSIG, DS, and NSEC to authenticate records and prove non-existence. The document emphasizes that while DNSSEC aims to validate records are authentic, recursive resolvers still may not perform validation, limiting its effectiveness. It also provides steps to configure a zone with DNSSEC.
DNS OARC 27: DNS over IPv6 - A study in fragmentationAPNIC
APNIC Chief Scientist Geoff Huston discusses his work at DNS OARC 27 analysing the DNS risks when using IPv6 transport, with his results indicating that DNSSEC will not work well over IPv6 and depends on IPv4 for the fall-back.
Carlos García - Pentesting Active Directory Forests [rooted2019]RootedCON
The document discusses penetration testing of Active Directory forests and trusts. It begins with an introduction to forests, domains, and trust types. It then covers authentication protocols like NTLM and Kerberos across trusts. Next, it discusses techniques for enumerating trusts and mapping the trust relationships. The document outlines common attacks when domain admin privileges are available, such as using Golden Tickets and SID history exploitation. For situations without domain admin, it recommends reconnaissance of trusts and objects to map a path to privileged accounts.
New DNS Traffic Analysis Techniques to Identify Global Internet ThreatsOpenDNS
Leveraging DNS data to detect new Internet threats has been gaining in popularity in the past few years. However, most industry and academic work examines DNS solely from the authoritative layer through the use of passive DNS. This presentation covers three novel methods that can be used to detect network threats at an Internet scale by analyzing DNS traffic below and above the recursive layer, monitoring malware hosting IP infrastructures, and applying graph analytics on DNS lookup patterns.
Google has changed Chrome's code to enforce HTTPS encryption on all ".dev" domains by default. This causes problems for developers who use ".dev" locally without HTTPS. Alternatives for local domain names include subdomains of owned domains, reserved domains like ".test", or protocols besides DNS like LLMNR and mDNS. Unbound and BIND can configure local zones to resolve names without internet access.
The document provides an overview of DNS (Domain Name System) security. It begins with introductions and defines DNS as the core internet protocol that converts domain names to IP addresses. It then discusses some security issues with DNS like hijacking and cache poisoning since DNS data is not encrypted or authenticated. It provides examples of how DNS works through a system of delegation from the root zone down. It explains how DNSSEC aims to address security but has limitations. The document demonstrates DNSSEC in action by showing signed responses from the root zone down to an example domain.
This document provides an overview of DNSSEC (Domain Name System Security Extensions). It discusses cryptography concepts used in DNSSEC like public-key cryptography, hashing algorithms, and digital signatures. It explains how DNSSEC uses these concepts to provide data integrity and authentication for DNS responses through the use of new resource records like RRSIG, DNSKEY, DS, and NSEC. It also discusses how DNSSEC establishes trust chains to validate signatures up to the root zone, and how "denial of existence" responses are signed using NSEC records.
Signing DNSSEC answers on the fly at the edge: challenges and solutionsAPNIC
Signing DNSSEC answers on the fly at the edge: challenges and solutions, by Jono Bergquist.
A presentation given at the APNIC 40 APOPS 2 session on Tue, 8 Sep 2015.
This document provides an overview of how DNS lookups generally work, with a focus on DNS security (DNSSEC). It explains the standard DNS lookup process, where a user's request is recursively resolved through root servers, TLD servers, and name servers until an IP address is returned. It then discusses DNSSEC in more detail, explaining the new record types it introduces like DNSKEY, RRSIG, DS, and NSEC to authenticate records and prove non-existence. The document emphasizes that while DNSSEC aims to validate records are authentic, recursive resolvers still may not perform validation, limiting its effectiveness. It also provides steps to configure a zone with DNSSEC.
DNS OARC 27: DNS over IPv6 - A study in fragmentationAPNIC
APNIC Chief Scientist Geoff Huston discusses his work at DNS OARC 27 analysing the DNS risks when using IPv6 transport, with his results indicating that DNSSEC will not work well over IPv6 and depends on IPv4 for the fall-back.
Carlos García - Pentesting Active Directory Forests [rooted2019]RootedCON
The document discusses penetration testing of Active Directory forests and trusts. It begins with an introduction to forests, domains, and trust types. It then covers authentication protocols like NTLM and Kerberos across trusts. Next, it discusses techniques for enumerating trusts and mapping the trust relationships. The document outlines common attacks when domain admin privileges are available, such as using Golden Tickets and SID history exploitation. For situations without domain admin, it recommends reconnaissance of trusts and objects to map a path to privileged accounts.
New DNS Traffic Analysis Techniques to Identify Global Internet ThreatsOpenDNS
Leveraging DNS data to detect new Internet threats has been gaining in popularity in the past few years. However, most industry and academic work examines DNS solely from the authoritative layer through the use of passive DNS. This presentation covers three novel methods that can be used to detect network threats at an Internet scale by analyzing DNS traffic below and above the recursive layer, monitoring malware hosting IP infrastructures, and applying graph analytics on DNS lookup patterns.
Google has changed Chrome's code to enforce HTTPS encryption on all ".dev" domains by default. This causes problems for developers who use ".dev" locally without HTTPS. Alternatives for local domain names include subdomains of owned domains, reserved domains like ".test", or protocols besides DNS like LLMNR and mDNS. Unbound and BIND can configure local zones to resolve names without internet access.
The document provides an overview of DNS (Domain Name System) security. It begins with introductions and defines DNS as the core internet protocol that converts domain names to IP addresses. It then discusses some security issues with DNS like hijacking and cache poisoning since DNS data is not encrypted or authenticated. It provides examples of how DNS works through a system of delegation from the root zone down. It explains how DNSSEC aims to address security but has limitations. The document demonstrates DNSSEC in action by showing signed responses from the root zone down to an example domain.
Jan-Piet Mens gave a presentation on DNSSEC and securing DNS with cryptography. He discussed how DNSSEC works by adding digital signatures to DNS records to authenticate their source and integrity. It provides data origin authentication and integrity but does not encrypt data. He demonstrated how to configure and use DNSSEC with Unbound and PowerDNS to enable validating queries. Attendees were encouraged to set up test environments to better understand DNSSEC.
The document discusses DNS over HTTPS (DoH), DNS over TLS (DoT), and Encrypted Server Name Indication (ESNI). It explains that DoH and DoT encrypt DNS queries and responses for increased privacy and security compared to traditional DNS. However, ESNI is also discussed as a solution to further improve privacy by encrypting the server name in the TLS handshake. Concerns about the potential use of these protocols by malware for command and control are also raised.
Part 3 - Local Name Resolution in Linux, FreeBSD and macOS/iOSMen and Mice
The focus of this webinar will be to take a deeper look into this local name-resolution system and the implementations for other Unix systems like Linux and FreeBSD. Linux’s new über-Daemon “systemd” supports both mDNS and the Windows LLMNR (Link-Local-Multicast-Name-Resolution). We will also show how well a Systemd-Linux behaves in heterogenous networks running both Windows and macOS.
This webinar is designed as an easy-to-follow tutorial on DNSSEC signing a zone for DNS admins. Our focus will be on DNSSEC zone signing automation with the Knot DNS Server and BIND 9.
Encrypted DNS - DNS over TLS / DNS over HTTPSAlex Mayrhofer
Encryption is coming to mainstream DNS. This briefing discusses the history, protocols and architecture of encrypted DNS, specifically DNS over TLS and DNS over HTTPS. It also describes the impact of DoT and DoH on various operational models.
This briefing was given during DNSheads Vienna #5 at the nic.at office in Vienna on Jan 30 2018.
The document describes a technique for covertly exfiltrating data from an infected client by encoding it in DNS queries to an evil name server. The infected client breaks sensitive files into blocks, encodes each block, and queries the blocks' names from the evil name server. The server collects the queries to reconstruct the original data. Modern network security systems like next-gen firewalls and intrusion prevention systems cannot detect this technique as the DNS queries appear normal and are mixed with legitimate traffic. The document proposes filtering suspicious domains and analyzing DNS query patterns and volumes to identify exfiltration attempts.
Part 2 - Local Name Resolution in Windows NetworksMen and Mice
This webinar discusses local name resolution protocols in Windows networks. It focuses on Link Local Multicast Name Resolution (LLMNR) and Peer Name Resolution Protocol (PNRP). LLMNR provides serverless name resolution on the local subnet using multicast queries. PNRP is a peer-to-peer name resolution protocol that operates over IPv6 or IPv4-IPv6 tunnels. The webinar explains how these protocols work, how to configure and use them, and potential security issues to be aware of when using them. It also advertises upcoming Men & Mice training courses on DNS and name resolution topics.
DNSSEC - Domain Name System Security ExtensionsPeter R. Egli
This document introduces DNS Security Extensions (DNSSEC) which aims to secure DNS queries and information by adding digital signatures to DNS response records. It discusses security problems with the current DNS system like cache poisoning and spoofing attacks. DNSSEC uses cryptographic keys and signatures to authenticate DNS responses and establish a chain of trust. While DNSSEC adds security, its deployment has been gradual due to complexity and the need for widespread implementation to provide full benefits.
The DNSSEC key signing key (or KSK) of the DNS root zone will be changed in the summer of 2017. During the time between July and October, all DNSSEC validating resolver need to get the new key material.
In this webinar we explain the KSK roll, how DNS resolver will load the new KSK with the RFC 5011 protocol and how a DNS administrator can verify that the new KSK is present in the resolvers configuration.
DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...Felipe Prado
This document discusses a DNS cache poisoning attack that exploits IP fragmentation. It begins with background on DNS and DNSSEC. It then explains how predictable IPIDs in DNS responses can be inferred, allowing an off-path attacker to poison caches with few attempts. The attack works across IPv4 and IPv6 by targeting predictable timing of DNS requests. Mitigations are discussed but the attack remains effective against current recommendations.
This document provides an overview and summary of a webinar for registrars about DNSSEC and PIR's implementation of DNSSEC for the .ORG top-level domain. The webinar covers topics like how DNSSEC works to secure DNS data and prevent cache poisoning, the benefits of DNSSEC for end users, registrants and registrars, PIR's timeline and process for implementing DNSSEC for .ORG, an introduction to DNSSEC terminology, changes to the EPP protocol and registry database, and resources for registrars. The presentation aims to educate registrars on DNSSEC and PIR's rollout so they can support it for domains under .ORG.
- The document discusses nameserver redirection attacks and SQL injection attacks against domain name registry systems.
- It provides examples of how attackers can change domain name registrations through SQL injection or by directly modifying registry databases to redirect traffic to malicious sites.
- A live demonstration shows how SQL injection can be used to enumerate and modify a registry database, redirecting a domain to a rogue IP address and server.
- Mitigation strategies include securing web applications, validating input, using authentication for changes, and information sharing about attacks.
Grehack2013-RuoAndo-Unraveling large scale geographical distribution of vulne...Ruo Ando
Feasibility study of large scale attacks of DNS. We have found 10,334,293 DNS servers in 34 hours of first measurement (2013/05/31 – 2013/06/02) and 30285322 DNS servers in 26 hours of second measurement (2013/07/05).
This document provides an introduction to DNSSEC (Domain Name System Security Extensions) in 3 parts:
1. It explains the purpose of DNSSEC is to address vulnerabilities in the DNS like cache poisoning and lack of data integrity by cryptographically signing DNS records.
2. It discusses some of the operational implications of DNSSEC like increased response sizes requiring EDNS0, using multiple keys (KSK and ZSK), and developing a DNSSEC Policy and Practice Statement.
3. It provides resources for further learning including open source DNSSEC software, mailing lists, and examples of deployed DNSSEC at the root zone and in some top-level domains.
This presentation gives an overview of the Domain Name System (DNS) and what goes into making the DNS secure. This deck also answers the question what is ICANN's role in Domain Name System Security (DNSSEC) deployment?
SSHFP records provide a secure method of distributing host public keys via DNS. The document discusses:
1) How SSHFP records store the fingerprint of a host's public key in DNS, allowing clients to validate the key via DNS lookup rather than trusting the host directly.
2) Instructions for generating SSHFP records for network devices that may not support all SSH commands, including extracting public keys and generating fingerprints.
3) Configuration details for distributing the SSHFP records in DNS and validating them during SSH connections using DNSSEC, avoiding the need to manually accept host keys.
SSHFP records provide a secure method of distributing host public keys via DNS. The document discusses:
1) How SSHFP records store fingerprints of host public keys in DNS to validate connections, rather than distributing keys directly.
2) The process of generating fingerprints from router public keys, creating SSHFP records, and configuring DNS to distribute them securely via DNSSEC.
3) How an SSH client can validate connections to a host by looking up its SSHFP records and fingerprints in DNS, preventing man-in-the-middle attacks.
DNSSEC at Penn aims to deploy DNSSEC across Penn's DNS infrastructure to authenticate DNS data and secure delegations. The summary tests DNSSEC records and signatures for the jabber.upenn.edu domain, showing authenticated data. Penn has developed homegrown tools to manage secure zone transitions and key rollovers. Initial results from Penn's DNSSEC testbed show a 3-4x increase in zone size and server resource usage after enabling DNSSEC.
The Domain Name System (DNS) is a critical part of Internet infrastructure and the largest distributed Internet directory service. DNS translates names to IP addresses, a required process for web navigation, email delivery, and other Internet functions. However, the DNS infrastructure is not secure enough unless the security mechanisms such as Transaction Signatures (TSIG) and DNS Security Extensions (DNSSEC) are implemented. To guarantee the availability and the secure Internet services, it is important for networking professionals to understand DNS concepts, DNS Security, configurations, and operations.
This course will discuss the concept of DNS Operations in detail, mechanisms to authenticate the communication between DNS Servers, mechanisms to establish authenticity, and integrity of DNS data and mechanisms to delegate trust to public keys of third parties. Participant will be involved in Lab exercises and do configurations based on number of scenarios.
The document discusses the planned key rollover of the DNSSEC Key Signing Key (KSK) for the root zone from the current KSK-2010 to a new KSK-2017. It provides details on the milestones, approach, and state of the rollover process according to the Automated Updates of DNSSEC Trust Anchors protocol. The rollover was paused in 2017 due to uncertainty in measurement data, but progress has since been made to complete the rollover in 2018.
Jan-Piet Mens gave a presentation on DNSSEC and securing DNS with cryptography. He discussed how DNSSEC works by adding digital signatures to DNS records to authenticate their source and integrity. It provides data origin authentication and integrity but does not encrypt data. He demonstrated how to configure and use DNSSEC with Unbound and PowerDNS to enable validating queries. Attendees were encouraged to set up test environments to better understand DNSSEC.
The document discusses DNS over HTTPS (DoH), DNS over TLS (DoT), and Encrypted Server Name Indication (ESNI). It explains that DoH and DoT encrypt DNS queries and responses for increased privacy and security compared to traditional DNS. However, ESNI is also discussed as a solution to further improve privacy by encrypting the server name in the TLS handshake. Concerns about the potential use of these protocols by malware for command and control are also raised.
Part 3 - Local Name Resolution in Linux, FreeBSD and macOS/iOSMen and Mice
The focus of this webinar will be to take a deeper look into this local name-resolution system and the implementations for other Unix systems like Linux and FreeBSD. Linux’s new über-Daemon “systemd” supports both mDNS and the Windows LLMNR (Link-Local-Multicast-Name-Resolution). We will also show how well a Systemd-Linux behaves in heterogenous networks running both Windows and macOS.
This webinar is designed as an easy-to-follow tutorial on DNSSEC signing a zone for DNS admins. Our focus will be on DNSSEC zone signing automation with the Knot DNS Server and BIND 9.
Encrypted DNS - DNS over TLS / DNS over HTTPSAlex Mayrhofer
Encryption is coming to mainstream DNS. This briefing discusses the history, protocols and architecture of encrypted DNS, specifically DNS over TLS and DNS over HTTPS. It also describes the impact of DoT and DoH on various operational models.
This briefing was given during DNSheads Vienna #5 at the nic.at office in Vienna on Jan 30 2018.
The document describes a technique for covertly exfiltrating data from an infected client by encoding it in DNS queries to an evil name server. The infected client breaks sensitive files into blocks, encodes each block, and queries the blocks' names from the evil name server. The server collects the queries to reconstruct the original data. Modern network security systems like next-gen firewalls and intrusion prevention systems cannot detect this technique as the DNS queries appear normal and are mixed with legitimate traffic. The document proposes filtering suspicious domains and analyzing DNS query patterns and volumes to identify exfiltration attempts.
Part 2 - Local Name Resolution in Windows NetworksMen and Mice
This webinar discusses local name resolution protocols in Windows networks. It focuses on Link Local Multicast Name Resolution (LLMNR) and Peer Name Resolution Protocol (PNRP). LLMNR provides serverless name resolution on the local subnet using multicast queries. PNRP is a peer-to-peer name resolution protocol that operates over IPv6 or IPv4-IPv6 tunnels. The webinar explains how these protocols work, how to configure and use them, and potential security issues to be aware of when using them. It also advertises upcoming Men & Mice training courses on DNS and name resolution topics.
DNSSEC - Domain Name System Security ExtensionsPeter R. Egli
This document introduces DNS Security Extensions (DNSSEC) which aims to secure DNS queries and information by adding digital signatures to DNS response records. It discusses security problems with the current DNS system like cache poisoning and spoofing attacks. DNSSEC uses cryptographic keys and signatures to authenticate DNS responses and establish a chain of trust. While DNSSEC adds security, its deployment has been gradual due to complexity and the need for widespread implementation to provide full benefits.
The DNSSEC key signing key (or KSK) of the DNS root zone will be changed in the summer of 2017. During the time between July and October, all DNSSEC validating resolver need to get the new key material.
In this webinar we explain the KSK roll, how DNS resolver will load the new KSK with the RFC 5011 protocol and how a DNS administrator can verify that the new KSK is present in the resolvers configuration.
DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...Felipe Prado
This document discusses a DNS cache poisoning attack that exploits IP fragmentation. It begins with background on DNS and DNSSEC. It then explains how predictable IPIDs in DNS responses can be inferred, allowing an off-path attacker to poison caches with few attempts. The attack works across IPv4 and IPv6 by targeting predictable timing of DNS requests. Mitigations are discussed but the attack remains effective against current recommendations.
This document provides an overview and summary of a webinar for registrars about DNSSEC and PIR's implementation of DNSSEC for the .ORG top-level domain. The webinar covers topics like how DNSSEC works to secure DNS data and prevent cache poisoning, the benefits of DNSSEC for end users, registrants and registrars, PIR's timeline and process for implementing DNSSEC for .ORG, an introduction to DNSSEC terminology, changes to the EPP protocol and registry database, and resources for registrars. The presentation aims to educate registrars on DNSSEC and PIR's rollout so they can support it for domains under .ORG.
- The document discusses nameserver redirection attacks and SQL injection attacks against domain name registry systems.
- It provides examples of how attackers can change domain name registrations through SQL injection or by directly modifying registry databases to redirect traffic to malicious sites.
- A live demonstration shows how SQL injection can be used to enumerate and modify a registry database, redirecting a domain to a rogue IP address and server.
- Mitigation strategies include securing web applications, validating input, using authentication for changes, and information sharing about attacks.
Grehack2013-RuoAndo-Unraveling large scale geographical distribution of vulne...Ruo Ando
Feasibility study of large scale attacks of DNS. We have found 10,334,293 DNS servers in 34 hours of first measurement (2013/05/31 – 2013/06/02) and 30285322 DNS servers in 26 hours of second measurement (2013/07/05).
This document provides an introduction to DNSSEC (Domain Name System Security Extensions) in 3 parts:
1. It explains the purpose of DNSSEC is to address vulnerabilities in the DNS like cache poisoning and lack of data integrity by cryptographically signing DNS records.
2. It discusses some of the operational implications of DNSSEC like increased response sizes requiring EDNS0, using multiple keys (KSK and ZSK), and developing a DNSSEC Policy and Practice Statement.
3. It provides resources for further learning including open source DNSSEC software, mailing lists, and examples of deployed DNSSEC at the root zone and in some top-level domains.
This presentation gives an overview of the Domain Name System (DNS) and what goes into making the DNS secure. This deck also answers the question what is ICANN's role in Domain Name System Security (DNSSEC) deployment?
SSHFP records provide a secure method of distributing host public keys via DNS. The document discusses:
1) How SSHFP records store the fingerprint of a host's public key in DNS, allowing clients to validate the key via DNS lookup rather than trusting the host directly.
2) Instructions for generating SSHFP records for network devices that may not support all SSH commands, including extracting public keys and generating fingerprints.
3) Configuration details for distributing the SSHFP records in DNS and validating them during SSH connections using DNSSEC, avoiding the need to manually accept host keys.
SSHFP records provide a secure method of distributing host public keys via DNS. The document discusses:
1) How SSHFP records store fingerprints of host public keys in DNS to validate connections, rather than distributing keys directly.
2) The process of generating fingerprints from router public keys, creating SSHFP records, and configuring DNS to distribute them securely via DNSSEC.
3) How an SSH client can validate connections to a host by looking up its SSHFP records and fingerprints in DNS, preventing man-in-the-middle attacks.
DNSSEC at Penn aims to deploy DNSSEC across Penn's DNS infrastructure to authenticate DNS data and secure delegations. The summary tests DNSSEC records and signatures for the jabber.upenn.edu domain, showing authenticated data. Penn has developed homegrown tools to manage secure zone transitions and key rollovers. Initial results from Penn's DNSSEC testbed show a 3-4x increase in zone size and server resource usage after enabling DNSSEC.
The Domain Name System (DNS) is a critical part of Internet infrastructure and the largest distributed Internet directory service. DNS translates names to IP addresses, a required process for web navigation, email delivery, and other Internet functions. However, the DNS infrastructure is not secure enough unless the security mechanisms such as Transaction Signatures (TSIG) and DNS Security Extensions (DNSSEC) are implemented. To guarantee the availability and the secure Internet services, it is important for networking professionals to understand DNS concepts, DNS Security, configurations, and operations.
This course will discuss the concept of DNS Operations in detail, mechanisms to authenticate the communication between DNS Servers, mechanisms to establish authenticity, and integrity of DNS data and mechanisms to delegate trust to public keys of third parties. Participant will be involved in Lab exercises and do configurations based on number of scenarios.
The document discusses the planned key rollover of the DNSSEC Key Signing Key (KSK) for the root zone from the current KSK-2010 to a new KSK-2017. It provides details on the milestones, approach, and state of the rollover process according to the Automated Updates of DNSSEC Trust Anchors protocol. The rollover was paused in 2017 due to uncertainty in measurement data, but progress has since been made to complete the rollover in 2018.
The document discusses the upcoming 2017 rollover of the DNSSEC Key Signing Key (KSK) for the root zone. It provides details on:
- The process of rolling over from the existing KSK-2010 to the new KSK-2017, following the Automated Updates protocol
- Important dates in the rollover process, including when KSK-2017 will be published and trusted, and when KSK-2010 will be revoked
- How to check if a DNSSEC validator already trusts KSK-2017 or needs to be updated, using tools like BIND and Unbound
- Potential issues validators may see related to the rollover, like fragmentation problems or trusting the wrong key, and
This document discusses DNSSEC configuration in Windows DNS servers. It covers choosing a key master to generate and manage keys, configuring key signing keys (KSK) and zone signing keys (ZSK), setting denial of existence such as NSEC, importing and exporting trust anchors, and verifying DNSSEC through demonstration of the query and response process between DNS clients, servers, and zones. Powershell commands are provided for automating DNSSEC signing and key management.
APNIC Chief Scientist Geoff Huston briefly explains DNSSEC and the role of the KSK, and the way in which we can measure the possible impact of this planned roll.
DNS-OARC-36: Measurement of DNSSEC Validation with RSA-4096APNIC
APNIC Chief Scientist Geoff Huston presents on why using larger keys for RSA in the context of DNSSEC impairs the robustness of DNSSEC validation for the signed name at DNS-OARC 36, held online from 29 to 30 November 2021.
Dns protocol design attacks and securityMichael Earls
The document discusses DNS security and attacks such as cache poisoning, denial of service attacks through query flooding, and man-in-the-middle attacks through DNS hijacking. It provides examples using tools like dnsFlood.pl and dnshijacker to demonstrate these attacks, and recommends mitigations like restricting queries, preventing unauthorized zone transfers, using DNSSEC, and configuring TSIG to secure DNS messages.
This document discusses DNSSEC deployment. It provides an introduction to DNSSEC and outlines the preparation, process, strategy, and potential influences of a DNSSEC deployment. Key aspects include setting up a test environment, upgrading systems, training staff, signing zones and managing keys, implementing the deployment in stages, and dealing with increased size of packets and potential for larger DDoS attacks. Regular key rollover is part of the long-term strategy. Resources for further information are also provided.
In this training session, two leading security experts review how adversaries use DNS to achieve their mission, how to use DNS data as a starting point for launching an investigation, the data science behind automated detection of DNS-based malicious techniques and how DNS tunneling and DGA machine learning algorithms work.
Watch the presentation with audio here: http://info.sqrrl.com/leveraging-dns-for-proactive-investigations
The document discusses using an experimental system that can perform thousands of DNS and HTTP measurements per day on random internet users to test DNSSEC implementation. It proposes configuring five domains - one validly signed, one invalidly signed, one with IPv6-only NS, one with large IPv6 responses, and one without DNSSEC - to test clients' DNSSEC support, validation, IPv6 capability, and response handling. Initial results from testing 1.8 million clients worldwide found 4.4% of resolvers and 14.15% of clients appear to support DNSSEC. Further analysis of 7,500 New Zealand experiments identified variability between internet providers in estimated DNSSEC support rates. Future work to improve DNSSEC activity detection is proposed
Slides for a college course based on "DNS Security" by Anestis Karasaridis.
Teacher: Sam Bowne
Twitter: @sambowne
Website: https://samsclass.info/40/40_F16.shtml
BSides Rochester 2018: Chris Partridge: Turning Domain Data Into Domain Intel...JosephTesta9
This document summarizes Chris Partridge's work on scraping and analyzing DNS data to generate threat intelligence. It discusses scraping domain and DNS data at scale, analyzing it for anomalies, integrating threat intelligence, and limitations. The goal is to develop proactive threat intelligence by identifying relationships between domains, IPs, and known bad actors from DNS data and intelligence. Future work includes scaling up data collection, distributed analysis, and integrating findings into security tools.
PLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSECPROIDEA
This document discusses DNSSEC (Domain Name System Security Extensions) and its importance for securing the Domain Name System (DNS) infrastructure. It provides an overview of vulnerabilities like cache poisoning attacks that DNSSEC aims to address. It highlights how attitudes towards DNSSEC deployment have changed rapidly in recent years. The document outlines several cache poisoning attacks like Kaminsky's 2008 attack that exploited vulnerabilities in DNS resolvers and spurred improved security. It provides resources for learning about and testing DNSSEC implementations to help secure domains. Overall, the document makes a case for DNSSEC as a critical long-term solution to DNS security issues.
The document describes the steps involved in resolving a URL to an IP address and retrieving a webpage. It involves:
1. The browser sends a DNS query to resolve the domain name to an IP address, going through a hierarchy of DNS servers starting from the root servers down to the authoritative name servers.
2. Once the IP address is obtained, the browser uses TCP to establish a connection and sends an HTTP request to the web server at that IP address.
3. The web server responds with the HTML content which the browser then parses and renders to display the webpage. Traceroute commands are shown to trace the path packets take from the local network to the destination server.
DNSSEC: What a Registrar Needs to Knowlaurenrprice
The document summarizes an upcoming webinar on DNSSEC hosted by .ORG, The Public Interest Registry and Afilias. The webinar will provide an introduction to DNSSEC including how it adds security and authentication to the Domain Name System to prevent forged DNS data. It will also discuss PIR's implementation timeline and test program for DNSSEC in the .ORG top-level domain.
This document discusses Extended DNS Errors (EDE), which defines a variety of new error messages in DNS responses to reduce the complexity of diagnosing DNS issues. EDE extends existing SERVFAIL and REFUSED response codes with details about the cause of errors. It uses an EDNS0 option to include this extended error information without affecting normal response code processing.
Navigating IP Addresses: Insights from your Regional Internet RegistryRIPE NCC
The document summarizes insights from Alena Muravska of the RIPE NCC about navigating IP addresses. It provides statistics on Internet number resources allocated to Poland by the RIPE NCC, including that Poland has 687 members and 737 LIRs. It discusses the depletion of IPv4 addresses and the new IPv4 allocation policy, noting that 32 Polish LIRs are currently waiting in the IPv4 waiting list. It also covers IPv6 allocations and assignments for members and non-members, and provides graphs on IPv4 holdings and IPv6 capability in Poland.
The presentation discusses the RPKI system and a recent incident where a threat actor gained access to an organization's RPKI dashboard using a leaked password. This led to unexpected changes being made to the organization's RPKI ROAs, causing a routing outage that disrupted internet connectivity. The presentation emphasizes the importance of strong passwords, multi-factor authentication, network security monitoring, and having an incident response plan to prevent similar incidents and increase routing resilience.
LIA HESTINA - Minimising impact before incidents occur with RIPE Atlas and RISRIPE NCC
This document discusses how network operators can minimize the impact of incidents on their networks using RIPE Atlas and Routing Information Services (RIS). It recommends strategically deploying RIPE Atlas probes and peering with RIS to continuously monitor the network. It also suggests setting up alerts to detect abnormalities and anomalies swiftly. Additional recommendations include maintaining low latency through debugging, and impressing customers by showcasing network performance.
IGF UA - Dialog with I_ organisations - Alena Muavska RIPE NCC.pdfRIPE NCC
This document summarizes Alena Muravska's presentation on engaging the Ukrainian community during times of war. It discusses how the Ukrainian community can participate in the RIPE community through various working groups and meetings. It also outlines how the RIPE NCC has supported Ukraine, including dedicating sessions to discuss the internet in Ukraine and forming a task force on best practices to survive disasters or war. Finally, it discusses efforts taken to protect Ukrainian resource holders, such as preventing unauthorized transfers of internet resources and examining changes made to country codes during the invasion.
Opportunities for Youth in IG - Alena Muravska RIPE NCC.pdfRIPE NCC
The document discusses opportunities for youth involvement in internet governance through the RIPE NCC. It describes the RIPE NCC as the regional internet registry for Europe, the Middle East, and Central Asia that allocates IP addresses and supports the open internet community. It outlines how individuals can participate in RIPE community working groups, meetings, policy development processes, and more. It specifically highlights the RIPE Fellowships and RIPE Academic Cooperation Initiative programs that fund youth attendance at RIPE meetings and encourage engagement between academia and the RIPE community.
The document discusses the RIPE NCC's Internet measurement tools - RIPE Routing Information Service (RIPE RIS), RIPEstat, and RIPE Atlas. It provides details on each tool, including how they collect and analyze routing data, Internet traffic maps, and performance measurements from over 12,000 probes worldwide. The tools are used by network operators, researchers, and policymakers to monitor routing, identify incidents, and inform future plans. Future plans include improving data collection and analysis, open sourcing components, and renewing back-end systems.
This document discusses RPKI (Resource Public Key Infrastructure) for securing Internet routing. It provides statistics on RPKI adoption in Luxembourg and neighboring countries, showing that while Luxembourg has over 65% of its address space covered by ROAs, not all networks have fully implemented RPKI. The goal is 100% RPKI implementation to validate all routes and prevent route hijacking, but obstacles still exist to full deployment. The presenter's contact information is provided for any questions.
The document discusses RIPE NCC's engagement in Southeast Europe, including organizing meetings, supporting network operator groups, developing internet exchange points, and funding opportunities. It then covers the topics of internet resiliency, analyzing networks in Belarus, Ukraine, Turkey and Poland using routing data. Next, it provides an analysis of internet landscapes in specific Southeast European countries. Key findings include the role of incumbent telecom operators, efficiency of regional routing but some anomalies, and modest diversity in routes into the region. Data sources used are also listed.
Know Your Network: Why Every Network Operator Should Host RIPE AtlasRIPE NCC
The document discusses the benefits of network operators hosting RIPE Atlas probes. It describes RIPE Atlas as an active measurements platform that monitors internet reachability through probes hosted by volunteers around the world. It highlights that RIPE Atlas data is publicly available and can be used by network operators to monitor performance, identify issues, validate findings, and plan improvements. The document encourages network operators in Africa to install RIPE Atlas probes to better monitor their networks and neighborhoods.
Minimising Impact When Incidents Occur With RIPE AtlasRIPE NCC
The document discusses how the online gaming company Mbappe uses RIPE Atlas to monitor network performance and minimize latency issues for their global users. It recommends strategically deploying RIPE Atlas probes, continuously monitoring measurements, and setting up alerts to quickly detect anomalies. When issues are found, the recommended actions are to identify network problems swiftly, debug issues to maintain low latency, and showcase network performance to impress customers. Installing probes in specific autonomous systems and networks could help identify parts of the network with high latency that are important to address.
- RIPE NCC provides internet measurement services including the Routing Information Service (RIS), RIPEstat, and RIPE Atlas to collect and provide data on internet routing and performance.
- RIS collects raw BGP data from remote route collectors at internet exchange points to observe real internet routing. RIPEstat and RIPE Atlas provide tools to analyze and visualize this data.
- RIPE Atlas specifically operates a global network of internet measurement devices that actively monitor connectivity, reachability, and performance. Its data and custom measurement tools are available to both network operators and researchers.
RIPE Atlas is a global measurement platform that uses probes hosted by volunteers to monitor internet connectivity and latency. It provides latency maps showing routes between networks and allows custom measurements. The presentation highlighted how RIPE Atlas can be used to identify networks with high latency, view routes and locations of probes, and conduct DNS and traceroute tests while remaining secure and low cost. Hosting a RIPE Atlas probe or improving coverage in certain regions would further benefit internet monitoring.
Presentasi menjelaskan tentang penggunaan RIPE Atlas untuk mendeteksi masalah latensi di internet. RIPE Atlas adalah platform pengukuran internet global yang menggunakan probe di seluruh dunia untuk melakukan pengukuran kinerja jaringan seperti ping dan traceroute. Presentasi mendemonstrasikan bagaimana RIPE Atlas dapat digunakan untuk mengidentifikasi anomali latensi dan membantu perusahaan game online menyelesaikan masalah kinerja mereka.
RIPE Atlas is a global network measurement platform that uses volunteer-hosted probes to monitor Internet performance and availability. It runs tests including ping, traceroute, and DNS to identify issues like high latency. The presentation discusses using RIPE Atlas to help an online gaming company identify and address latency problems impacting users in different regions. It also provides examples of the probes and measurements available in Southeast Asian countries like the Philippines.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
“An Outlook of the Ongoing and Future Relationship between Blockchain Technologies and Process-aware Information Systems.” Invited talk at the joint workshop on Blockchain for Information Systems (BC4IS) and Blockchain for Trusted Data Sharing (B4TDS), co-located with with the 36th International Conference on Advanced Information Systems Engineering (CAiSE), 3 June 2024, Limassol, Cyprus.
Maruthi Prithivirajan, Head of ASEAN & IN Solution Architecture, Neo4j
Get an inside look at the latest Neo4j innovations that enable relationship-driven intelligence at scale. Learn more about the newest cloud integrations and product enhancements that make Neo4j an essential choice for developers building apps with interconnected data and generative AI.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
zkStudyClub - Reef: Fast Succinct Non-Interactive Zero-Knowledge Regex ProofsAlex Pruden
This paper presents Reef, a system for generating publicly verifiable succinct non-interactive zero-knowledge proofs that a committed document matches or does not match a regular expression. We describe applications such as proving the strength of passwords, the provenance of email despite redactions, the validity of oblivious DNS queries, and the existence of mutations in DNA. Reef supports the Perl Compatible Regular Expression syntax, including wildcards, alternation, ranges, capture groups, Kleene star, negations, and lookarounds. Reef introduces a new type of automata, Skipping Alternating Finite Automata (SAFA), that skips irrelevant parts of a document when producing proofs without undermining soundness, and instantiates SAFA with a lookup argument. Our experimental evaluation confirms that Reef can generate proofs for documents with 32M characters; the proofs are small and cheap to verify (under a second).
Paper: https://eprint.iacr.org/2023/1886
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
Hardening the Core of the Internet
1. Ondřej Caletka, Nathalie Trenaman (RIPE NCC)
Hardening the core of the
Internet
DNSSEC and RPKI
APTLD79 Virtual Meeting
2. DNSSEC par
t
• Basic DNS principle
s
• DNS vulnerabilitie
s
• DNSSEC introductio
n
• DNSSEC key type
s
• Parent-child interactio
n
• How to deploy DNSSEC
Agenda
2
RPKI par
t
• Introduction to Routing Securit
y
• Internet Routing Registr
y
• Resource Public Key Infrastructur
e
• Router Origin Authorizatio
n
• Router Origin Validation
4. Example of a DNS query
4
CLIENT
RECURSIVE
RESOLVER
<<.>>
(root)
AUTHORITATIVE
SERVER
AUTHORITATIVE
SERVER
STUB
RESOLVER
www.yahoo.com?
www.yahoo.com?
ask .com DNS
www.yahoo.com?
ask Yahoo DNS
www.yahoo.com?
87.140.2.33
87.140.2.33
9. DNS Vulnerabilities
9
Data Corruption
Cache Poisoning
DNS Amplification
CACHE / RECURSIVE
SERVER
PRIMARY
SECONDARIES
RESOLVER
SR
SR
SR
SR
SR
SR
MITM
DoS
DDNS
Authoritative servers
Spoofing DDNS
AXFR Spoofing
DNS Configuration
DNS-SD mDNS
LLMNR
IPv6 DNS Autodiscovery
10. • Mail goes to the server in the MX resource recor
d
• Path only visible in the email headers
DNS exploit example
10
MX RR MX RR
resolver
Question Answer
receiving
mail server
Spoofed answer
MX RR
Black Hat
sending
mail server
11. • Using UDP makes it easy to send spoofed datagram
s
• Only 16-bit transaction id make brute force guessing possibl
e
• Fragmentation of large datagrams presents another family of vulnerabilitie
s
• Broken resolver implementations using predictable outgoing port numbe
r
• Side-channel attacks like SAD DNS (2020)
Factors making DNS attacks feasible
11
12. • BGP hijack of IP pre
fi
xes used by Amazon Route5
3
• Fake authoritative DNS servers installed on hijacked pre
fi
xe
s
• DNS responses redirected MyEtherWallet.com to a phishing sit
e
• Cache of DNS resolver was poisone
d
• Cryptocurrencies were stolen
Real world example: MyEtherWallet attack in 2018
12
14. • A solution to secure DNS data with asymmetric cryptograph
y
• Provides authenticity and integrity, but no con
fi
dentiality (encryption) of dat
a
• Publisher signs data with a private key and publish the signatures and public key inside the
DNS zon
e
• A
fi
ngerprint of the zone's public key is published in its paren
t
• Validator checks signatures and
fi
lters out compromised dat
a
• A backward-compatible protocol allowing a gradual rollout
What is DNSSEC
14
15. DNSSEC Protected Vulnerabilities
15
Data Corruption
Cache Poisoning
CACHE / RECURSIVE
SERVER
PRIMARY
SECONDARIES
RESOLVER
SR
SR
SR
SR
SR
SR
MITM
(if resolver is
validating)
DDNS
Authoritative servers
AXFR Spoofing
16. • Signing the Resource Records Sets with
private key
• Publishing DNSKEYs and RRSIGs inside the
zone
• Children sign their zones with their private key
• Parent guarantees authenticity of child’s key by
signing the hash of it (DS)
• Repeat for parent …
• …and grandparent
DNSSEC Summary
16
signature
Delegation Signer
public key
TLD
ROOT
DS NSEC3
DNSKEY
DNSKEY
DS
DNSKEY
DNSKEY
SLD1
DS
A
DNSKEY
DNSKEY
AAAA
SLD2
A AAAA
17. www.ripe.net IN A 193.0.0.214
www.ripe.net IN RRSIG A … 26523 ripe.net.
ripe.net IN DNSKEY 256 26523 … ripe.net.
ripe.net IN RRSIG DNSKEY 32987 … ripe.net.
ripe.net IN DNSKEY 257 32987 … ripe.net.
ripe.net IN DS 26523 8 1 …
ripe.net IN RRSIG DS … 43249 net.
net IN DNSKEY 256 43249 … net.
DNSSEC Example
17
ripe.net.
net.
18. • Mostly caching/recursive server
s
• It is expected to shift validation closer to the user for speci
fi
c protocols like DAN
E
• No integrity is guaranteed between validator and end use
r
• Forged data are hidden from end user
s
• According to APNIC Labs measurements, more than 30 % of internet users are using
DNSSEC-validating resolver
Who is validating DNSSEC data?
18
19. • Secure
• Validator can build chain of signed records from trust anchor all the way down to the
desired record
• Insecure
• Validator found a signed proof of an unsigned subtree
• Bogus
• It was not possible to build chain of signed records
• May indicate attack, con
fi
guration error, data corruption or clock di
ff
erence
• Indeterminate
• There is no trust anchor con
fi
gured for that particular subtree
Validation results
19
27. • Interaction with parent administratively expensiv
e
• Should only be done when neede
d
• Bigger keys are bette
r
• Signing zones should be fas
t
• Memory restriction
s
• Space and time concern
s
• Smaller keys with short lifetimes are bette
r
Key problem
27
28. • Large keys are more secur
e
• Can be used longer
• Large signatures => large zone
fi
les
• Signing and verifying computationally expensive
• Small keys are fas
t
• Small signatures
• Signing and verifying less expensive
• Short lifetime
Key functions
28
✖
✖
✖
29. • Key Signing Key (KSK) only signs DNSKEY RRset - all public key
s
• Zone Signing Key (ZSK) signs all records in zone
• Parent DS points to child’s KS
K
• Parent’s ZSK signs D
S
• Signature transfers trust from parent key to child key
More than one key
29
31. • Used to sign all data in the zone
• Can be lower strength than the KSK
• No need to coordinate with parent zone if change is needed
• Can be changed very often
Zone Signing Key - ZSK
31
32. • Only signs the public keys of the zone – KSK and ZSK
• Delegates trust to the ZSK
• Serves as a trust anchor – is referenced from the parent zone
• Its replacement requires changing DS record in the parent zone
Key Signing Key - KSK
32
33. • Only one key that signs all records and also serves as trust ancho
r
• Used mostly in small deployments with ECC-based algorithms
:
• unlike RSA, key size is
fi
xed for Elliptic-curve algorithm
s
• keys are small, fast to sign and secure at the same tim
e
• therefore KSK/ZSK split may not be necessary
Combined Signing Key - CSK
33
34. 34
MX
MX
MX
Record Set
A
A
A
Record Set
RRSIG MX
RRSIG A
signed by (private) ZSK
signed by (private) ZSK
DNSKEY (ZSK)
DNSKEY (KSK)
RRSIG DNSKEY
RRSIG DNSKEY
signed by (private) ZSK (this is actually not necessary)
signed by (private) KSK
DS hash of child’s (public) KSK
DNSKEY (ZSK)
DNSKEY (KSK)
RRSIG DS
CHILD
signed by Parent’s (private) ZSK
PARENT
(public) ZSK
(public) KSK
36. • Each DNS zone is self-containe
d
- publishes actual DNS data, their signatures and a public key to check the
m
• The Chain of trust is built by inserting
fi
ngerprint of the public key to the parent zon
e
- if there is no DS record in the parent zone, the zone is always considered insecur
e
• TLD registry and registrars have to support publishing DS record
s
• Two possible ways
:
- publishing user-provided DS record directl
y
- calculating their own DS records out of user-provided DNSKEY
Building the chain of trust
36
37. • Child zone publishes special CDS and/or CDNSKEY recor
d
• Parent zone operator periodically scans all the child zones for such record
s
• DS records in the parent zone are updated according to CDS or CDNSKEY content
s
- for already secure zones, this update is authorised by DNSSEC signature
s
- for insecure zones, another mechanism has to be deployed to avoid spoo
fi
n
g
•
Automating secure delegation updates
37
39. • On a resolver: almost no effort needed; on by default for
:
- BIN
D
- Unboun
d
- Knot Resolve
r
• On the authoritative side: proper planning is necessary (DNSSEC Practice Statement
)
- Key and Signature Policy: what algorithm to use, how often to change the key
s
- Where to store key
s
- Adapt provisioning syste
m
- Prepare for disaster recovery
How to deploy DNSSEC
39
40. • Most cloud resolvers (Google, Quad9, Cloud
fl
are,…
)
• It is on by default for most common open source DNS resolver
s
• According to APNIC Labs measurements, more than 30 % of internet users are using
DNSSEC-validating resolve
r
• Only signed domains are protected by DNSSEC validatio
n
• The path between validating resolver and client has to be protected, for instance
:
- DNS-over-TL
S
- DNS-over-HTTPS
Who deploys DNSSEC validation
40
41. • The root zone itsel
f
• 1371 out of 1504 Top Level Domains (91 %
)
• Second Level Domain numbers vary a lot per different TLDs
:
- 3.3 million domains under .COM (2 %
)
- 3.4 million domains under .NL (56 %
)
• there is registration fee discount for DNSSEC-enabled domain
s
- 800 000 domains under .CZ (60 %
)
- 515 000 domains in .EU (14 %)
Which domain names are signed
41
43. • The bulk of DNSSEC-protected domain names come from web hosting companie
s
• DNSSEC is usually on-by-default by the hosting compan
y
• Many high-value domains are still not protecte
d
- complex task for Content Delivery Networks, where DNS responses are dynami
c
- no/hard support by many registrar
s
- lack of understanding of the DNSSEC technology
There is still work to do
43
49. Routing on the Internet
49
“BGP protocol”
Can I
trust B?
Routing table
194.x.x.x = B
Routing table
193.x.x.x = A
Is A
correct?
A
193.x.x.x
B
194.x.x.x
B: “I have 194.x.x.x”
A: “I have 193.x.x.x”
50. Routing on the Internet
50
Can I
trust B?
Routing table
194.x.x.x = B
Routing table
193.x.x.x = A
Is A
correct?
A
193.x.x.x
B
194.x.x.x
B: “I have 194.x.x.x”
A: “I have 193.x.x.x”
RIPE
Database
“Internet Routing Registry”
51. • Fat
fi
nger
s
- 2 and 3 are really close on our keyboard
s
• Policy violation
s
- Oops, we did not want this to go on the public Interne
t
- Infamous incident with Pakistan Telecom and YouTube
Accidents happen
51
54. • Many exist, most widely use
d
- RIPE Databas
e
- APNIC Databas
e
- RAD
B
• Veri
fi
cation of holdership over resource
s
- RIPE Database for RIPE Region resources onl
y
- RADB allows paying customers to create any objec
t
- Lots of the other IRRs do not formally verify holdership
Internet Routing Registry
54
55. • Some IRR data cannot be fully truste
d
- Accurac
y
- Incomplete dat
a
- Lack of maintenanc
e
• Not every RIR has an IR
R
- Third party databases need to be used (RADB, NTTCOM
)
- No veri
fi
cation of who holds IPs/ASNs
Problem Statement
55
58. • Ties IP addresses and AS numbers to public key
s
• Follows the hierarchy of the IP address registrie
s
• Allows for authorised statements from IP address holder
s
- AS X is authorised to announce my pre
fi
x
Y
- Signed, holder of Y
Resource Public Key Infrastructure
58
69. ROAs in some Asia Paci
fi
c countries
69
Country % Pre
fi
xes % Addreses Accuracy
AU 26% 44% 100,0%
KZ 12% 5% 100,0%
JP 12% 25% 100,0%
MN 99% 85% 100,0%
AE 36% 29% 99,9%
IR 90% 97% 99,9%
RU 27% 31% 99,9%
PK 91% 97% 99,8%
IN 43% 57% 99,4%
ID 39% 15% 97,6%
CN 2% 2% 93,2%
source: https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html
70. Number of ROAs Globally IPv4
70
• Source: https://stat.ripe.net/widget/rpki-by-trust-anchor
71. Number of ROAs Globally IPv6
71
• Source: https://stat.ripe.net/widget/rpki-by-trust-anchor
73. Two Elements of RPKI
73
Signing
Create your ROAs
Validating
Verifying others
74. • Serious uptake in Route Origin Validation at Internet Exchange Points and Transit Provider
s
• Resulting in decrease of invalid BGP announcement
s
• High uptake in signing objects at all Regional Internet Registrie
s
• All major router vendors are now on boar
d
• Also some outages at different Trust Anchors
2020: The Year of RPKI
74
75. Status of Transit and Cloud Providers
75
Name Type Details Status
Telia Transit Signed & Filtering Safe
Cogent Transit Signed & Filtering Safe
GTT Transit Signed & Filtering Safe
NTT Transit Signed & Filtering Safe
Hurricane Electric Transit Signed & Filtering Safe
Tata Transit Signed & Filtering Safe
PCCW Transit Signed & Filtering Safe
RETN Transit Partially Signed & Filtering Safe
Cloud
fl
are Cloud Signed & Filtering Safe
Amazon Cloud Signed & Filtering Safe
Net
fl
ix Cloud Signed & Filtering Safe
Wikimedia Foundation Cloud Signed & Filtering Safe
Scaleway Cloud Signed & Filtering Safe
• Source: isbgpsafeyet.com
76. More Work Underway
76
Name Type Details Status
Telstra Transit
AS1221 done,
AS4637 planned
Partially Safe
AT&T ISP Signed & Filtering peers Partially Safe
Google Cloud Signed & Filtering planned Partially Safe
You? ? ? ?
• Source: isbgpsafeyet.com
77. Why This Matters for TLDs
77
• Route hijacks are a threat to the availability of the DN
S
• A successful hijack can make a domain name server unreachabl
e
• Or cause DNS queries to be diverted to malicious server
s
• ROAs are important to state routing intention
s
• So validating parties can make secure routing decision
s
• Registrars play an important role in protecting domain name
s
• Creating ROAs is easy!
78. How To Get Started?
78
• Read up! This is a great starting point
:
- https://rpki.readthedocs.io/en/latest
/
• Create your ROA
s
- In my.apnic.net or my.ripe.net
• Share your experience or ask for advic
e
- https://www.ripe.net/mailman/listinfo/routing-wg/
- https://www.apnic.net/community/participate/sigs/routing-security-sig/