• Home

  • Documents

  • Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new...
44
Rolling the Root KSK Geoff Huston APNIC Labs September 2017

Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Rolling the Root KSKGeoff HustonAPNIC LabsSeptember 2017

Page 2: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Will this break the Internet?

Page 3: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Why?If we stuff up this trust anchor key roll then resolvers that perform DNSSEC validation will fail to provide responses

For DNSSEC-signed names!andFor unsigned names!

These resolvers will go completely dark if they lose their relationship with the signed root of the DNS

Page 4: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Ok – lets strip out the hyperbole!

Can we estimate the extent of the Internet’s population (both human and other) that MAY be impacted by this change in the DNSSEC Trust Anchors?

Can we estimate the LIKELY impact of this change?

Page 5: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

How many users …Send their DNS queries towards recursive resolvers that perform DNSSEC validation?

Because these resolvers WILL be sensitive to a change in the KSK and this number is an approximate estimate of the upper bounds of impact of the KSK change

Page 6: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Digression: Let’s measure DNSSEC

Page 7: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Understanding DNS Resolvers is “tricky”What we would like to think happens in DNS resolution!

Client DNS Resolver

x.y.z?AuthoritativeNameserver

x.y.z?

x.y.z? 10.0.0.1x.y.z? 10.0.0.1

Page 8: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Understanding DNS Resolvers is “tricky”

A small sample of what appears to happen in DNS resolution

Page 9: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Understanding DNS Resolvers is “tricky”The best model we can use

for DNS resolution

Page 10: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Understanding Resolvers is “tricky”

Page 11: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

This means…That it’s hard to talk about “all resolvers”

– We don’t know the ratio of the number of resolvers we cannot see compared to the resolvers we can see from the perspective of an authoritative name server

We can only talk about “visible resolvers”

Page 12: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

This means…And there is an added issue here:

– It can be hard to tell the difference between a visible resolver performing DNSSEC validation and an occluded validating resolver performing validation via a visible non-validating forwarder

Page 13: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

This means…And there is an added issue here:

– It can be hard to tell the difference between a visible resolver performing DNSSEC validation and an occluded validating resolver performing validation via a visible non-validating forwarder

Page 14: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

This means…It’s easier to talk about end clients rather than resolvers, and whether these end clients use / don’t use a DNS resolution service that performs DNSSEC validation

Page 15: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Ok – so measuring the DNS is trickyBut we want to measure DNSSEC validation.

15

Page 16: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Server-Side MeasurementWe can’t instrument the user-sideInstead we instrument the server side, and capture all packets to the authoritative DNS servers and the web serversSo we are trying to infer the capabilities of the end user environment based upon the queries we see at our servers in response to passing the user a “known” question that they have to resolve

16

Page 17: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

The ExperimentWe have an online Ad that contains a scripted collection of URLS to fetch – when the ad is “impressed” the ad script is executed by the user and the user attempts to retrieve all the listed URLsThree URLs:

the good (DNSSEC signed)the bad (invalid DNSSEC signature)the control (no DNSSEC at all)

Page 18: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

DNSSEC ValidatingDNSSEC-Validating resolvers will:

ask for the DNSKEY and DS RRs for both namesfetch the valid-signed objectNOT fetch the Invalid-signed object

Non DNSSEC-validating resolvers will:Not ask for DNSKEY and DS RRsfetch both objects

But what if I have two resolvers in my local config, one validates, one does not?

ask for the DNSKEY and DS RRs for both namesfetch both objects

18

Page 19: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

DNSSEC ValidatingDNSSEC-Validating resolvers will:

ask for the DNSKEY and DS RRs for both namesfetch the valid-signed objectNOT fetch the Invalid-signed object

Non DNSSEC-validating resolvers will:Not ask for DNSKEY and DS RRsfetch both objects

But what if I have two resolvers in my local config, one validates, one does not?

ask for the DNSKEY and DS RRs for both namesfetch both objects

19

Page 20: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

So lets measure DNSSECHow many users use ONLY DNS resolvers that perform DNSSEC validation?

20

Page 21: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Measurement ResultsAugust 2017

– Presented: 426,676,126 experiments to clients– 53,121,177 experiments showed behaviour that was

consistent with DNSSEC validation

