Yin Yang Metaphor of DNS Privacy

9 min readDec 24, 2023

DNS, in its simplest explanation, is the protocol that converts human-readable domain names into IP addresses. It is one of the fundamental protocols used in Internet communication and therefore it is widely used.

DNS traffic consists of a query and response. A record where the answer to the query is kept is located on the DNS servers. Of course, queries are not only asked for IP address information. DNS record types may vary depending on the information to be learned. Although the DNS protocol is the fundamental protocol for the internet, it has many security vulnerabilities. I will not cover all DNS-related vulnerabilities in this article. However, I will write about how some extensions that are known to be safe can actually be abused.

DNS is a protocol whose queries and responses are all in plain text. This allows DNS traffic to be eavesdropped and even manipulated on the network.

Example of standart clear text DNS request and response

To solve this privacy problem, fortunately DNS over TLS (DoT-RFC 7858) and DNS over Https (DoH-RFC 8484) protocols were introduced in 2016 and 2018, respectively, which ensure that DNS traffic is encrypted.

First, let’s look at how these 2 protocols work.

DNS-over-TLS

As you know, TLS is a security protocol used for both encryption and authentication. Therefore, when we encrypt DNS traffic with TLS, it becomes DNS over TLS :)

DoT listens on TCP port 853 by default, as mentioned in RFC 7858. Of course, this port number can be changed by making necessary changes on the client and server. Let’s look at an example DoT query;

~% kdig -d @1.1.1.1 +tls-ca +tls-host=one.one.one.one www.google.com
;; DEBUG: Querying for owner(www.google.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 147 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: GP8Knf7qBae+aIfythytMbYnL+yowaWVeD6MoLHkVRg=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
;; DEBUG:      SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 59719
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; PADDING: 405 B

;; QUESTION SECTION:
;; www.google.com.       IN A

;; ANSWER SECTION:
www.google.com.      291 IN A 142.251.39.36

;; Received 468 B
;; Time 2023-12-18 21:21:59 +03
;; From 1.1.1.1@853(TLS) in 139.7 ms

As seen above, a person sniffing the network cannot see anything other than data encrypted with TLS1.3.

What about DNS-over-HTTPS (DoH)?

DoH is simply the execution of DNS traffic using the HTTPS protocol. Just as TLS protocol is used for encryption in DoT, Https protocol is used for encryption in DoH.

In general use, DoH enpoints differ according to MIME type. While Wireformat supports GET and POST methods, Json format only supports GET method. By the way, Content Type and Accept headers also vary depending on these formats. To send queries using DNS Wireformat, set the accept header to (or if you use POST method, content type header) application/dns-message. For json format, accept header application/dns-json is used.

Wireformat is the binary representation of the DNS object. So don’t be surprised when you see such a request or answer :)

~% curl -H 'accept: application/dns-message' -v 'https://cloudflare-dns.com/dns-query?dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | hexdump
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f968700a400)
GET /dns-query?dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
accept: application/dns-message
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
HTTP/2 200
date: Fri, 23 Mar 2018 05:14:02 GMT
content-type: application/dns-message
content-length: 49
cache-control: max-age=0
set-cookie: \__cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=Sat, 23-Mar-19 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly
server: cloudflare-nginx
cf-ray: 3ffe69838a418c4c-SFO-DOG
{ [49 bytes data]
100 49 100 49 0 0 493 0 - : - : - - : - : - - : - : - 494
* Connection
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

An example of the json format, which is a human readable version, is as follows;

~% curl -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=www.google.com&type=A" |jq '.'
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
    {
      "name": "www.google.com",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "www.google.com",
      "type": 1,
      "TTL": 296,
      "data": "142.251.39.4"
    }
  ]
}

However DoH/DoT providers can still monitor who (which organization) made which DNS query. To prevent this, Cloudflare, Apple and Fastly engineers started developing a new protocol called Oblivious DNS over Https (ODoH) in 2021. In ODoH, a 3rd party Proxy comes between the Client and the DoH provider. Public key encryption occurs between the client and the DoH provider, and the proxy does not see the request. However, DoH Provider does not see the real client IP who is making the request, but sees the Proxy IP as the source IP. Thus, the provider does not see who made the request, and the proxy does not see the query sent. In this way, privacy is ensured end-to-end.

https://blog.cloudflare.com/oblivious-dns

There are many DoH service providers on the internet. Such as,

cloudflare-dns.com and one.one.one.one
dns.adguard.com
dns.google and dns.google.com
dns.nextdns.io
dns.opendns.com and doh.umbrella.com
dns.quad9.net

This is where the story begins. The privacy we provide to legitimate users is also provided to attackers with DoH and DoT. This risk provides a significant advantage in hiding attackers’ C2 traffic. At this point, the concept of two edged knives emerges for enterprise networks.

Malicious Usage of DoH

Let’s assume that an enterprise organization monitors the DNS queries made by its clients and servers and checks whether each domain requested is a known malicious domain/newly registered/newly observed/stalled domain. In this case, an attacker who has already somehow infiltrated to local network or an insider threat can use DoH for;

It can bypass DNS control and connect to the C2 server on the internet. You may ask why it does not connect directly to the IP address. In this company with strict security measures, direct access to public IPs may be blocked, or the attacker may be using a DDNS (dynamic DNS) infrastructure to access C2 server over different proxy servers. Using DoH, an attacker can hide the C2 hostname or DDNS queries.
An attacker or insider threat can hide DNS exfiltration by DoH. DNS tunneling may be the subject of another article, but briefly, I can summarize it as the deliberate misuse of DNS for purposes other than its intended purpose. So, you may ask, why isn’t the attacker trying to leak data directly over https? The malicious domain may appear by SNI on the corporate Proxy. When DoH is used, SNI will appear as the DoH provider and may be considered harmless by security systems.

