DOH? DONUT! - The new internet according to RFC 8484.
Aniketh Girish
anikethgireesh@gmail.com
Privacy | Network | Security
so for next 30 mins..
my quick open source story - boring, *showoff*
Which includes..
My complicated relationship with Networking
On a Serious note.
Why HTTPS here?
How insecure DNS is?
Under the hood DNS-over-HTTPS resolver implementation
I will talk more about.
How DNS-over-HTTPS brings secure DNS to the table?
I will talk more about.
The resistance!
Why not DNSSEC, DNS-over-TLS?
Disputes in secure DNS
DoH: DNS over HTTPS
my Open Source story?
2017- GSoC student with KDE, first patch in 2016 sept.
2018- Again, GSoC student with GNU Linux
2018- Exchange Student Ben-Gurion University, Israel
2019- Research Intern at Rochester Institute of Technology, USA
2019- Research collaboration with the University of Illinois at Chicago, USA
alternative facts
talks are fun (?)
you might enjoy this
Network/Internet Protocol Security enthusiast
mild OSS user/dev
me + IIESoc = ?
amFOSS Community
Insecure DNS
'A coffee shop scenario'
Conventional DNS resolution
DHCP
Are there any DNS servers available for me to resolve?
Sure, send all you need in Clear Text!!!
DHCP
-
Ask for the servers to resolve
-
Get a response from the source
-
Ask an unverified server source to send and receive data
Remote Resolution
DNS over UDP (or TCP)
Does the Name resolution
Get the response from unverified source
There can be unverified hop for finding another server
All in Clear Text!!
What are we looking at here?
MITM: Man-in-the-Middle-attack
DNS communication over UDP or TCP is unencrypted. This is vulnerable to eavesdropping and spoofing
Responses can be tampered with
DNSSEC provides the check of authenticity but NOT availability
Tunnelling the full traffic via VPN is not a practical solution just to obtain authentic DNS records.
Work Around!
DoH: DNS over HTTPS
The better workaround doesn't exist......
Diving into DoH:
- Based on RFC 8484
- HTTPS payload (RFC 1035 packets in HTTPS 'payload' )
- Never sends over Clear-text HTTP
- Privacy and security
- Needs to be configured manually
The device-to-resolver connection is encrypted and hidden inside Web traffic
Each application can use a different resolver (DNS becomes an application level service, not a network one)
Each application maker can hardwire their own remote resolver, at least as a default
Main Changes in the Resolution
More about HTTPS
Use case of HTTPS here?
Use case of HTTPS here?
Hard to block
Proxy friendly
Applications can resolve names easily
Easy to Implement
Easy connection re-use
HTTPS with HTTP/2
DNS packets in HTTP/2 payload
Multiplexing
Server Push
Under the hood of DoH
`Let's start kneading the doh`
Creating DNS Packets
Creating IPv4 (A) && IPv6 (AAAA) and other RR records flags and what else?
Encode it with base64
Each DNS query-response pair is mapped into a HTTP/2 exchange.
Resolver encodes a single DNS query into an HTTP request using either the HTTP GET or POST method and the other requirements of this section.
Parse the DNS response from the HTTP/2 response
Response content type: application/dns-message
HTTP status code 415 (Unsupported Media Type)
https://dnsserver.example.net/dns-query{?dns}
DoH servers
- Public endpoints: Google. quad9, Cloudflare, power-DNS etc
- Multiple server implementations
- Easy to run as DoH supports proxy
Putting all the pieces together:
DNS over HTTPS
The Resistance
Protocol Layer violation
DNS centralisation is wrong!
HTTPS add-ons to more user-tracking
Needs to trust 3rd parties or DNS provider companies
Well, 80% of something is far better than 100% nothing
- Harvey Specter (Suits)
User configuration is hard
Name resolves can't be unsupervised
Admins need to monitor users
Debugging DNS issues is impossible
Split horizon problems
Disputes in secure DNS
Discovery
Opportunistic
System vs Users
Probing
Why not DNSSEC, DNS-over-TLS?
DNSSEC
Prevents fake response and tampering
Chain of Trust
Doesn't consider end user
Still done over clear/Plain text
DNS-over-TLS
Secure
Private
Uses TLS instead of UDP/TCP
RFC 7858 (May 2016)
Not widely deployed yet.
Can be Oppurtunistic
Easy to block (Uses unique por 853)
DoT
DoH
- User Controlled
- Hard to block
- Secure network path
-
Because of HTTP/2:
- Multiplexed
- Connection always reused
DoT vs DoH
- System controlled
- controlled server
- Blockable
- Not Multiplexed
- Often no connection reuse
Takeaways!
Easy to use
Easy to deploy
Doesn't imply centralisation
DoH: Authenticated secure name resolver
But then..!
Secure DNS is still not complete!
Questions?
Thank You!
anikethgireesh@gmail.com