– i.e. 12.45% of users use DNSSEC-validatingresolvers!

Page 22: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Measurement ResultsAugust 2017

– Presented: 426,676,126 experiments to clients– 53,121,177 experiments showed behaviour that was

consistent with DNSSEC validation

– i.e. 12.45% of users use DNSSEC-validatingresolvers!

Page 23: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

DNSSEC ValidatingDNSSEC-Validating resolvers will:

ask for the DNSKEY and DS RRs for both namesfetch the valid-signed objectNOT fetch the Invalid-signed object

Non DNSSEC-validating resolvers will:Not ask for DNSKEY and DS RRsfetch both objects

But what if I have two resolvers in my local config, one validates, one does not?

ask for the DNSKEY and DS RRs for both namesfetch both objects

23

Page 24: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

“Partial” DNSSEC ValidatingDNSSEC-Validating resolvers will:

ask for the DNSKEY and DS RRs for both namesfetch the valid-signed objectNOT fetch the Invalid-signed object

Non DNSSEC-validating resolvers will:Not ask for DNSKEY and DS RRsfetch both objects

But what if I have two resolvers in my local config, one validates, one does not?

ask for the DNSKEY and DS RRs for both namesfetch both objects

24

Page 25: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

DNSSEC Use in the InternetThere is a lot of DNSSEC validation out there!

20% don’t ask for DNSSEC credentials at all

62% ask, but don’t validate the response

6% validate but don’t take ‘NO’ for an answer!

12% validate, and accept ‘NO’ as an answer!

Users

Page 26: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

End Digression

26

Page 27: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Ok – lets strip out the hyperbole!

Can we estimate the extent of the Internet’s population (both human and other) that MAY be impacted by this change in the DNSSEC Trust Anchors?

Can we estimate the LIKELY impact of this change?

Page 28: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Ok – lets strip out the hyperbole!

Can we estimate the extent of the Internet’s population (both human and other) that MAY be impacted by this change in the DNSSEC Trust Anchors?

Can we estimate the LIKELY impact of this change?

Page 29: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Ok – lets strip out the hyperbole!

Can we estimate the extent of the Internet’s population (both human and other) that MAY be impacted by this change in the DNSSEC Trust Anchors?

Can we estimate the LIKELY impact of this change?

Page 30: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Our Major Concerns1. That resolvers who validate DNS responses will fail to pick

up the new DNS root key– they do not have code that follows RFC5011 procedures for the

introduction of a new KSK– Or they are using a manually loaded key as the trust point– Or they came in late!

2. The resolvers will be unable to receive the larger DNS responses that will occur during the dual signature phase of the rollover

Page 31: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Let the keys roll automatically# // recursive resolver configuration - Bind

…

managed-keys {

. initial-key 257 3 5 "AwEAAfdqNV

JMRMzrppU1WnNW0PWrGn4x9dPg

…

=„; };

31

A Bind resolver uses the “managed keys” clause in its configuration to allow the KSK to be managed automatically.

When a new KSK is added to the DNSKEY record of the root, signed by the trusted key, then the resolver recognises this as a candidate trusted key. After 30 days of continuous publication of this new key, the resolver is prepared to trust the new KSK

Page 32: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Easy, Right? Just follow RFC5011…• Publish a new KSK and include it in DNSKEY responses,

signed by the old KSK– Resolvers use old-signs-over-new to pick up the new KSK, validate it using the old KSK, and add the

new KSK to the local cache of trust anchor material (i.e. this steps allows resolvers to “learn” the new KSK as a trust point)

• Wait– For at least 30 days

• Withdraw the old KSK– And sign the DNSKEY RR in the root zone with only the new KSK

• Wait– For a a while

• Revoke the old KSK– Because its never wise to keep old information in a trusted state

Page 33: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

https://www.icann.org/en/system/files/files/ksk-rollover-operational-implementation-plan-22jul16-en.pdf

PublishWait

WithdrawWait

Revoke

Page 34: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Our Major Concerns1. That resolvers who validate DNS responses will fail to pick

up the new DNS root key– they do not have code that follows RFC5011 procedures for the

introduction of a new KSK– Or they are using a manually loaded key as the trust point– Or they came in late!

Page 35: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Our Major Concerns1. That resolvers who validate DNS responses will fail to pick

