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.
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.
(NET308) Consolidating DNS Data in the Cloud with Amazon Route 53Amazon Web Services
In this session, we show you how to use Amazon Route 53 to consolidate your DNS data and manage it centrally. Learn how to use Amazon Route 53 for public DNS and for private DNS in VPC, and also learn how to combine Amazon Route 53 private DNS with your own DNS infrastructure.
This is a presentation about DNS Cache Poisoning which was presented to the Grey H@t club at Georgia Tech. It covers the basics of DNS, how DNS is vulnerable, the effect of exploiting DNS, and the Kaminsky attack.
bdNOG 7 - Re-engineering the DNS - one resolver at a timeAPNIC
APNIC Director General, Paul Wilson, talks about APNIC's support of updates to BIND to implement caching of NSEC responses to reduce root server query load.
Install and Understand DNSSEC in Linux Server running BIND 9 with CHROOT JAIL system and Service.
By Utah Networxs
Follow - @fabioandpires
Follow - @utah_networxs
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.
(NET308) Consolidating DNS Data in the Cloud with Amazon Route 53Amazon Web Services
In this session, we show you how to use Amazon Route 53 to consolidate your DNS data and manage it centrally. Learn how to use Amazon Route 53 for public DNS and for private DNS in VPC, and also learn how to combine Amazon Route 53 private DNS with your own DNS infrastructure.
This is a presentation about DNS Cache Poisoning which was presented to the Grey H@t club at Georgia Tech. It covers the basics of DNS, how DNS is vulnerable, the effect of exploiting DNS, and the Kaminsky attack.
bdNOG 7 - Re-engineering the DNS - one resolver at a timeAPNIC
APNIC Director General, Paul Wilson, talks about APNIC's support of updates to BIND to implement caching of NSEC responses to reduce root server query load.
Install and Understand DNSSEC in Linux Server running BIND 9 with CHROOT JAIL system and Service.
By Utah Networxs
Follow - @fabioandpires
Follow - @utah_networxs
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.
in this presentation their is the detailed information regarding Domain Name System that is DNS.
What is DNS,how it works,query, resolution wtc all are being covered thoroughly in this presentation as it would have in for all new upcoming Engineering students to know about the DNS as well as would also help employees to get the better understanding regarding the protocol.
The complete agenda of the presentation is to provide the detailed knowledge regarding dns as its the most basic protocol used in Web development.
Hope you would like it. If so please do like share and subscribe.
Domain Name System and Dynamic Host Configuration Protocol.pptxUsmanAhmed269749
Introduction to DNS and DHCP. The presentations highlights the introduction of Domain name System and Dynamic Host Configuration Protocol. These are essential study part in computer networking
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 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.
Presentation on 'The Path to Resolverless DNS' by Geoff HustonAPNIC
Presentation on 'The Path to Resolverless DNS' by Geoff Huston for OARC 39 and 47th CENTR technical workshop, held in Belgrade on 22 and 23 October 2022
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).
ION Tokyo slides for "The Business Case for Implementing DNSSEC" by Dan York (Internet Society).
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 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.
Similar to What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1] (20)
APNIC Foundation, presented by Ellisha Heppner at the PNG DNS Forum 2024APNIC
Ellisha Heppner, Grant Management Lead, presented an update on APNIC Foundation to the PNG DNS Forum held from 6 to 10 May, 2024 in Port Moresby, Papua New Guinea.
Registry Data Accuracy Improvements, presented by Chimi Dorji at SANOG 41 / I...APNIC
Chimi Dorji, Internet Resource Analyst at APNIC, presented on Registry Data Accuracy Improvements at SANOG 41 jointly held with INNOG 7 in Mumbai, India from 25 to 30 April 2024.
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...APNIC
Sunny Chendi, Senior Advisor, Membership and Policy at APNIC, presents 'APNIC Policy Roundup' at the 5th ICANN APAC-TWNIC Engagement Forum and 41st TWNIC OPM in Taipei, Taiwan from 23 to 24 April.
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024APNIC
Dave Phelan, Senior Network Analyst/Technical Trainer at APNIC, presents 'DDoS In Oceania and the Pacific' at NZNOG 2024 held in Nelson, New Zealand from 8 to 12 April 2024.
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...APNIC
Geoff Huston, Chief Scientist at APNIC deliver keynote presentation on the 'Future Evolution of the Internet' at the Everything Open 2024 conference in Gladstone, Australia from 16 to 18 April 2024.
IP addressing and IPv6, presented by Paul Wilson at IETF 119APNIC
Paul Wilson, Director General of APNIC delivers a presentation on IP addressing and IPv6 to the Policymakers Program during IETF 119 in Brisbane Australia from 16 to 22 March 2024.
draft-harrison-sidrops-manifest-number-01, presented at IETF 119APNIC
Tom Harrison, Product and Delivery Manager at APNIC presents at the Registration Protocols Extensions working group during IETF 119 in Brisbane, Australia from 16-22 March 2024
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...APNIC
Che-Hoo Cheng, Senior Director, Development at APNIC presents on the "Benefits of doing Internet peering and running an Internet Exchange (IX)" at the Communications Regulatory Commission of Mongolia's IPv6, IXP, Datacenter - Policy and Regulation International Trends Forum in Ulaanbaatar, Mongolia on 7 March 2024
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC
APNIC Senior Advisor, Membership and Policy, Sunny Chendi presented on APNIC updates and RIR Policies for ccTLDs at APTLD 85 in Goa, India from 19-22 February 2024.
Bridging the Digital Gap Brad Spiegel Macon, GA Initiative.pptxBrad Spiegel Macon GA
Brad Spiegel Macon GA’s journey exemplifies the profound impact that one individual can have on their community. Through his unwavering dedication to digital inclusion, he’s not only bridging the gap in Macon but also setting an example for others to follow.
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
2.Cellular Networks_The final stage of connectivity is achieved by segmenting...JeyaPerumal1
A cellular network, frequently referred to as a mobile network, is a type of communication system that enables wireless communication between mobile devices. The final stage of connectivity is achieved by segmenting the comprehensive service area into several compact zones, each called a cell.
Meet up Milano 14 _ Axpo Italia_ Migration from Mule3 (On-prem) to.pdfFlorence Consulting
Quattordicesimo Meetup di Milano, tenutosi a Milano il 23 Maggio 2024 dalle ore 17:00 alle ore 18:30 in presenza e da remoto.
Abbiamo parlato di come Axpo Italia S.p.A. ha ridotto il technical debt migrando le proprie APIs da Mule 3.9 a Mule 4.4 passando anche da on-premises a CloudHub 1.0.
Understanding User Behavior with Google Analytics.pdfSEO Article Boost
Unlocking the full potential of Google Analytics is crucial for understanding and optimizing your website’s performance. This guide dives deep into the essential aspects of Google Analytics, from analyzing traffic sources to understanding user demographics and tracking user engagement.
Traffic Sources Analysis:
Discover where your website traffic originates. By examining the Acquisition section, you can identify whether visitors come from organic search, paid campaigns, direct visits, social media, or referral links. This knowledge helps in refining marketing strategies and optimizing resource allocation.
User Demographics Insights:
Gain a comprehensive view of your audience by exploring demographic data in the Audience section. Understand age, gender, and interests to tailor your marketing strategies effectively. Leverage this information to create personalized content and improve user engagement and conversion rates.
Tracking User Engagement:
Learn how to measure user interaction with your site through key metrics like bounce rate, average session duration, and pages per session. Enhance user experience by analyzing engagement metrics and implementing strategies to keep visitors engaged.
Conversion Rate Optimization:
Understand the importance of conversion rates and how to track them using Google Analytics. Set up Goals, analyze conversion funnels, segment your audience, and employ A/B testing to optimize your website for higher conversions. Utilize ecommerce tracking and multi-channel funnels for a detailed view of your sales performance and marketing channel contributions.
Custom Reports and Dashboards:
Create custom reports and dashboards to visualize and interpret data relevant to your business goals. Use advanced filters, segments, and visualization options to gain deeper insights. Incorporate custom dimensions and metrics for tailored data analysis. Integrate external data sources to enrich your analytics and make well-informed decisions.
This guide is designed to help you harness the power of Google Analytics for making data-driven decisions that enhance website performance and achieve your digital marketing objectives. Whether you are looking to improve SEO, refine your social media strategy, or boost conversion rates, understanding and utilizing Google Analytics is essential for your success.
Italy Agriculture Equipment Market Outlook to 2027harveenkaur52
Agriculture and Animal Care
Ken Research has an expertise in Agriculture and Animal Care sector and offer vast collection of information related to all major aspects such as Agriculture equipment, Crop Protection, Seed, Agriculture Chemical, Fertilizers, Protected Cultivators, Palm Oil, Hybrid Seed, Animal Feed additives and many more.
Our continuous study and findings in agriculture sector provide better insights to companies dealing with related product and services, government and agriculture associations, researchers and students to well understand the present and expected scenario.
Our Animal care category provides solutions on Animal Healthcare and related products and services, including, animal feed additives, vaccination
2. 2
DNSSEC and DNS Security
$ dig xxx.00001.z.dotnxdomain.net
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; ANSWER SECTION:
xxx.00001.z.dotnxdomain.net. 1 IN A 199.102.79.186
What does this mean?
$ dig xxx.00001.z.dashnxdomain.net
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; ANSWER SECTION:
xxx.00001.z.dashnxdomain.net. 3600 IN A 199.102.79.188
3. DNSSEC and DNS Security
3
$ dig xxx.00002.z.dotnxdomain.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9216
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;xxx.00002.z.dotnxdomain.net. IN A
;; Query time: 619 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 10 01:20:02 UTC 2014
;; MSG SIZE rcvd: 56
What does this DNS response mean?
4. DNSSEC and DNS Security
• Setting the AD bit in a recursive resolver response seems like a
rather unimpressive way of conveying a positive security
outcome, and in the same manner, setting SERVFAIL seems like
a rather poor way of conveying a failed security outcome
• Various approaches to securing the channel between the client
and the recursive resolver have been suggested, but in a simple
lightweight UDP transaction model this can be challenging
• Perhaps it would be simpler for the edge device to perform
DNSSEC validation directly
• Which is fine, but will this approach scale?
5. What can we say about a DNS environment where every edge device that
poses DNS queries performs their own DNSSEC validation?
6. DNSSEC today
• A small, but growing, fraction of all domain names are
signed using DNSSEC
• A larger, but still small, fraction of users use DNS resolvers
that perform DNSSEC validation
At the end of August 2014, some
~11.5% of users send their DNS
queries to DNSSEC-validating
resolvers
7. What if everyone did it?
What if:
every resolver performed DNSSEC validation?
or even if:
every end device performed DNSSEC validation?
What difference in traffic loads and query rates would we see
at an authoritative name server between serving an unsigned
domain name and serving the signed equivalent of the
domain name?
8. The Experiment
• We serve an online Ad with 3 embedded URLs that the
user’s browser is tasked to fetch. The URLs use unique
domain names that are:
– Unsigned
– Signed (good)
– Signed (bad)
• We are looking for behaviours where we see the browser
perform:
– Queries for the DS and DNSKEY RRs for both of the the signed
domains, and
– Fetch the signed (good) but not the signed (bad) URLs
9. What we saw
• Users who exclusively used DNSSEC-validating resolvers
• Users who used a mix of validating and non-validating
resolvers
(typically, we saw the SERVFAIL response on a badly signed
domain name cause the user to repeat the query to a resolver
that did not perform DNSSEC validation)
• Users who exclusively used non-validating resolvers
10. What we saw
Did not attempt to fetch DNSSEC RRs
DNSSEC-validating
Mixed DNSSEC-validating
11. If your resolver validates DNS
responses…
• Then the resolver will need to fetch the DNSKEY and DS
RRs for the zone, and recurse upward to the root
• If these RRs are not cached, then at a minimum there are
at least two additional DNS queries that are performed as
part of the validation process
12. If your resolver validates DNS
responses…
More queries, longer resolution time
Dual Stack client - query for unsigned domain name
20:36:40.288 query: unsigned.example.com IN AAAA -ED (199.102.79.186)!
20:36:41.028 query: unsigned.example.com IN A -ED (199.102.79.186)!
Dual Stack client - query for signed domain name
20:36:41.749 query: signed.example.com IN A -ED (199.102.79.186)!
20:36:41.758 query: signed.example.com IN AAAA -ED (199.102.79.186)!
20:36:41.876 query: signed.example.com IN DS -ED (199.102.79.186)!
20:36:41.993 query: signed.example.com IN DNSKEY -ED (199.102.79.186)!
!
14. Measured Time Cost
Distribution of elapsed time
difference, measured at the
server, from the first DNS query
until the WEB object fetch. There
are three types of clients: those
who validate, those who do not
validate, and those who use a
mix of validating and non-validating
resolvers
15. Measured Time Cost
Distribution of elapsed time
difference, measured at the
server, from the first DNS query
of a signed name until the WEB
object fetch. There are three
types of clients: those who
validate, those who do not
validate, and those who use a
mix of validating and non-validating
resolvers
16. Time Cost
Cumulative distribution of
elapsed time difference,
measured at the server, from the
first DNS query until the WEB
object fetch
17. DNS Resolution Time
This measures just the DNS
resolution part, collecting the
elapsed time between the first
and last queries for a domain
name
18. Unsigned/Non-Validating vs
Signed/Validating
Let’s try a slightly different comparison, and compare the total
DNS query time between
– Non-validating users querying an unsigned name
and
– Validating users querying for a signed name
20. Like-vs-like: unsigned vs signed
25% of users cannot
resolve a simple
uncached unsigned
domain name within a
single query
25% of DNSSEC-validating
users
cannot resolve a
signed name within ½
second
21. Validation Time
• When resolving a previously unseen domain name most clients will
experience up to 500ms additional time spent in validation
– This is due to the additional queries related to the fetch of the
DNSKEY / DS RR sequence to validate the RRSIG of the original
response
This validation phase could be processed in less time…
• Most resolvers appear to perform the validation path check using serial
fetches. Parallel fetches of the DNSSEC validation path RRs would
improve this situation so that the validation fetches would take a single
query cycle time
22. Do any clients drop out?
Does the addition of the DNSSEC RR’s in the response
cause any clients to stop attempts at DNS resolution?
So we looked…
23. Do any clients drop out?
If there was any clear
evidence of DNSSEC
causing resolution failure
then the blue line would be
clearly higher than the other
three control lines
But its not.
There is no experimental evidence to suggest systematic resolution failure
here for DNSSEC-signed names
However, the DNS responses in this experiment were all below 1500 octets.
We have yet to test the case of forced UDP fragmentation in DNS responses
24. Client Behaviour
• Retrieving DNSSEC credentials takes additional time and
volume when validating the resolution outcomes of a signed
name
• But much of this overhead is mitigated by use of local
caches in the DNS resolution path
• And if resolvers performed validation using parallel fetches,
the additional overhead could be brought down to a single
retrieval cycle time
25. Authoritative Server
Measurements
The following analysis attempts to answer the question:
– What increase in queries and traffic should I expect to see if the
unsigned zone I currently serve is DNSSEC signed, and everyone is
using DNSSEC validating resolvers?
26. If you serve a signed Domain
Name:
You will generate larger responses:
Dual Stack client - query for unsigned domain name, no EDNS0!
!
"Query: 117 Bytes!
"Response: 168 bytes!
!
Dual Stack client - query for signed domain name, EDNS0!
!
"Query: (A) 127 Bytes!
"Response: (A) 1168 bytes!
!
"Query: (DS) 80 Bytes!
"Response: (DS) 341 bytes!
!
"Query: (DNSKEY) 80 Bytes!
"Response: (DNSKEY) 742 bytes!
!
"Total: Query: 287 bytes!
" "Response: 2,251 bytes!
27. If you serve a signed Domain
Name:
You will generate larger responses:
Dual Stack client - query for unsigned domain name, no EDNS0!
!
"Query: 117 Bytes!
"Response: 168 bytes!
!
Dual Stack client - query for signed domain name, EDNS0!
!
"Query: (A) 127 Bytes!
"Response: (A) 1168 bytes!
!
"Query: (DS) 80 Bytes!
"Response: (DS) 341 bytes!
!
The DS query is directed to
the parent zone, so you may or
may not see this query at the
authoritative server. In our
case we are serving the parent
zone as well
"Query: (DNSKEY) 80 Bytes!
"Response: (DNSKEY) 742 bytes!
!
"Total: Query: 287 bytes!
" "Response: 2,251 bytes!
28. If you serve a signed Domain
Name:
You will generate larger responses:
Dual Stack client - query for unsigned domain name, no EDNS0!
!
"Query: 117 Bytes!
"Response: 168 bytes!
!
Dual Stack client - query for signed domain name, EDNS0!
!
That’s an increase of 13x in
terms of outbound traffic volume
"Query: (A) 127 Bytes!
"Response: (A) 1168 bytes!
!
"Query: (DS) 80 Bytes!
"Response: (DS) 341 bytes!
!
The DS query is directed to
the parent zone, so you may or
may not see this query at the
authoritative server. In our
case we are serving the parent
zone as well
"Query: (DNSKEY) 80 Bytes!
"Response: (DNSKEY) 742 bytes!
!
"Total: Query: 287 bytes!
" "Response: 2,251 bytes!
29. Server Traffic Load
This represents the 5 minute
relative traffic load between serving
an unsigned control domain and
serving a validly signed domain.
The originating query rates are the
same
30. Server Traffic Load
• Serving a DNSSEC-signed name appears to generate 7.5x
the traffic load, as compared to serving an unsigned name
– But 20% of clients are performing validation, and hence 20% of the
clients generate 13x more traffic
– The theory would expect to see a 3.4x increase in traffic.
– Why is this observed result double the prediction?
31. Server Traffic Load
• Use of the EDNS DNSSEC-OK flag is far higher than the
level of DNSSEC validation
– 84% of queries have the EDNS0 DNSSEC-OK flag set
– And this query generates a response of 1168 bytes (i.e. 7x the size of
a null EDNS response)
– So 64% of clients set EDNS0 DNSSEC-OK, and 20% of clients also
ask for DS and DNSKEY RRs
– The theory predicts that this would result in 7.25x the traffic over an
unsigned domain
– Which is (roughly) what we see
32. Server Traffic Load
• What is the traffic load difference between serving an
unsigned zone and serving a signed zone if every client
performed DNSSEC validation?
– The difference from the current levels of DNSSEC traffic lies
predominately in the additional DNSKEY and DS responses
– You should expect approximately 15x the traffic load for response
traffic
33. If you serve a signed Domain
Name:
You’ll receive 2-3 times as many queries:
Dual Stack client - query for unsigned domain name, no EDNS0!
!
"Query: 117 Bytes!
"Response: 168 bytes!
!
Dual Stack client - query for signed domain name, EDNS0!
!
"Query: (A) 127 Bytes!
"Response: (A) 1168 bytes!
!
"Query: (DS) 80 Bytes!
"Response: (DS) 341 bytes!
!
"Query: (DNSKEY) 80 Bytes!
"Response: (DNSKEY) 742 bytes!
!
"
The DS query is directed to the
parent zone, so you may or may
not see this query at the
authoritative server. In our case
we are serving the parent zone
as well
35. Server Query Load
• 20% of clients use validating resolvers, so the signed
domain query load should be 1.4x that of the unsigned
domain
• But we are observing an increase in the query load of 1.6x
the unsigned domain.
• Why?
37. Query duplication
We are seeing a noticeable level of query duplication from
anycast DNS server farms
The same query is being received from multiple slave
resolvers within a short period of time
Domain Time Query source Query!
!
0a62f.z.example.com 02:05:31.998 74.125.41.81 port: 52065 q: DNSKEY?!
0a62f.z.example.com 02:05:32.000 74.125.41.19 port: 53887 q: DNSKEY?!
0a62f.z.example.com 02:05:32.005 74.125.41.146 port: 52189 q: DNSKEY?!
0a62f.z.example.com 02:05:32.008 74.125.16.213 port: 42079 q: DNSKEY?!
!
This is rising over time
38. Setting Expectations
For a validly signed zone an authoritative server may
anticipate about 4x the query load and 15x the traffic load
as compared to serving an equivalent unsigned zone, if
everyone performed DNSSEC validation *
(* if you served the parent zone as well)
39. The Worst Case
But things get worse when the DNSSEC signatures are
invalid:
– The response from a DNSSEC-validating recursive resolver upon
DNSSEC validation failure is SERVFAIL, which prompts clients of
this resolver to re-query using an alternative resolver
– The recursive resolver may re-query the name using alternative
servers, on the assumption that the validation failure is due to a
secondary server falling out of sync with the current zone data
How much worse does it get?
40. DNS Resolution Time Difference
In this case we look at clients
who use a mixed set of
resolvers, and fail over from a
validating resolver to a non-validating
resolver, and
measure the time from first DNS
query to Web fetch
41. DNS Resolution Time Difference
In this case we look at clients
who use a mixed set of
resolvers, and fail over from a
validating resolver to a non-validating
resolver, and
measure the time from first DNS
query to Web fetch
42. DNS Resolution Times
25% of DNSSEC-validating clients continue DNS
resolution attempts for more than 6 seconds
with a badly signed DNS name
44. Traffic Profile
• The traffic load for a badly signed domain name is around
10x the load for an unsigned domain
• If everyone were to use validating resolvers then the load
profile would rise to around 26x the load of an unsigned
domain
46. Query Profile
• The query load for a badly signed domain name is around
2.5x the load for an unsigned domain
• If everyone were to use validating resolvers then the load
profile would rise to around 4x the load of an unsigned
domain
47. Badly Signed Names
The problem with a badly signed name is the lack of caching
– when a name does not validate, a validating resolver should
not cache the resolution outcomes
So now all resolution attempts from validating resolvers
generate queries at the authoritative name servers
And the use of a rather cryptic “ServFail” response prompts
some recursive resolvers to query all nameservers
So the resultant query load on the authoritative name servers
is far higher than these measurements would suggest
49. Setting Expectations for
DNSSEC
For a validly signed zone an authoritative server may
anticipate about 4x the query load and 15x the traffic load
as compared to serving an equivalent unsigned zone, if
everyone performed DNSSEC validation *
But if you serve a badly signed zone, expect >>8x the query
load and around >>26x the traffic load *
(* if you served the parent zone as well)