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 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.
Deploying New DNSSEC Algorithms (IEPG@IETF93 - July 2015)Dan York
In this talk to the IEPG session at IETF 93 in Prague on 19 July 2015, I outlined some of the challenges associated with deploying new crypto algorithms within DNSSEC and what we potentially need to do to address these challenges.
This document provides an overview and tutorial of the getdns API, which is a new DNS API specification created by and for application developers. It aims to provide a natural follow-on to the getaddrinfo() function. The getdns API and its first implementation, getdns, highlight features like bootstrapping encrypted channels to prevent man-in-the-middle attacks. The tutorial covers DNSSEC and how getdns allows applications to directly query for and validate DNSSEC records like TLSA to securely establish TLS connections using DANE, bypassing the need to trust recursive resolvers. It demonstrates simple getdns functions for full recursion, stub resolution, and fallback options.
1. The document proposes signing the root zone to establish a chain of trust from the root to TLDs to second-level domains, allowing validation of DNS data. Signing the root would connect existing "islands of trust" and prevent alternate trust anchor repositories from diverging.
2. ICANN proposes to perform the key management and signing of the root zone because it is well positioned to ensure secure, stable, and accountable operations through its experience and transparent processes. Integrating these functions maintains the chain of custody and avoids errors from data transfers.
3. The proposal is to maintain the existing tripartite arrangement, with ICANN compiling and signing the root zone file after validating changes, NTIA providing
This document provides an overview of DNS security and DNSSEC. It begins with explanations of what DNS is, how it works, and how DNS responses can be corrupted. It then discusses the problems that occur when DNS goes bad, such as being directed to the wrong site or downloading malware. The document introduces DNSSEC as a solution and explains why it was created and why it is important, particularly for government agencies. It addresses why more organizations don't use DNSSEC and the challenges of deploying and maintaining it. Finally, it describes options for implementing DNSSEC, including the GSA DNSSEC Cloud Signing Service, which handles the complexities for .gov domains.
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.
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 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.
Deploying New DNSSEC Algorithms (IEPG@IETF93 - July 2015)Dan York
In this talk to the IEPG session at IETF 93 in Prague on 19 July 2015, I outlined some of the challenges associated with deploying new crypto algorithms within DNSSEC and what we potentially need to do to address these challenges.
This document provides an overview and tutorial of the getdns API, which is a new DNS API specification created by and for application developers. It aims to provide a natural follow-on to the getaddrinfo() function. The getdns API and its first implementation, getdns, highlight features like bootstrapping encrypted channels to prevent man-in-the-middle attacks. The tutorial covers DNSSEC and how getdns allows applications to directly query for and validate DNSSEC records like TLSA to securely establish TLS connections using DANE, bypassing the need to trust recursive resolvers. It demonstrates simple getdns functions for full recursion, stub resolution, and fallback options.
1. The document proposes signing the root zone to establish a chain of trust from the root to TLDs to second-level domains, allowing validation of DNS data. Signing the root would connect existing "islands of trust" and prevent alternate trust anchor repositories from diverging.
2. ICANN proposes to perform the key management and signing of the root zone because it is well positioned to ensure secure, stable, and accountable operations through its experience and transparent processes. Integrating these functions maintains the chain of custody and avoids errors from data transfers.
3. The proposal is to maintain the existing tripartite arrangement, with ICANN compiling and signing the root zone file after validating changes, NTIA providing
This document provides an overview of DNS security and DNSSEC. It begins with explanations of what DNS is, how it works, and how DNS responses can be corrupted. It then discusses the problems that occur when DNS goes bad, such as being directed to the wrong site or downloading malware. The document introduces DNSSEC as a solution and explains why it was created and why it is important, particularly for government agencies. It addresses why more organizations don't use DNSSEC and the challenges of deploying and maintaining it. Finally, it describes options for implementing DNSSEC, including the GSA DNSSEC Cloud Signing Service, which handles the complexities for .gov domains.
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.
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 document discusses IPv6 threats to government networks. It provides an overview of IPv6 including its large address space and advantages over IPv4. It notes that while the US government is required to transition to IPv6, progress has been slow. Specific IPv6 threats are examined such as NDP spoofing, SLAAC attacks, and Teredo tunneling. It is concluded that most organizations are not fully prepared to detect and mitigate IPv6 threats due to limitations in tools, analyst expertise, and threat intelligence focusing primarily on IPv4.
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.
DNSSEC Deployment for .VN and share information of DNSSEC's plan in 2017APNIC
The document summarizes Vietnam's deployment of DNSSEC for the .VN top-level domain. It discusses Vietnam moving the domain to partial DNSSEC in 2015, getting the DS record included in the DNS root zone in 2016, and becoming fully operational in 2017. It provides details on preparations like infrastructure, key management, and monitoring plans. The next steps include signing additional subdomains and training registrars and ISPs to deploy DNSSEC to complete the rollout.
This document discusses DNS cache poisoning vulnerabilities, including:
- Explanations of how cache poisoning works by entering non-authoritative records into a resolver's cache.
- A timeline of vulnerabilities discovered from 1993-2008 related to implementation issues that allowed cache poisoning.
- Countermeasures like DNSSEC that add authentication and integrity to DNS to prevent cache poisoning attacks.
DNS is critical network infrastructure and securing it against attacks like DDoS, NXDOMAIN, hijacking and Malware/APT is very important to protecting any business.
Early Detection of Malicious Activity—How Well Do You Know Your DNS?Priyanka Aash
The Domain Name System is deceptively simple and often underutilized as a security tool. Once you start looking under the cover there is a wealth of detail that can be used as an early warning system to predict new targeted attacks. In this session Farsight Security CTO Merike Kaeo will provide a detailed look at how DNS information can be used to indicate suspicious activity and prevent attacks.
Learning Objectives:
1: Understand how DNS can be utilized as early warning system for attacks.
2: Understand how to mitigate against attacks utilizing DNS infrastructure.
3: Understand importance of DNS as a security tool.
(Source: RSA Conference USA 2018)
DNS security is important. But, in today’s world of dynamic cloud environments (AWS and Azure), content delivery networks (CDNs) and crowdsourced content and advertisements, looking only at the domain name is not a complete indicator of security. “Grey” domains are no longer the exception, they have become the norm. Join this webcast to explore the risks of relying on DNS-only based solutions and ways to add security to your DNS traffic without sacrificing performance or additional security insights.
This document provides an overview of key concepts in DNSSEC including public/private keys, message digests or hashes, and digital signatures. It explains that public/private key pairs are used, where the private key is kept secret and the public key can be freely distributed. It also describes how one-way hashing functions work to generate fixed-length hashes from variable-length data, and how digital signatures are created by encrypting a message hash with a private key. These three concepts of public/private keys, hashes, and digital signatures form the basis of cryptographic techniques used in DNSSEC.
The document discusses estimating the impact of rolling the root zone key signing key (KSK) in the Domain Name System Security Extensions (DNSSEC). It finds that approximately 12% of users use DNSSEC-validating resolvers and would be impacted if they fail to pick up the new KSK. There are also concerns that some resolvers may be unable to handle the larger DNS responses during the dual signature period of the rollover. However, the impact is estimated to be small, as many users of failing resolvers would just switch to a non-validating resolver temporarily. The key risks are resolvers that do not follow the RFC for rolling keys or cannot receive responses over 1400 bytes.
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
The NGPC approved the Name Collision Occurrence Management Framework on 30 July 2014 that puts new requirements on registries to mitigate name collision issues.
This session explains what registries are expected to implement, and discuss feedback from those in the community on their experiences so far. It also aims to clarify any points of confusion – such as how RPMs can be treated in relation to this new Framework and how both sets of requirements can be adhered to simultaneously.
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.
This document discusses DNS cache poisoning. It begins by explaining what DNS is and its purpose of mapping domain names to IP addresses. It then discusses how DNS servers implement caching to improve performance and defines DNS cache poisoning as getting unauthorized entries into a DNS server's cache. The document outlines how an attacker could poison a cache to redirect traffic to a machine they control in order to perform man-in-the-middle attacks or install malware. It describes various methods of poisoning caches locally or remotely, such as between end users and nameservers or between nameservers themselves using the Kaminsky attack. Defenses like DNSSEC are mentioned along with encouragement to try cache poisoning in a controlled lab environment.
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.
PLNOG15 :DDOS Attacks & Collateral Damage. Can we avoid it? Asraf AliMarta Pacyga
This document discusses DDoS attacks, including the types of attacks, their impact on victims, and best practices for network operators. It covers TCP exhaustion attacks, volumetric attacks, reflective amplification attacks that exploit protocols like DNS and NTP, and application layer attacks. These attacks can directly impact content providers and indirectly impact service providers and cloud providers. The document recommends network operators deploy anti-spoofing, scan for and mitigate abusable services, and utilize carrier DDoS protection services to help prevent collateral damage from attacks.
1. The document discusses DNS cache poisoning using a man-in-the-middle attack. It provides details on setting up the attack using Kali Linux, Windows Server 2008, and Windows 7. It clones the Facebook website and poisons the DNS cache so traffic is redirected to the fake site.
2. Testing confirms the attack was successful when pinging the fake Facebook site returns the IP of the Kali machine for both Windows systems. The document also proposes short and long-term solutions to prevent DNS cache poisoning attacks, such as disabling open recursive name servers and implementing DNSSEC.
3. In conclusion, the document notes that while DNS cache poisoning is easy to setup, protection requires more effort but is still important for network
This document discusses SSL/TLS protocols and how to set up your own certificate authority (CA) or use Let's Encrypt for free SSL certificates.
It provides a brief history of SSL and TLS protocols, outlines the key differences between versions, and lists common TLS implementations like OpenSSL. It then explains how to set up your own CA by generating root and intermediate certificates and signing server/client certificates.
Finally, it introduces Let's Encrypt as a free and automated CA that aims to promote SSL security. It explains how Let's Encrypt validates domain ownership and issues certificates to ensure communications are private, integrity is maintained, and parties can be trusted.
ION Toronto, 11 November 2013: What is DNSSEC and why is it so important? We’ll discuss the business reasons for, and financial implications of, deploying DNSSEC, from staying ahead of the technological curve, to staying ahead of your competition, to keeping your customers satisfied and secure on the Internet.
DNSSEC aims to secure the Domain Name System (DNS) by introducing digital signatures to guarantee the authenticity and integrity of DNS data and protect against vulnerabilities like cache poisoning, as it uses cryptographic keys to validate that DNS responses have not been tampered with and that the data originates from the authoritative name server.
This document discusses IPv6 threats to government networks. It provides an overview of IPv6 including its large address space and advantages over IPv4. It notes that while the US government is required to transition to IPv6, progress has been slow. Specific IPv6 threats are examined such as NDP spoofing, SLAAC attacks, and Teredo tunneling. It is concluded that most organizations are not fully prepared to detect and mitigate IPv6 threats due to limitations in tools, analyst expertise, and threat intelligence focusing primarily on IPv4.
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.
DNSSEC Deployment for .VN and share information of DNSSEC's plan in 2017APNIC
The document summarizes Vietnam's deployment of DNSSEC for the .VN top-level domain. It discusses Vietnam moving the domain to partial DNSSEC in 2015, getting the DS record included in the DNS root zone in 2016, and becoming fully operational in 2017. It provides details on preparations like infrastructure, key management, and monitoring plans. The next steps include signing additional subdomains and training registrars and ISPs to deploy DNSSEC to complete the rollout.
This document discusses DNS cache poisoning vulnerabilities, including:
- Explanations of how cache poisoning works by entering non-authoritative records into a resolver's cache.
- A timeline of vulnerabilities discovered from 1993-2008 related to implementation issues that allowed cache poisoning.
- Countermeasures like DNSSEC that add authentication and integrity to DNS to prevent cache poisoning attacks.
DNS is critical network infrastructure and securing it against attacks like DDoS, NXDOMAIN, hijacking and Malware/APT is very important to protecting any business.
Early Detection of Malicious Activity—How Well Do You Know Your DNS?Priyanka Aash
The Domain Name System is deceptively simple and often underutilized as a security tool. Once you start looking under the cover there is a wealth of detail that can be used as an early warning system to predict new targeted attacks. In this session Farsight Security CTO Merike Kaeo will provide a detailed look at how DNS information can be used to indicate suspicious activity and prevent attacks.
Learning Objectives:
1: Understand how DNS can be utilized as early warning system for attacks.
2: Understand how to mitigate against attacks utilizing DNS infrastructure.
3: Understand importance of DNS as a security tool.
(Source: RSA Conference USA 2018)
DNS security is important. But, in today’s world of dynamic cloud environments (AWS and Azure), content delivery networks (CDNs) and crowdsourced content and advertisements, looking only at the domain name is not a complete indicator of security. “Grey” domains are no longer the exception, they have become the norm. Join this webcast to explore the risks of relying on DNS-only based solutions and ways to add security to your DNS traffic without sacrificing performance or additional security insights.
This document provides an overview of key concepts in DNSSEC including public/private keys, message digests or hashes, and digital signatures. It explains that public/private key pairs are used, where the private key is kept secret and the public key can be freely distributed. It also describes how one-way hashing functions work to generate fixed-length hashes from variable-length data, and how digital signatures are created by encrypting a message hash with a private key. These three concepts of public/private keys, hashes, and digital signatures form the basis of cryptographic techniques used in DNSSEC.
The document discusses estimating the impact of rolling the root zone key signing key (KSK) in the Domain Name System Security Extensions (DNSSEC). It finds that approximately 12% of users use DNSSEC-validating resolvers and would be impacted if they fail to pick up the new KSK. There are also concerns that some resolvers may be unable to handle the larger DNS responses during the dual signature period of the rollover. However, the impact is estimated to be small, as many users of failing resolvers would just switch to a non-validating resolver temporarily. The key risks are resolvers that do not follow the RFC for rolling keys or cannot receive responses over 1400 bytes.
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
The NGPC approved the Name Collision Occurrence Management Framework on 30 July 2014 that puts new requirements on registries to mitigate name collision issues.
This session explains what registries are expected to implement, and discuss feedback from those in the community on their experiences so far. It also aims to clarify any points of confusion – such as how RPMs can be treated in relation to this new Framework and how both sets of requirements can be adhered to simultaneously.
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.
This document discusses DNS cache poisoning. It begins by explaining what DNS is and its purpose of mapping domain names to IP addresses. It then discusses how DNS servers implement caching to improve performance and defines DNS cache poisoning as getting unauthorized entries into a DNS server's cache. The document outlines how an attacker could poison a cache to redirect traffic to a machine they control in order to perform man-in-the-middle attacks or install malware. It describes various methods of poisoning caches locally or remotely, such as between end users and nameservers or between nameservers themselves using the Kaminsky attack. Defenses like DNSSEC are mentioned along with encouragement to try cache poisoning in a controlled lab environment.
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.
PLNOG15 :DDOS Attacks & Collateral Damage. Can we avoid it? Asraf AliMarta Pacyga
This document discusses DDoS attacks, including the types of attacks, their impact on victims, and best practices for network operators. It covers TCP exhaustion attacks, volumetric attacks, reflective amplification attacks that exploit protocols like DNS and NTP, and application layer attacks. These attacks can directly impact content providers and indirectly impact service providers and cloud providers. The document recommends network operators deploy anti-spoofing, scan for and mitigate abusable services, and utilize carrier DDoS protection services to help prevent collateral damage from attacks.
1. The document discusses DNS cache poisoning using a man-in-the-middle attack. It provides details on setting up the attack using Kali Linux, Windows Server 2008, and Windows 7. It clones the Facebook website and poisons the DNS cache so traffic is redirected to the fake site.
2. Testing confirms the attack was successful when pinging the fake Facebook site returns the IP of the Kali machine for both Windows systems. The document also proposes short and long-term solutions to prevent DNS cache poisoning attacks, such as disabling open recursive name servers and implementing DNSSEC.
3. In conclusion, the document notes that while DNS cache poisoning is easy to setup, protection requires more effort but is still important for network
This document discusses SSL/TLS protocols and how to set up your own certificate authority (CA) or use Let's Encrypt for free SSL certificates.
It provides a brief history of SSL and TLS protocols, outlines the key differences between versions, and lists common TLS implementations like OpenSSL. It then explains how to set up your own CA by generating root and intermediate certificates and signing server/client certificates.
Finally, it introduces Let's Encrypt as a free and automated CA that aims to promote SSL security. It explains how Let's Encrypt validates domain ownership and issues certificates to ensure communications are private, integrity is maintained, and parties can be trusted.
ION Toronto, 11 November 2013: What is DNSSEC and why is it so important? We’ll discuss the business reasons for, and financial implications of, deploying DNSSEC, from staying ahead of the technological curve, to staying ahead of your competition, to keeping your customers satisfied and secure on the Internet.
DNSSEC aims to secure the Domain Name System (DNS) by introducing digital signatures to guarantee the authenticity and integrity of DNS data and protect against vulnerabilities like cache poisoning, as it uses cryptographic keys to validate that DNS responses have not been tampered with and that the data originates from the authoritative name server.
AEP Netwrorks Keyper HSM & ICANN DNSSECChin Wan Lim
1) ICANN implemented DNSSEC at the root zone using AEP Keyper HSMs to securely generate and store cryptographic keys.
2) The AEP Keyper HSMs provide the highest level of security certification (FIPS 140-2 Level 4) and have never been compromised.
3) ICANN uses a split key signing scheme, with the KSK stored offline on an encrypted smartcard for additional protection.
The document provides an overview of modules for implementing advanced network services, with a focus on lessons for configuring advanced DHCP and DNS features, and implementing IP Address Management (IPAM). The lessons cover topics such as DHCP components and failover, advanced DNS settings including DNSSEC, and using IPAM to manage IP addressing, address spaces, and monitor network resources.
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.
Why Implement DNSSEC?
Champika Wijayatunga from ICANN discusses the importance of implementing DNSSEC. DNSSEC introduces digital signatures to cryptographically secure DNS data and protect against threats like cache poisoning, spoofing, and man-in-the-middle attacks. While DNSSEC does not protect server threats or ensure data correctness, it does establish the authenticity and integrity of DNS data retrieved. Fully implementing DNSSEC allows businesses and users to be confident they are receiving unmodified DNS information. However, more needs to be done to increase awareness and provide turnkey solutions in order for widespread DNSSEC adoption.
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
The document describes an Internet2 pilot project to deploy DNSSEC (Domain Name System Security Extensions) across several universities and organizations. The goals are to gain operational experience implementing DNSSEC, test DNSSEC-aware applications, and help address obstacles to wider adoption. Participants will sign at least one of their DNS zones and exchange trust anchors to validate DNS data. Several groups including MAGPI and Merit have already started deploying DNSSEC. Challenges include key distribution, operational stability, and encouraging application support.
This document provides an overview of application uses of DNSSEC and the DANE protocol. It discusses how DNSSEC allows cryptographic keys to be stored and verified in the DNS using records like SSHFP, IPSECKEY and TLSA. It describes issues with the current public CA model for TLS certificates and how DANE addresses these by binding certificates to domain names using DNSSEC. The document also provides background on DNSSEC deployment status and examples of application uses like validating SSH host keys.
1. The document proposes signing the root zone with DNSSEC to validate domain name lookups and protect against attacks by incorporating cryptographic trust. Signing the root zone would connect existing "islands of trust" and avoid problems from multiple trust anchor repositories.
2. ICANN is proposed to perform the root zone signing because it is experienced in root zone management, uses open and transparent processes, and can provide long-term stability as an internationally organized nonprofit.
3. The proposal is that ICANN would compile and sign the root zone file while continuing the existing arrangement where Verisign distributes the file after authorization from the US Department of Commerce and ICANN. A public consultation period would begin in October 2008 with the
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.
A presentation on DNS concepts. It covers the topics DNS Introduction, DNS Hierarchy, DNS Resolution Process,
DNS Components, DNS Types, DNSSEC, DNS over TLS (DoT) & HTTPS (DoH), Oblivious DNS (ODoH).
FOSE 2011: DNSSEC and the Government, Lessons LearnedNeustar, Inc.
At FOSE 2011, the panel discussion on the deployment of domain name system security extensions (DNSSEC) within government included Neustar VP and Senior Technologist, Rodney Joffe, who sat side-by-side with some of the industry’s best and discussed how federal IT managers can leverage private sector best practices to meet OMB and FISMA mandated DNSSEC requirements. Entitled “DNS-3: Private Sector Deployment in .com, .net, .org and Beyond,” the panel discussed lessons learned and how federal agencies that have yet to deploy DNSSEC can do so successfully. Visit http://www.ultradns.com for more information.
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.
ION Islamabad, 25 January 2017
By Champika Wijayatunga, ICANN
DNSSEC helps prevent attackers from subverting and modifying DNS messages and sending users to wrong (and potentially malicious) sites. So what needs to be done for DNSSEC to be deployed on a large scale? We’ll discuss the business reasons for, and financial implications of, deploying DNSSEC, from staying ahead of the technological curve, to staying ahead of your competition, to keeping your customers satisfied and secure on the Internet. We’ll also examine some of the challenges operators have faced and the opportunities to address those challenges and move deployment forward.
The document discusses the business case for implementing IPV6 and DNSSEC. It outlines some key criteria for a successful business, including high sales, profits, customer satisfaction, quality products, reputation and sustained growth. It then discusses the limited remaining IPv4 addresses and the need to transition to IPv6. The document also summarizes the key components and security objectives of DNSSEC for securing DNS transactions and authenticating data. Finally, it discusses potential business benefits and motivations for early adopters of DNSSEC across different roles like registries, zone operators and registrars.
DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]APNIC
This document provides an overview of DNSSEC (Domain Name System Security Extensions). It discusses how DNSSEC introduces digital signatures to cryptographically protect DNS data and prevent man-in-the-middle attacks. It also describes some common DNS record types used in DNSSEC like DNSKEY, RRSIG, and DS. The document notes that while DNSSEC deployment has increased in top-level domains and root servers, adoption remains low at the second-level domain level, and more work is still needed for full deployment.
This document provides an overview of the Domain Name System (DNS) including how DNS works, the record types stored in DNS, caching and authoritative servers, and delegation. It discusses how DNS queries work by recursively searching through the DNS hierarchy from the root servers down. Key record types like A, AAAA, NS, MX and SOA are described. The roles of caching servers, which forward queries on behalf of clients, and authoritative servers, which serve data from their own zone files, are compared. Delegation allows separate administration of different domains through the hierarchical structure of DNS.
The document discusses content network navigation and DNS. It defines navigation, switching, routing and explains how DNS translates hostnames to IP addresses. It describes the components of DNS including the domain name space, name servers, resource records, and resolvers. It explains DNS requests, resolution process and tools like nslookup. It also summarizes load balancing techniques for switches including policies for best available server, persistence and differentiated services.
Presentation from ION Djibouti on 2 June 2014 by Toilem Poriot Godwin.
This session will explore one potential technical solution for deploying DNSSEC support within a ccTLD registry. We’ll take a quick look at DNSSEC awareness strategy, the status/progress of signed domains, and lessons learned and challenges for increasing numbers of signed domain names.
23rd PITA AGM and Conference: DNS Security - A holistic view APNIC
Security Specialist Jamie Gillespie presents on DNS Security, examining the complex interactions of this system, from domain registration to name resolution, the security risks of each component, and the mitigation options currently available at 23rd PITA AGM and Annual Conference in Nadi, Fiji from 8 to 12 April 2019.
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.
Top 10 interview question and answers for mcsahopesuresh
Hope Tutors provide Top 15 Windows Server Interview Questions & Answers, which is helpful to system admins who are attending the interview. So kindly follow and prepare for the interviews.
Understanding DNSSEC in Windows DNS Server Kumar Ashutosh
Windows DNS Server supports DNSSEC functionality including signing zones, validating signed responses, automated key rollovers, and RFC 5011 compliance. The document outlines Microsoft's introduction of DNSSEC support in Windows 2008 R2 and improvements in later versions such as online zone signing, automated re-signing of dynamic updates, and low overhead key management.
DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS AttacksFindWhitePapers
Domain Name System (DNS) provides one of the most basic but critical functions on the Internet. If DNS isn't working, then your business likely isn't either. Secure your business and web presence with Domain Name System Security Extensions (DNSSEC).
This document discusses strategies for improving the resilience of the Domain Name System (DNS) against distributed denial-of-service (DDoS) attacks. It outlines how caching of DNSSEC-signed responses for non-existent domain names can help prevent unnecessary queries from reaching the DNS root servers. The document details an initiative by APNIC to sponsor the inclusion of this NSEC caching in the upcoming BIND 9.12 release, which would help distribute DNS query load more efficiently and mitigate DDoS attacks targeting the root servers.
The document provides instructions on how to configure a DNS server. It begins by explaining what a DNS server is and its purpose of translating domain names to IP addresses. It then discusses IP addresses and the differences between dynamic and static IP addresses. Finally, it provides the steps to install and configure a Microsoft DNS server using DNS Manager. These include adding the DNS component in Windows and using DNS Manager to configure the server.
This document provides an overview of Linux and DNS server administration. It discusses what Linux is, where it is used, advantages of using Linux like low cost and security. It also explains what a DNS server is, components of DNS like domains, hostname, zones and how to configure a DNS server in Linux. Hackers prefer Linux due to its availability, customizability and prevalence on servers. Using public DNS services like Google DNS can help speed up internet access. Linux provides a flexible, secure and low-cost operating system for applications including web servers.
Similar to DNSSEC: What a Registrar Needs to Know (20)
3. The Vulnerability of DNS
Quick Intro to DNSSEC
PIR and DNSSEC Timeline
Friends and Family Program
Some DNSSEC Terminology
OT&E Functionality and Changes
◦ EPP
◦ Etc.
Resources
Questions
4. When you visit a web site, send an email, or
download software, can you be sure you are
communicating with the server that you think
you are?
The answer is ‘no’, at least not with certainty.
5. DNSSEC (short for Domain Name System Security
Extensions) adds security to the Domain Name
System.
DNSSEC is designed to protect Internet resolvers
(clients) from forged DNS data, such as that
created by DNS cache poisoning.
6. Currently, a DNS resolver sends a query out to the
Internet and then accepts the first response it
receives, without question.
If a malicious system were to send back an incorrect
response, the resolver would use this address until
its cache expired.
This is bad enough if a single user's computer gets
this bad data, but it is much worse if it's another
name server that answers queries for an ISP –
affecting thousands of users.
7. It provides proof that DNS data has not been
modified in transit to the end-user
It does this by providing additional information,
something like a “seal of origin”, that can be verified
as being correct or not.
It is a set of extensions to DNS, which provide:
a) origin authentication of DNS data,
b) data integrity, and
c) authenticated denial of existence.
8. Each piece of a domain’s DNS information has a digital
signature attached to it.
When a user enters the domain in a browser, the resolver
verifies the signature.
If it does not match, the resolver discards the response and
waits for another.
Only a response with a verified signature will be accepted by
the resolver
The description above is a common scenario. Please note
that different resolvers may take different actions
** Note: DNSSEC only adds signatures to DNS data. It does not encrypt
anything. It has no effect on increasing the privacy of the DNS, and
information in the DNS is still public information.
9. End User Benefits
Ensures you are communicating to the correct
website
End Users that are not DNSSEC aware will not see
any adverse effect.
Registrant Benefits
Mitigates the risk of possible fraud
Greater protection of brand
◦ Significantly decreases the threat of domain hijacking
10. Registrar Benefits
Ability to meet Registrant demands for increase
security of their domain
Ability to continue to sell domains that are not
secured by DNSSEC for those registrants who are not
interested.
Complying with new industry standards
Registry Benefits
Meeting new industry standards
Ability to meet Registrar demands for increase
security of their portfolio of domains
11.
12. Top five perceptions of the .ORG Brand*
◦ Informative
◦ Well-Intentioned
◦ Trustworthy
◦ Valuable Information
◦ Reliable
We expect to keep it that way!
* Source: e5 Marketing Survey of over 10,000 respondents in an electronic form,
November 2008
12
13. .ORG zone signed June 2, 2009
Registrars can participate in the testing phase
Registrars are encouraged to test in OTE
A certification test will be required
2 registrars have passed their certification test to date
We have selected small set of domains and have
manually inserted the DS records at the Registry
Successful scheduled Key Rollovers
14. Additional mandatory .ORG DNSSEC OT&E Test
required
Registrars must pass the OT&E Test to become
DNSSEC Aware
PIR will enable DNSSEC functionality for the
Registrar after successful completion of the OT&E
test.
15. We expect to be done with our internal testing by
Q409
Estimated full production timeframe first half of
2010 meaning registrars can submit live
delegations
16.
17. A DNS resolver is the program on a user’s
computer that sends the query to the DNS.
Once a response is received, the resolver returns
the response back to the end user’s application.
domain.org?
192.0.5.4
User’s PC
Resolver
18. A key pair contains two digital keys — a private key
(held only by the .ORG registry) and a public key
(distributed to the public).
The .ORG registry uses the .ORG private key pair to
sign the zone.
End users' validators (or the validators at their ISPs)
use the .ORG public key to validate the signature
once they've asked for it.
19. If I trust a public key from someone, I can use that key to verify
the signature … and authenticate the source
Make sure the root zone key can be trusted
◦ Pointers in the root zone point to lower zones
(org/com/info/de etc)
◦ Each pointer is validated with the previous validated
zone key
When DNSSEC is fully deployed, only the key for the
root zone is needed to validate all the DNSSEC keys
on the Internet
20. Root Servers
.org authoritative NS
Local
Cache
Recursive
DNS Server
Local
cache
domain.org authoritative NS
User’s PC Resolver Confidential – Copyright
2008 Afilias Limited
21. Root Servers
DNSSEC DNSSEC .ORG authoritative NS
Recursive
DNS Server DNSSEC
Local cache
domain.ORG authoritative NS
User’s PC Resolver Confidential – Copyright
2008 Afilias Limited
22. A key rollover will occur when the .ORG registry
needs to change its side of a key pair.
This means that the entire pair needs to be
changed
◦ The .ORG zone will need to be re-signed with a
new private key
AND
◦ The public will need to update their validating
resolvers with the new public portion of the .ORG
zone key.
23. PIR will be required to do Key Rollovers on a regular
basis:
1. If one of the .ORG private keys were compromised
(i.e., stolen) and had to be immediately revoked.
2. For prevention of compromise (see next question
for further information), where a key rollover
would be scheduled at regular intervals.
24. Digital signatures are not secure all of the time.
They are subject to cryptanalysis.
It is possible for an attacker to learn the private key
in a key pair even though that key has never been
disclosed, either through "brute force" or other
types of attacks.
Since every attack requires time to complete,
periodically changing the key decreases the length
of time an attacker has to attempt the compromise.
25. What would happen if end users do not update their
validating resolvers with the new .ORG zone key?
Once the old key is purged, domains in the .ORG
zone that were signed would no longer resolve for
those people who did not use the new .ORG key.
It would not affect people that are not using
DNSSEC – they would continue to see the domain
name.
26. A key rollover will be announced on the PIR Web
site prior to the scheduled event
Anyone using DNSSEC will have to watch for these
announcements, specially ISPs, registrars, and
people using DNSSEC in applications.
27. Changes have been made to support the DNS
protocol.
Built New Registrar Tool Kit for DNSSEC
◦ Adds DNSSEC EPP transactions (RFC 4310)
EPP server has been modified for DNSSEC
Adds DNSSEC EPP transactions (as per RFC 4310)
Changes to the Registry Database to now Store DS
Information
DNSSEC
28. Covered in the ORG manual: Extensible Provisioning
Protocol (EPP) v1.0 ORG DNSSEC Registrar Acceptance
Criteria
Registrars must test the basic operations that their
client application can perform in the ORG DNSSEC
registry environment including:
◦ Create Domain
◦ Create Domain with Optional Key Data
◦ Query Domain
◦ Query Domain with Optional Key Data
◦ Update Domain – Adding DS Data
◦ Update Domain – Changing DS Data
◦ Update Domain – Change to Include Optional Data
◦ Update Domain – Removing DS Data
29. DNSSEC adds four new resource record types:
1. Resource Record Signature (RRSIG)
Signature over RRset made using private key
2. DNS Public Key (DNSKEY)
Public key, needed for verifying a RRSIG
3. Delegation Signer (DS)
‘Pointer’ for building chains of authentication
4. Next Secure (NSEC, NSEC3)
As an alternative to NSEC, NSEC3 (defined in RFC 5155) can
prevent walking of DNSSEC zones and permits optional
gradual expansion of delegation-centric zones.
NSEC: Indicates which name is the next one in the zone and which
type-codes are available for the current name
30. The DNSSEC Data Fields
Keytag • Contains the key tag value of the DNSKEY RR that validates this signature, in
network byte order
• Provides a mechanism for selecting a public key efficiently.
Algorithm • Identifies the public key's cryptographic algorithm and determines the format of
the Public Key field
Digest Type • Identifies the algorithm used to construct the digest
Digest • The DS record refers to a DNSKEY RR by including a digest of that DNSKEY
RR.
Maximum • Specifies a validity period for the signature
Signature Life
Flags • Identifies whether or not the DNSKEY record holds a DNS zone key
Protocol • The Protocol Field MUST have value 3, and the DNSKEY RR MUST be treated
as invalid during signature verification if it is found to be some value other tan 3.
Confidential – Copyright
Public Key • Holds the public key material 2005 Afilias Limited
31. The following EPP commands will now contain the
optional DNSSEC data:
1. Session Mgmt. 2. Object Query 3. Object
<login> <check> Transform
<logout> <info> <create>
<poll > <delete>
<transfer> <renew>
<transfer>
<update>
32. Create Domain is changed because a DNSSEC
secure domain must be created with a DS record
attached to it
Registrar needs to be accredited for creating
domain names with DS records
If they are not, the system will reject the domain
create command and throw a validation error – You
are not authorized to perform this action.
33. If the maxSigLife is not entered for a <create>
domain name with DS records, the system will set it
to the default value (40 days)
If the user provides empty tags for the following
parameters, the domain will not be created and an
error message will be returned:
◦ secDNS:keyTag
◦ secDNS:alg
◦ secDNS:digestType
34. <update> domain command is now changed as DS
information can be added or changed for each domain
If the Registrar is not accredited for creating domain
names with DS records and attempts to add DS data to
an existing domain name, the system will reject the
domain update command and return an error
If the domain name already has 10 DS records and the
sponsoring Registrar attempts to add another, the
system will reject the domain update command and
return an error per EPP RFC 3730.
If the maxSigLife is not entered for a domain name with
DS records, the system will set it to the default value
(40 days)
35. The following fields will be appended to the WHOIS
output for a domain name with DS records –
◦ DNSSEC (Can be Signed or Unsigned) – To denote if the
domain name is digitally signed.
◦ DS Created – Time stamp that the record was created in
UTC
◦ DS Maximum Signature Life - Maximum Signature Life
associated with this DS record
36. If a domain name has more than one DS record
associated with it, the DS record information for all
the records will be displayed one after the other as
displayed in the screenshot (above) If a domain
name does not have any DS records associated with
it, the DNSSEC value displayed will be Unsigned
37. .ORG OT&E Test Criteria
General FAQ
ORG manual: Extensible Provisioning Protocol (EPP)
v1.0 ORG DNSSEC Registrar Acceptance Criteria
Registrar Tool Kit (RTK – Addon) including the
DNSSEC extensions is available for download from:
◦ https://registrars.pir.org/registrar_relations/dns_
security
◦ www.sourceforge.net
38. The Domain Name System Security Extensions
(DNSSEC are described in these IETF documents:
◦ RFC 4033: DNS Security Introduction and Requirements
◦ RFC 4034: Resource Records for the DNS Security
Extensions
◦ RFC 4035: Protocol Modifications for the DNS Security
Extensions
.ORG website
◦ http://www.pir.org/dnssec
DNSSEC related information website
www.dnssec-deployment.org
www.dnssec.net