up the new DNS root key– they do not have code that follows RFC5011 procedures for the

introduction of a new KSK– Or they are using a manually loaded key as the trust point– Or they came in late!

Page 36: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Our Major Concerns1. That resolvers who validate DNS responses will fail to pick

up the new DNS root key– they do not have code that follows RFC5011 procedures for the

introduction of a new KSK– Or they are using a manually loaded key as the trust point– Or they came in late!

2. The resolvers will be unable to receive the larger DNS responses that will occur during the dual signature phase of the rollover

Page 37: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

1,139 1,414 1,139 1,4251,414

Page 38: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Large ResponsesThe larger DNS responses invoke different behaviours:

– Some root servers hand back a large unfragmented UDP packet– Some root services hand back a fragmented UDP packet– Some root servers hand back a truncated UDP packet, with fallback

to TCP

Page 39: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Large Responses• This presents a problem with testing – not all root server instances behave the

same way when delivering large responses

• We can test each behaviour in isolation, but to test the diversity of the root server environment is beyond the capabilities of reasonable accuracy of our ad-based measurement framework

• Our tests with 1,430 octet responses in IPv4 show that the noise component drowns out any coherent signal – the loss rate is less than 1%

• IPv6 only has a higher loss rate for UDP fragmentation (40%), but as long as a resolver is dual-stack then this is not a major operational issue

• As a related data point, .org has been running a DNSKEY response of 1,650 octets for some years, and nobody is calling out .org as an operational failure!

Page 40: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Large Responses• This presents a problem with testing – not all root server instances behave the

same way when delivering large responses

• We can test each behaviour in isolation, but to test the diversity of the root server environment is beyond the capabilities of reasonable accuracy of our ad-based measurement framework

• Our tests with 1,430 octet responses in IPv4 show that the noise component drowns out any coherent signal – the loss rate is less than 1%

• IPv6 only has a higher loss rate for UDP fragmentation (40%), but as long as a resolver is dual-stack then this is not a major operational issue

• As a related data point, .org has been running a DNSKEY response of 1,650 octets for some years, and nobody is calling out .org as an operational failure!

Page 41: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Ok – lets strip out the hyperbole!

Can we estimate the extent of the Internet’s population (both human and other) that MAY be impacted by this change in the DNSSEC Trust Anchors?

Can we estimate the LIKELY impact of this change?

Page 42: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Where are we?• A key roll of the Root Zone KSK will cause some DNS resolvers

to fail:– Resolvers who do not pick up the new key in the manner described by

RFC5011 – Resolvers who cannot receive a DNS response of >1,400 octets– The failure will not occur at the exact time of the key roll – it will occur

when the local cache of old signed root entries ages out of the cache, which will take up to 7 days

• Many users who use these failing resolvers will just switch over to use a non-validating resolver

• A small pool of users will be affected with no DNS

Page 43: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

What can I do?Check your recursive resolver config!Check your trusted key set

There is no need to turn off DNSSEC validation!

43

Page 44: Rolling the Root KSK · 1.That resolvers who validate DNS responses will fail to pick up the new DNS root key –they do not have code that follows RFC5011 procedures for the introduction

Questions?


DETECTING RESOLVERS AT - DNS-OARC (Indico)€¦ · DNS TRAFFIC IS NOISY Despite general belief, not all the sources ... Trail blazing 2. Uncertainty about resolvers’ pattern “In

DETECTING RESOLVERS AT - DNS-OARC (Indico)€¦ · DNS TRAFFIC IS NOISY Despite general belief, not all the sources ... Trail blazing 2. Uncertainty about resolvers’ pattern “In

Documents
Defeating DNS Amplification Attacks...Largest DDoS ever uses open resolvers - April 2013 – 300Gbps targeted at Spamhaus Providers worldwide see attacks using their DNS resolvers

Defeating DNS Amplification Attacks...Largest DDoS ever uses open resolvers - April 2013 – 300Gbps targeted at Spamhaus Providers worldwide see attacks using their DNS resolvers

Documents
Measurement Study of Open Resolvers and DNS Server Version

Measurement Study of Open Resolvers and DNS Server Version

