DOH? DONUT! - The new internet according to RFC 8484.

Aniketh Girish

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 


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


Are there any DNS servers available for me to resolve?

Sure, send all you need in Clear Text!!!


  • 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! 


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


DNS packets in HTTP/2 payload


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){?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:


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



System vs Users


Why not DNSSEC, DNS-over-TLS?


Prevents fake response and tampering

Chain of Trust

Doesn't consider end user

Still done over clear/Plain text




Uses TLS instead of UDP/TCP

RFC 7858 (May 2016)

Not widely deployed yet.

Can be Oppurtunistic

Easy to block (Uses unique por 853)



  • 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


Easy to use

Easy to deploy

Doesn't imply centralisation

DoH: Authenticated secure name resolver

But then..!

Secure DNS is still not complete!


Thank You!

Made with