Real Life Stories

The 2 usage scenarios we have given are actually real-life events.

ChamelGang

In the 2nd quarter of 2021, it was detected that a Chinese APT group called ChamelGang was using DoH for C2 communication. The original report, published by Positive Technologies, but Stairwell exposed the DoH implant used in the malware.

{
     ns_record: [
          "ns1.spezialsex[.]com",
          "ns2.spezialsex[.]com"
     ],
     doh: [
          https://8.8.8.8/resolve?type=TXT&name=,
          https://8.8.4.4/resolve?type=TXT&name=,
          https://1.1.1.1/dns-query?type=TXT&name=,
          https://cloudflare-dns.com/dns-query?type=TXT&name=,
          https://dns.google.com/resolve?type=TXT&name=
     ]
}

As can be seen, an attempt was made to hide C2 records by using known legitimate DoH providers.

Flubot

Again in 2021, This time an Android banking trojan named Flubot was announced by F-Secure. This new Flubot variant, announced by F-secure in 2022, uses DoH to mask DNS tunneling with TXT records instead of establishing a direct connection with C2.

https[:]//cloudflare-dns[.]com/dns-query?name=798f300c.2.1.4NLIV5GLKFX6Z2JE6TPBEUMKPRKKSGHUEYFGIQNSS4HOR3GFQO6PGCMI5YJKBSB.IK5XFEVIV3EC2C2MNEJKUPNWNU27SU3WACGD4YARQ.yacwryqiccwhlvm.ru&type=TXT
"Status":0,
    "TC":false,
    "RD":true,
    "RA":true,
    "AD":false,
    "CD":false,
    "Question":[{
        "name":"798f300c.2.1.4NLIV5GLKFX6Z2JE6TPBEUMKPRKKSGHUEYFGIQNSS4HOR3GFQO6PGCMI5YJKBSB.IK5XFEVIV3EC2C2MNEJKUPNWNU27SU3WACGD4YARQ.yacwryqiccwhlvm.ru",
        "type":16
    }],
    "Answer":[{
        "name":"798f300c.2.1.4NLIV5GLKFX6Z2JE6TPBEUMKPRKKSGHUEYFGIQNSS4HOR3GFQO6PGCMI5YJKBSB.IK5XFEVIV3EC2C2MNEJKUPNWNU27SU3WACGD4YARQ.yacwryqiccwhlvm.ru",
        "type":16,
        "TTL":600,
        "data":"\"2.1.Wmzf8e9Nd1xVDjh6oRiomD35/MXuMDTvQsAlbq2x4hGKzaDzZG8PAVQj4gYIwZI=\""
    }]
}

For this campaign, it reached out to the following DNS providers:

https[:]//cloudflare-dns[.]com/dns-query?name=<request>&type=TXT
https[:]//dns[.]google/resolve?name=<request>&type=TXT
https[:]//dns[.]nextdns[.]io/resolve?name=<request>&type=TXT
https[:]//dns[.]alidns[.]com/resolve?name=<request>&type=TXT

As it is understood, the https requests were sent to domains that could be considered legitimate. If this C2 connection was made directly, Threat intelligence services or any security layer could understand that the request was made to an abnormal domain and generate an alarm or even block it. If DNS tunneling were done directly without using DoH, it could still be caught by security layers due to abnormal factors such as length and frequency in the DNS request.

So What Can be Done?

These DoT and DoH solutions, together with DNSSEC, are very useful to prevent DNS traffic from being monitored and manipulated. However, it is recommended to restrict its use in enterprise networks. To ensure this, the following items can be applied.

Block all clients and servers traffic to known public DoH/DoT proxies other than your local DNS servers/DoH proxies. For DoT, this process is relatively easy. DoT can be blocked only by blocking TCP 853. In order to handle the customization of this port by the attacker, clients and servers must be prevented from accessing the Internet other than the required ports.
Blocking DoH is a bit more of a challenge. Because it is usually not possible to block access to the port as we do in DoT. To achieve this, decrypt your outbound Internet traffic and prevent DoH usage at this point. In this way, it will also ensure that DoH requests made directly to the IP address are blocked.
Update your threat database with threat intelligence feeds to block known DoH IPs and DoH domains. Blocking can be done in firewalls, proxies or SaaS and on-premise DNS security layers.

So how do we ensure the privacy of DNS queries made from the enterprise network to internet?

Some DNS service providers that provide special DNS security, such as Cisco or Infoblox, can ensure that DoH or DoT requests are forwarded to their own resolvers by using their own DNS proxy for the enterprise networks. To do this, DoH and DoT settings on the clients must be defined. For DNS security of remote users, agents from these manufacturers can be installed on clients and the client’s DNS traffic can be directed to the DNS security service using DoH.

Privacy for corporate networks by using DoH Proxy

Conclusion

For home users, DoH or DoT may be an important improvement for privacy, but for enterprise organizations, this issue creates a significant security vulnerability. The consequences of the real events I mentioned above can be very severe. At this point, we talked about some precautions that corporates should take. The most important thing is that no settings should be left as default. We cannot know what will be abused.