Internet
The Current State of DNS Resolvers and RPKI Protection · 2020-02-09 · The Current State of DNS Resolvers and RPKI Protection Marius Brouwer University of Amsterdam marius.brouwer@os3.nl

The Current State of DNS Resolvers and RPKI Protection · 2020-02-09 · The Current State of DNS Resolvers and RPKI Protection Marius Brouwer University of Amsterdam [email protected]

Documents
Master in System and Network Engineering - NLnet Labs · Master in System and Network Engineering Analysis of DNS Resolver Performance Measurements Author: ... widely used DNS resolvers

Master in System and Network Engineering - NLnet Labs · Master in System and Network Engineering Analysis of DNS Resolver Performance Measurements Author: ... widely used DNS resolvers

Documents
Comparing DNS Resolvers in the Wild

Comparing DNS Resolvers in the Wild

Documents
Considered Harmful DNS Resolvers - SIGCOMMconferences.sigcomm.org/hotnets/2014/slides/... · Considered Harmful Kyle Schomp, Mark Allman, and Michael Rabinovich. ... Many security

Considered Harmful DNS Resolvers - SIGCOMMconferences.sigcomm.org/hotnets/2014/slides/... · Considered Harmful Kyle Schomp, Mark Allman, and Michael Rabinovich. ... Many security

Documents
DNS query trends seen at Root and JP · DNS query trends seen at Root and JP Kazunori Fujiwara, JPRS fujiwara@jprs.co.jp 2016/6/14, NANOG 67 DNS Track

DNS query trends seen at Root and JP · DNS query trends seen at Root and JP Kazunori Fujiwara, JPRS [email protected] 2016/6/14, NANOG 67 DNS Track

Documents
The Dan Kaminsky DNS vulnerability DNS root servers DNSSEC ...security.hsr.ch › lectures › Internet_Security_1 › 12-DNSSEC.pdf · • DNS resolution via recursive nameserver

The Dan Kaminsky DNS vulnerability DNS root servers DNSSEC ...security.hsr.ch › lectures › Internet_Security_1 › 12-DNSSEC.pdf · • DNS resolution via recursive nameserver

Documents
Public DNS Resolvers - OPCUG · Your ISP automatically provides you with a DNS resolver. When your com-puter asks for the IP address of a do-main, your ISP’s DNS resolver will provide

Public DNS Resolvers - OPCUG · Your ISP automatically provides you with a DNS resolver. When your com-puter asks for the IP address of a do-main, your ISP’s DNS resolver will provide

Documents
Open Resolvers in COM/NET Resolution Duane Wessels, Aziz Mohaisen DNS-OARC 2014 Spring Workshop Warsaw, Poland

Open Resolvers in COM/NET Resolution Duane Wessels, Aziz Mohaisen DNS-OARC 2014 Spring Workshop Warsaw, Poland

Documents
ANYCAST & DNS by SHAURYA RASTOGI. Root DNS Its is the top most DNS in the DNS hierarchy. It contains entries of DNS nameservers all top level domains

ANYCAST & DNS by SHAURYA RASTOGI. Root DNS Its is the top most DNS in the DNS hierarchy. It contains entries of DNS nameservers all top level domains

Documents
The Resolvers We Use - RIPE 79 · 2019-10-15 · Top Resolvers –by Origin AS Rank Resolver Use % Open Resolver / AS 1Google DNS 9.39% GOOGLE, US 2AS55836 7.89% Reliance Jio, IN

The Resolvers We Use - RIPE 79 · 2019-10-15 · Top Resolvers –by Origin AS Rank Resolver Use % Open Resolver / AS 1Google DNS 9.39% GOOGLE, US 2AS55836 7.89% Reliance Jio, IN

Documents
L-Root September, 2014 ICANN DNS Operations. 2 “L” is one of 13 independently operated root servers serving the DNS root zone The ICANN DNS OPS team

L-Root September, 2014 ICANN DNS Operations. 2 “L” is one of 13 independently operated root servers serving the DNS root zone The ICANN DNS OPS team

Documents
Domain Name System Security - Cyber - Dom… · This publication provides information on Domain Name System (DNS) security. DNS systems, known as DNS Resolvers, are vulnerable to

Domain Name System Security - Cyber - Dom… · This publication provides information on Domain Name System (DNS) security. DNS systems, known as DNS Resolvers, are vulnerable to

