APNIC Chief Scientist Geoff Huston gives an overview of the complex many-layered model of DNS security, and a new emerging world of choices for protecting traffic, hiding queries, and the future trends in ISP provided, and independent third-party DNS services at the 2nd ICANN APAC-TWNIC Engagement Forum, held from 15 to 16 April 2021.
APNIC Product Manager, Registry Services George Michaelson present on why RPKI really matters at the 2nd ICANN APAC-TWNIC Engagement Forum, held from 15 to 16 April 2021.
APNIC Chief Scientist Geoff Huston and João Damas present on metrics on DNS centrality, focusing their research on resolvers at RIPE 82, held online from 17 to 21 May 2021.
ICANN DNS Symposium 2021: Measuring Recursive Resolver CentralityAPNIC
APNIC Chief Scientist Geoff Huston and João Damas presented metrics on DNS centrality, focusing their research on resolvers at the ICANN DNS Symposium 2021, held online from 25 to 27 May 2021.
APNIC Product Manager, Registry Services George Michaelson present on why RPKI really matters at the 2nd ICANN APAC-TWNIC Engagement Forum, held from 15 to 16 April 2021.
APNIC Chief Scientist Geoff Huston and João Damas present on metrics on DNS centrality, focusing their research on resolvers at RIPE 82, held online from 17 to 21 May 2021.
ICANN DNS Symposium 2021: Measuring Recursive Resolver CentralityAPNIC
APNIC Chief Scientist Geoff Huston and João Damas presented metrics on DNS centrality, focusing their research on resolvers at the ICANN DNS Symposium 2021, held online from 25 to 27 May 2021.
DNS-OARC-36: Measurement of DNSSEC Validation with RSA-4096APNIC
APNIC Chief Scientist Geoff Huston presents on why using larger keys for RSA in the context of DNSSEC impairs the robustness of DNSSEC validation for the signed name at DNS-OARC 36, held online from 29 to 30 November 2021.
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.
APNIC Chief Scientist, Geoff Huston, gives a presentation on DOH and the changing nature of the DNS as infrastructure at NZNOG 2020 in Christchurch, New Zealand, from 28 to 31 January 2020.
BSides: BGP Hijacking and Secure Internet RoutingAPNIC
APNIC Senior Network Analyst/Technical Trainer Warren Finch and APNIC Training Delivery Manager Tashi Phuntsho present on current tool and techniques, how Resource Public Key Infrastructure (RPKI) is just a piece in the puzzle, and what we should all do to secure Internet routing at BSides in Brisbane, Australia on 12 December 2020.
APNIC Chief Scientist Geoff Huston presents on work Labs is doing to whetehr results from experiments performed at lower levels of the DNS hierarchy would also apply to the root zone.
Rolling the Root Zone DNSSEC Key Signing Key, by Edward Lewis.
A presentation given at APNIC 42's DNS and INR Security session on Monday, 3 October 2016.
Module 4: Configuring and Troubleshooting IPv6 TCP/IP
This module introduces you to IPv6, a technology that will help ensure that the Internet can support a growing user base and the increasingly large number of IP-enabled devices. The current Internet Protocol Version 4 (IPv4) has served as the underlying Internet protocol for almost thirty years. Its robustness, scalability, and limited feature set is now challenged by the growing need for new IP addresses, due in large part to the rapid growth of new network-aware devices.
Lessons
Overview of IPv6
IPv6 Addressing
Coexistence with IPv6
IPv6 Transition Technologies
Transitioning from IPv4 to IPv6
Lab : Configuring an ISATAP Router
Configuring a New IPv6 Network and Client
Configuring an ISATAP Router to Enable Communication Between an IPv4 Network and an IPv6 Network
Lab : Converting the Network to Native IPv6
Transitioning to a Native IPv6 Network
After completing this module, students will be able to:
Describe the features and benefits of IPv6.
Implement IPv6 addressing.
Implement an IPv6 coexistence strategy.
Describe and select a suitable IPv6 transition solution.
Transition from IPv4 to IPv6.
Troubleshoot an IPv6-based network.
SIP and DNS - federation, failover, load balancing and moreOlle E Johansson
SIP use DNS to find a server for a specific URI, like sip:alice@example.com. With DNS a SIP service can provide failover, load balancing and much more. SIP without DNS is a broken solution. SIP and DNS rocks!
DNS-OARC-36: Measurement of DNSSEC Validation with RSA-4096APNIC
APNIC Chief Scientist Geoff Huston presents on why using larger keys for RSA in the context of DNSSEC impairs the robustness of DNSSEC validation for the signed name at DNS-OARC 36, held online from 29 to 30 November 2021.
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.
APNIC Chief Scientist, Geoff Huston, gives a presentation on DOH and the changing nature of the DNS as infrastructure at NZNOG 2020 in Christchurch, New Zealand, from 28 to 31 January 2020.
BSides: BGP Hijacking and Secure Internet RoutingAPNIC
APNIC Senior Network Analyst/Technical Trainer Warren Finch and APNIC Training Delivery Manager Tashi Phuntsho present on current tool and techniques, how Resource Public Key Infrastructure (RPKI) is just a piece in the puzzle, and what we should all do to secure Internet routing at BSides in Brisbane, Australia on 12 December 2020.
APNIC Chief Scientist Geoff Huston presents on work Labs is doing to whetehr results from experiments performed at lower levels of the DNS hierarchy would also apply to the root zone.
Rolling the Root Zone DNSSEC Key Signing Key, by Edward Lewis.
A presentation given at APNIC 42's DNS and INR Security session on Monday, 3 October 2016.
Module 4: Configuring and Troubleshooting IPv6 TCP/IP
This module introduces you to IPv6, a technology that will help ensure that the Internet can support a growing user base and the increasingly large number of IP-enabled devices. The current Internet Protocol Version 4 (IPv4) has served as the underlying Internet protocol for almost thirty years. Its robustness, scalability, and limited feature set is now challenged by the growing need for new IP addresses, due in large part to the rapid growth of new network-aware devices.
Lessons
Overview of IPv6
IPv6 Addressing
Coexistence with IPv6
IPv6 Transition Technologies
Transitioning from IPv4 to IPv6
Lab : Configuring an ISATAP Router
Configuring a New IPv6 Network and Client
Configuring an ISATAP Router to Enable Communication Between an IPv4 Network and an IPv6 Network
Lab : Converting the Network to Native IPv6
Transitioning to a Native IPv6 Network
After completing this module, students will be able to:
Describe the features and benefits of IPv6.
Implement IPv6 addressing.
Implement an IPv6 coexistence strategy.
Describe and select a suitable IPv6 transition solution.
Transition from IPv4 to IPv6.
Troubleshoot an IPv6-based network.
SIP and DNS - federation, failover, load balancing and moreOlle E Johansson
SIP use DNS to find a server for a specific URI, like sip:alice@example.com. With DNS a SIP service can provide failover, load balancing and much more. SIP without DNS is a broken solution. SIP and DNS rocks!
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
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.
This presentation is a tutorial intro to DANE (DNS Authentication of Named Entities). It describes the root problem, a possible solution using DANE, and briefly shows how you can starting using DANE and TLSA records yourself.
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.
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
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.
Lao Digital Week 2024: It's time to deploy IPv6APNIC
APNIC Development Director Che-Hoo Cheng presents on the importance of deploying IPv6 at the Lao Digital Week 2024, held in Vientiane, Lao PDR from 10 to 14 January 2024.
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.
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.
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. Why pick on the DNS?
The DNS is very easy to tap and tamper
• DNS queries are open and unencrypted
• DNS payloads are not secured and tampering cannot be detected
• DNS responses are predictable and false answers can be readily inserted
3. Why pick on the DNS?
The DNS is hard for users to trace
• Noone knows exactly where their queries go
• Noone can know precisely where their answers come from
4. Why pick on the DNS?
The DNS is you!
• Because pretty much everything you do on the net starts with a call to
the DNS
• If we could see your stream of DNS queries in real time we could easily
assemble a detailed profile of you and your interests and activities as
it happens!
• And in the Internet Surveillance Economy this profile information is
highly valuable to all kinds of actors
5. Countering DNS Surveillance
• Can we stop DNS surveillance completely?
• Probably not!
• Can we make it harder to collect individual profiles of activity?
• Well, yes
• And that’s what I want to talk about today
6. What’s the problem here?
• Is the DNS label being queried a secret?
• Well, not normally *
✵ Although there are DNS versions of steganography that can conceal data in the query string
7. What’s the problem here?
• Is the DNS label being queried a secret?
• Well, not normally
• Is the DNS response to a query a secret?
• Again, not normally *
✵ Although there are DNS versions of steganography that can conceal data in the response value
8. What’s the problem here?
• Is the DNS label being queried a secret?
• Well, not normally
• Is the DNS response to a query a secret?
• Again, not normally
• So what is the issue here?
• It’s the combination of query and the meta-data around a query that creates
a problem:
• The end user identity, from the IP packet header
• The DNS label (or sequence of labels) being queried, from the payload
• The date and time
9. Let’s take a step back…
Client DNS Resolver DNS Server
How the idealised model of the DNS works
10. What we suspect the DNS is like
Client DNS Server
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
11. What we suspect the DNS is like
Client DNS Resolver DNS Server
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
DNS
Resolver
Corrupted host platforms
Wireline and middleware
Inspection and interception
Resolvers that leak queries
Servers that leak
queries
13. How can we improve DNS
Privacy?
Let’s look at a few behaviours of the DNS and see what we are doing to
try and improve its privacy properties
14. QNAME Minimisation
• A resolver technique intended to improve DNS privacy where a DNS
resolver no longer sends the entire original query name to the
upstream name server
• Described in RFC 7816
15. Yes, but…
It’s a technique to minimise the information leak between a recursive
resolver and authoritative servers, as stub resolvers pass the full query
label to the recursive resolver
So while it sounds good, its actually not a major improvement
16. DNSSEC pixie dust
• A DNSSEC-signed zone can be used to allow clients to verify that the DNS
answer they that receive about an entry in that zone is authentic
• A DNS response that has been modified will fail to validate under DNSSEC when:
• a client asks a security-aware resolver to resolve a name, and
• sets the EDNS(0) DNSSEC OK bit, and
• the zone is DNSSEC-signed
• A DNSSEC-validating recursive resolver will only return a RRset for the query if it can
validate the response using the associated digital signature, and It will set the AD bit
in the resolver response to indicate validation success
Otherwise it will return SERVFAIL
17. Yes, but…
• The zone (and all its parent zones) must be DNSSEC-signed
• If the recursive resolver performs DNSSEC validation (using the recursive
resolver to validate is the most prevalent deployment model) then the all-
important stub-to-recursive link is still vulnerable to interception and re-
writing
• And if your recursive resolver is performing the re-writing of the response
then the stub is none the wiser if the stub does not perform DNSSEC
validation
• Stub resolvers don’t generally perform DNSSEC validation
• It’s too slow!
18. Middleware and WireTapping
• If we want to make DNS surveillance harder we should look at
encrypting the transport used by DNS queries and responses between
stub and recursive resolvers
• Today’s standard tool is Transport Layer Security, which uses a
dynamically generated session key to encrypt all traffic between two
parties
19. DoT - DNS over TLS
• TLS is a TCP ‘overlay’ that adds server authentication and session encryption
to TCP
• DoT uses a persistent stub-to-recursive relationship to amortize the setup
costs of TCP and TLS over many subsequent queries
• Which works efficiently in a stub-to-recursive scenario, but its not even a little bit
efficient for recursive-to-authoritatives!
• If the initial server name certificate is validated by the client then
• The client can be assured (to some extent) of who it is talking to by name
• No third parties can observe or intrude in the DNS queries and responses in this DoT
session
20. Yes, but…
• The TCP session state is on port 853
• DNS over TLS can be readily blocked by CPE and middleware
• DoT will generate a higher recursive resolver memory load as each client
may have a held state with one or more recursive resolvers
• The privacy is relative, as the recursive resolver still knows all about you
and your DNS queries
• And until ECH* in TLS 1.3 is widely supported, the identity of the TLS server
is still in the clear, which also facilitates blocking even if the DoT session
jumps over to use TCP port 443
* Encrypting the Server Name in the Client Hello message of TLS setup
21. DoH - DNS over HTTPS
• DNS over HTTPS
• Uses an HTTPS session for the stub-to-recursive link
• Similar to DNS over TLS, but with HTTP object semantics interposed
between the DNS and TLS
• Uses TCP port 443, so can be masked within other HTTPS traffic
• Uses DNS wire format
22. Why prefer DoH over DoT?
• To bypass middleware blocking of TCP port 853 (DoT)
• DoH allows the stub resolver function to be merged into the
application at the client end and DNS resolver to be multiplexed at
the server side (browsers and web servers)
• HTTP object semantics allow for HTTP object caching in the client
• This enables server-side HTTP push of DNS responses
• Resolver-less DNS!
• Can speed up transactions through pre-provisioning of DNS responses
• Applications can switch to use DoH without waiting for the OS
platform or the ISP service infrastructure to also support DoH
23. Yes, but…
• Aside from changing the TCP port to 443 there is little difference
between DoH and DoT from a conventional DNS perspective
• Most of the DNS issues with DoH are about the use of resolver-less
DNS and content-based DoH-server switching using the HTTP framing
shim, which are still largely speculative matters these days
• Application-level DoH can be readily hidden from the platform and
from the local network – this can be seen as a good or bad thing!
24. DNS over QUIC
• QUIC is a transport protocol originally
developed by Google and passed over to the
IETF for standardised profile development
• QUIC uses a thin UDP shim and an encrypted
payload
• The payload is divided into a TCP-like transport
header and a payload
• QUIC allows for multiple DNS queries without
TCP Head Of Line blocking
DNS
TLS
TCP
IP
DNS
QUIC
UDP
IP
DOT DOQ
25. Yes, but…
• QUIC on UDP port 443 has issues with port blocking in middleware
• There is little difference between DoQ, DoH and DoT from a
conventional DNS perspective
• The remote end recursive resolver still is privy to all your DNS queries and
your identity
26. Hiding in the Crowd
• What if you use a DoT or DoH session to a very busy open resolver?
• No third party can see you queries to the open resolver
• Noone else can see the responses from the open resolver
• The open resolver asks the authoritative servers which makes it challenging to
map the query back to the end user
• So if you you are prepared to trust Google, Open DNS, Cloudflare, Quad9, etc
with your DNS, and you use DoH or DoT on the stub-to-recursive hop then its
far harder for any third party to associate your identity with your queries
27. I’m still uncomfortable
• It the intention of all of these measures is to prevent a third party
from known who I am and what DNS queries I make, then none of
these approaches really work!
• Is sharing my identity and all my DNS with Google* really a step
forward in protecting my privacy?
• I don’t pay Google
• I don’t have a contract with Google
• It’s not even clear if Google obey the laws of the country where I reside
• So how am I “protected” here?
* Or any other third party DNS resolution service provider
28. Can we improve this?
• A big part of the problem is being able to associate my identity with
DNS queries
• So can we break this association?
29. Oblivious DNS (oDNS)
• Uses the QUERY name to disassociate stub identity from query
• Stub resolver encrypts the DNS query name into a new query name
• Encryption uses the public key of a known oDNS server, and appends the name of the oDNS
server to the encrypted query name
• Stub resolver queries a ‘normal’ recursive resolver with this encrypted query name
• Recursive resolver queries an oDNS server with this encrypted query name
• oDNS server strips out its own name and decrypts the query name, and resolves this
name
• oDNS server encrypts the DNS response to send back to the stub via the recursive
resolver
30. Oblivious DNS
This is “you”
Knows your identity, but not what
DNS name you are asking for
Knows what DNS name you are
asking for, but not your identity
31. Yes, but…
• The DNS is still DNS over UDP port 53
• But nothing prevents a oDNS stub using Do[THQ] to a recursive resolver. The
recursive resolver has no knowledge of oDNS and process the DNS query like
any other
• The encryption is limited due to limited size and alphabet of the
query name field
32. Oblivious DoH
Use double TLS wrapper on a DoH transport to dissociate query name
from stub identity
This is “you”
Knows your identity, but not what
DNS name you are asking for
Knows what DNS name you are
asking for, but not your identity
33. Oblivious DoH
• An outer TLS wrapper is used for the stub-to-oDoH Proxy hop and a
different TLS wrapper is used for the oDoH Proxy-to-oDoH Target hop
• The inner TLS wrapper is used to encrypt the DNS query, encrypted
using the public key of the target
• The response is encrypted using a session key generated by the client
34. Yes, but…
• This requires a modified DNS stub resolver that can send and receive
oDoH messages, an ODoH Proxy and an ODoH Target
• Oh, and the ODoH Proxy and the ODoH Target must not collude!
• But we can’t ensure that no collusion happens!
35. Where is this heading?
• Will any of these DNS Privacy approaches becomes mainstream in the
public Internet?
36. The DNS Economy
• In the public Internet, end clients don’t normally pay directly for DNS
recursive resolution services
• Which implies that outside of the domain of the local ISP, DNS
resolvers are essentially unfunded by the resolver’s clients
• And efforts to monetise the DNS with various forms of funded
misdirection (such as NXDOMAIN substitution) are generally viewed
with extreme disfavour
• Open Resolver efforts run the risk of success-disaster
• They more they are used, the greater the funding problem
• The greater the funding problem the greater the temptation to monetise the
DNS resolver function in more subtle ways
37. The DNS Economy
• The default option is that the ISP funds and operate the recursive DNS
service, funded by the ISP’s client base
• 70% of all end clients use same-AS recursive resolvers *
• However the fact that is works today does not mean that you can
double the input costs and expect it to just keep on working
tomorrow
• For ISPs the DNS is a cost department, not a revenue source
• We should expect strong resistance from ISPs to increase their costs in DNS
service provision
• The DNS is also highly resistant to changes in the edge infrastructure
37
* https://stats.labs.apnic.net/rvrs
38. My Opinion
• ISP-based provisioning of DNS servers without channel encryption will
continue to be the mainstream of the public DNS infrastructure
• Most users don’t change their platform settings from the defaults and
CPE based service provisioning in the wired networks and direct
provisioning in mobile networks will persist
• But that’s not the full story...
39. “Fragmented” DNS
• Is appears more likely that applications who want to tailor their DNS
use to adopt a more private profile will hive off to use DoH to an
application-selected DNS service, while the platform itself will
continue to use libraries that will default to DNS over UDP to the ISP-
provided recursive DNS resolver
• That way the application ecosystem can fund its own DNS privacy
infrastructure and avoid waiting for everyone else to make the
necessary infrastructure and service investments before they can
adopt DNS privacy themselves
• The prospect of application-specific naming services is a very real
prospect in such a scenario
40. It’s life Jim, but not as we
know it!
• The progression here is an evolution from network-centric services to
platform-centric services to today’s world of application-centric
services
• It’s clear that the DNS is being swept up in this shift, and the DNS is
changing in almost every respect
• The future prospects of a single unified coherent name space as
embodied in the DNS, as we currently know it, for the entire Internet
service domain are looking pretty poor right now!
* Apologies to Trekkies!
*