Documents
DNS Architecture Idea: Modularization & Compartmentalization · 2019-06-18 · Attacks Interna Attacks . 12 Configure Policy Resolvers Caching Forwarders (CFs) ... mitigate issues

DNS Architecture Idea: Modularization & Compartmentalization · 2019-06-18 · Attacks Interna Attacks . 12 Configure Policy Resolvers Caching Forwarders (CFs) ... mitigate issues

Documents
Managing the trust anchor of the DNS against adversity · know the locations of the servers authoritative for the root (root servers). They use “root hints” ... Resolvers have

Managing the trust anchor of the DNS against adversity · know the locations of the servers authoritative for the root (root servers). They use “root hints” ... Resolvers have

Documents
White Paper DNS Security Strategies · 2015. 2. 3. · DNS Security Strategies BT Diamond Whitepaper • 5 This can result in hijacking resolvers and hence applications to incorrect

White Paper DNS Security Strategies · 2015. 2. 3. · DNS Security Strategies BT Diamond Whitepaper • 5 This can result in hijacking resolvers and hence applications to incorrect

Documents
Benchmarking DNS resolvers - RIPE 79

Benchmarking DNS resolvers - RIPE 79

Documents
Resolvers in IPv6 Identifying DNS Open - NANOG

Resolvers in IPv6 Identifying DNS Open - NANOG

Documents
Secure Root DNS Servers - GIAC Certifications

Secure Root DNS Servers - GIAC Certifications

Documents
Discover Financial Services DNS Practice Statement for the ...€¦ · Relying parties include DNS resolvers e.g., the browsers or hosts which resolve names in the zone, DNS providers,

Discover Financial Services DNS Practice Statement for the ...€¦ · Relying parties include DNS resolvers e.g., the browsers or hosts which resolve names in the zone, DNS providers,

Documents
Managing and Monitoring a Root DNS Service

Managing and Monitoring a Root DNS Service

Documents
A Look at the ECS Behavior of DNS Resolvers...cies between end-users that use public resolvers and their edge servers by 50%, at the cost of 8 times increase in the number of DNS queries

A Look at the ECS Behavior of DNS Resolvers...cies between end-users that use public resolvers and their edge servers by 50%, at the cost of 8 times increase in the number of DNS queries

Documents
A Measurement Study of Open Resolvers and DNS Server Version

A Measurement Study of Open Resolvers and DNS Server Version

Internet
DNS - Devious Name Services Destroying Privacy & Anonymity ... CON 25/DEF CON 25 presentations/DE… · •Understand IPv6 vs IPv4 •Route ALL DNS to knowns recursive resolvers that

DNS - Devious Name Services Destroying Privacy & Anonymity ... CON 25/DEF CON 25 presentations/DE… · •Understand IPv6 vs IPv4 •Route ALL DNS to knowns recursive resolvers that

Documents
DNS Tampering and Root Servers - Renesys

DNS Tampering and Root Servers - Renesys

Documents
DNSSEC - Red Hatpeople.redhat.com/pwouters/LinuxCon2012-DNSSEC.pdf · DNSSEC capable DNS resolvers unbound (preferred for on the fly reconfiguration) bind (named) DNSSEC capable DNS

DNSSEC - Red Hatpeople.redhat.com/pwouters/LinuxCon2012-DNSSEC.pdf · DNSSEC capable DNS resolvers unbound (preferred for on the fly reconfiguration) bind (named) DNSSEC capable DNS

Documents
Measuring DNSSEC Use - RIPE 67 · Understanding Resolvers is “tricky” What we would like to think happens in DNS resolution! Client DNS Resolver x.y.z? Authoritative Nameserver

Measuring DNSSEC Use - RIPE 67 · Understanding Resolvers is “tricky” What we would like to think happens in DNS resolution! Client DNS Resolver x.y.z? Authoritative Nameserver

Documents
Domain Name System Security · Web viewThis publication provides information on Domain Name System (DNS) security. DNS systems, known as DNS Resolvers, are vulnerable to a number

Domain Name System Security · Web viewThis publication provides information on Domain Name System (DNS) security. DNS systems, known as DNS Resolvers, are vulnerable to a number

Documents