DNS Publik Mullvad Tutup 2 November: 5 Pengecekan Sebelum Pindah ke Quad9

Versi bahasa Inggris: Mullvad Public DNS Shuts Down Nov 2: 5 Checks I Ran First.

Pada 3 September, Mullvad mengumumkan akan menutup server DNS terenkripsi publik yang mereka jalankan sejak 2022 dan beralih mensponsori Quad9. Kalau Anda tidak pernah mengetik salah satu alamat mereka ke mana pun, silakan berhenti membaca. Saya pernah, lebih dari sekali: satu endpoint DoT di konfigurasi systemd-resolved laptop saya dan satu varian adblock di travel router. Keenam alamat itu, 194.242.2.2 sampai 194.242.2.9, berhenti menjawab pada 2 November 2026.

Migrasinya tampak seperti perubahan satu baris, padahal bukan. Lima dari enam endpoint Mullvad memfilter iklan. Quad9, penerus yang ditunjuk, tidak memfilter iklan di satu pun dari empat varian layanannya. Endpoint Mullvad hanya pernah bicara DNS over HTTPS atau TLS. Quad9 menjawab plaintext di port 53. Ganti alamat tanpa memeriksa kedua fakta itu, dan Anda kehilangan filtering secara diam-diam, lalu enkripsi secara diam-diam. Berikut lima pengecekan yang saya jalankan atau antrekan sebelum menyentuh konfigurasi apa pun.

# Check 1: find Mullvad resolver leftovers in the usual config spots
grep -rnE "194\.242\.2\.[2-9]|2a07:e340|dns\.mullvad\.net" \
  /etc/resolv.conf /etc/systemd/resolved.conf \
  /etc/NetworkManager/conf.d /etc/dnsmasq.conf 2>/dev/null

Contoh hasil yang Anda cari:

/etc/systemd/resolved.conf:27:DNS=194.242.2.4#base.dns.mullvad.net

Apa persisnya yang berhenti berfungsi pada 2 November?

Hanya resolver publik. Pengguna Mullvad VPN tetap memakai DNS internal di dalam tunnel, dan itu memang setup yang selalu direkomendasikan. Layanan publik ini ada untuk dua kasus: pengguna Mullvad Browser di luar VPN, dan siapa pun yang mengarahkan perangkat langsung ke sana. Ini tabel endpoint lengkap dari dokumentasi Mullvad, karena pengumumannya tidak pernah merinci apa yang dilakukan tiap alamat:

Hostname	IPv4	Yang difilter
dns.mullvad.net	194.242.2.2	tidak ada
adblock.dns.mullvad.net	194.242.2.3	iklan, tracker
base.dns.mullvad.net	194.242.2.4	iklan, tracker, malware
extended.dns.mullvad.net	194.242.2.5	+ media sosial
family.dns.mullvad.net	194.242.2.6	+ dewasa, perjudian
all.dns.mullvad.net	194.242.2.9	semua daftar

Tiga kelompok punya pekerjaan rumah. Siapa pun yang mengonfigurasi manual salah satu alamat ini di router, OS, atau browser. Siapa pun yang memakai profil iOS atau macOS dari Mullvad, yang menurut Mullvad akan berhenti bekerja dan perlu diganti dengan profil Quad9. Dan pengguna Mullvad Browser yang mengubah DoH-nya, karena Mullvad secara eksplisit tidak akan menyentuh pengaturan yang sudah dikustomisasi; hanya konfigurasi default dan adblock bawaan yang dimigrasikan otomatis ke Quad9.

Satu detail mekanisme yang perlu diketahui: filtering Mullvad bekerja dengan menjawab NXDOMAIN untuk domain yang diblokir. Dokumentasi mereka menyatakannya terang-terangan: resolver “simply lies to the client and says that the hostname does not exist”. Daftar blokirnya ada di GitHub, jadi Anda bisa membangun ulang perilaku yang sama sendiri nanti kalau mau.

Bagaimana menemukan semua perangkat yang masih mengarah ke Mullvad?

Grep pertama saya hanya mencocokkan alamat IP. Ia melewatkan dua konfigurasi yang merujuk hostname, termasuk sintaks IP#hostname systemd-resolved yang terlihat di contoh di atas. Pola yang sudah dikoreksi mencocokkan keduanya, ditambah prefiks IPv6, yang membuat saya menemukan baris 2a07:e340::4 basi di clone VM yang sudah diam-diam mati berbulan-bulan.

Browser tidak menyimpan pengaturan DoH di file-file di atas. Firefox menyimpan provider kustomnya di about:config pada network.trr.uri, dan browser Chromium menampilkan provider secure DNS di Settings, Privacy and security, Security. Tidak ada grep untuk itu; ini pengecekan manual dua menit per mesin.

Windows butuh pengecekan sendiri, karena Windows 11 menyimpan template DoH per adapter terpisah dari alamat resolver:

# Check 2: Windows 11 per-adapter DoH templates pointing at Mullvad
Get-DnsClientDohServerAddress | Where-Object DohTemplate -match "mullvad"

Mengecek profil Apple tanpa menebak

Di iOS dan macOS, profil Mullvad berasal dari repo GitHub encrypted-dns-profiles mereka. Buka Settings, lalu General, lalu VPN and Device Management di iOS (Device Management di macOS), dan cari apa pun yang bernama Mullvad. Profil itu tidak ter-update otomatis; Mullvad menyatakan profil tersebut berhenti bekerja pada 2 November. Quad9 menyediakan profil setara untuk iOS dan macOS di panduan setup mereka, dan menggantinya butuh sekitar satu menit per perangkat.

Amankah menempel 9.9.9.9 ke slot Mullvad lama?

Ini pengecekan yang hampir saya lewati, dan justru yang paling penting. Dokumentasi Mullvad menyatakan IP mereka “can only be used with DNS resolvers that support DoH or DoT, not with DNS over UDP/53 or TCP/53”. Endpoint mereka tidak pernah menjawab query plaintext di port 53, selain listener terbatas hanya untuk bootstrap hostname mereka sendiri. Slot Mullvad lama Anda menjamin transport terenkripsi secara kebetulan karena sifat endpoint-nya.

Quad9 adalah resolver publik biasa. Ia menjawab plaintext di port 53 by design, dengan 9953 sebagai port alternatif untuk jaringan yang ketat. Tempel 9.9.9.9 ke kolom DNS biasa yang tadinya berisi 194.242.2.4, dan resolusi jalan di hari pertama. Transportnya diam-diam berubah dari TLS ke cleartext, dan tidak ada yang akan memperingatkan Anda.

Solusinya adalah mengonfigurasi transport secara eksplisit, per slot:

# systemd-resolved: pin DoT with the hostname, not just the IP
# in /etc/systemd/resolved.conf under [Resolve]
DNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes
Domains=~.

# Windows 11: set the IP, then set DNS over HTTPS to "On (manual template)"
# Preferred DNS: 9.9.9.9
# DNS over HTTPS template: https://dns.quad9.net/dns-query

Membaca jawaban resolvectl dengan jujur

resolvectl status seharusnya menampilkan server Quad9 Anda di bagian global atau per-link dengan “DNS Over TLS: yes”. Satu catatan yang saya pelajari dari dokumentasi Mullvad sendiri dan terkonfirmasi berlaku juga di sini: DNSOverTLS=opportunistic berarti resolver boleh turun ke plaintext saat TLS gagal. Kalau konfigurasi Anda bertuliskan opportunistic, yang Anda punya adalah preferensi enkripsi, bukan jaminan. Dan dig @9.9.9.9 example.com akan dengan senang hati mengembalikan jawaban lewat port 53, karena memang itu yang disajikan Quad9. Dengan endpoint filtering Mullvad, dig yang sama tidak akan mendapat jawaban sama sekali. Perbedaan itu adalah seluruh jebakannya dalam satu perintah.

Apa yang terjadi pada ad blocking setelah pindah?

Tidak ada, by design. Dokumentasi Quad9 sendiri mencantumkan empat varian layanan, dan tidak satu pun memfilter iklan atau tracker:

Varian Quad9	IPv4	Fungsinya
Secure	9.9.9.9, 149.112.112.112	validasi DNSSEC, pemblokiran malware
No Threat Blocking	9.9.9.10	rekursif murni, tanpa filtering
Secure + ECS	9.9.9.11	Secure, plus EDNS Client Subnet untuk routing CDN
No Threat Blocking + ECS	9.9.9.12	tanpa filter dengan ECS

Pemblokiran malware dan phishing adalah ruang lingkup Quad9, dan FAQ mereka menyatakan tidak ada rencana menambah content filtering. Jadi siapa pun yang memakai salah satu dari lima endpoint filtering Mullvad kehilangan ad blocking dalam migrasi ini, dan halaman web jadi lebih ramai beberapa minggu kemudian tanpa ada yang tampak rusak. Itulah mode kegagalan paling sunyi dalam seluruh cerita ini.

Perbandingan yang akan saya jalankan sebelum cutover, selagi kedua layanan masih hidup:

# Check 4: compare resolver behavior over DoH (pip install dnspython)
import dns.message, dns.query, dns.rcode

RESOLVERS = {
    "Mullvad adblock (still up today)": "https://adblock.dns.mullvad.net/dns-query",
    "Quad9 secure (the successor)":     "https://dns.quad9.net/dns-query",
}
DOMAINS = {
    "doubleclick.net":          "ad canary",
    "malware.testcategory.com": "Quad9's own malware test domain",
}

for label, url in RESOLVERS.items():
    print(label)
    for domain, note in DOMAINS.items():
        query = dns.message.make_query(domain, "A")
        answer = dns.query.https(query, url)
        print(f"  {domain:26s} {dns.rcode.to_text(answer.rcode()):9s} {note}")

Berdasarkan perilaku yang didokumentasikan masing-masing provider, bentuk yang diharapkan: Mullvad adblock menjawab NXDOMAIN untuk kedua domain, Quad9 secure me-resolve ad canary seperti biasa dan mengembalikan respons blokir untuk domain uji malware. Agar jujur soal proses saya: saya belum menjalankan ini di bench, jadi anggap ekspektasi tersebut hipotesis, dan script-nya adalah alat yang mengubahnya menjadi data sebelum 2 November.

Kalau Anda ingin filtering kembali, opsi yang realistis adalah uBlock Origin di browser (yang direkomendasikan Mullvad sendiri, dan menangani iklan lebih baik daripada filtering DNS), kotak Pi-hole atau AdGuard Home di LAN Anda dengan Quad9 sebagai upstream-nya, atau resolver terkelola lain seperti AdGuard DNS yang masih menawarkan tingkat filtering.

Ke mana query Anda pergi saat Mullvad mati?

Perangkat jarang punya tepat satu resolver. Saat yang primer berhenti menjawab, yang sekunder mengambil alih, dan sekunder biasanya apa pun yang dibagikan DHCP: resolver ISP Anda. Semuanya tetap jalan. Query Anda hanya pergi ke pihak yang justru ingin Anda hindari saat mengonfigurasi DNS terenkripsi.

Dua default yang masing-masing masuk akal bergabung menjadi hasil yang buruk di sini: resolver sekunder ada demi keandalan, dan resolver primer mati di tanggal yang pasti. Saya sering menemui pola ini, di mana tidak ada yang salah konfigurasi tetapi gabungannya tetap gagal. Pelajarannya sama dengan dua CVE sandbox agent CVSS 9.8 yang muncul di hari yang sama: tinjau default sebagai sebuah sistem, bukan baris per baris.

Check 5 murah: pilih sekunder Anda sendiri dengan sengaja (149.112.112.112 kalau Anda tetap di Quad9), lalu sebelum 2 November arahkan primer ke alamat mati selama satu menit dan pantau resolvectl status untuk melihat ke mana query Anda sebenarnya pergi. Lebih baik tahu itu di Selasa sore daripada di 3 November.

Haruskah Mullvad tetap menjalankan resolver itu?

Ini argumen yang ingin saya bahas. Alasan Mullvad adalah bahwa resolver publik yang berfokus pada privasi adalah usaha yang sangat spesifik dan Quad9, dalam kata mereka, adalah pemimpin tak terbantahkan di bidangnya, jadi mendanainya lebih baik daripada menduplikasi sebagian kecilnya. Saya anggap itu bisa dipertahankan. Menjalankan infrastruktur anycast, merawat blocklist, dan menjawab email abuse adalah kerja operasional yang nyata, dan resolver yang dirawat setengah-setengah lebih buruk daripada yang didanai baik.

Tetapi dua hal mengganggu saya. Pertama, migrasi otomatis: pengguna Mullvad Browser dengan default terfilter bangun dengan resolver yang memfilter secara berbeda dan tidak pernah ditanya. Dampak nyatanya kecil, untuk adil, karena Mullvad Browser membawa uBlock Origin, jadi ad blocking browser memang tidak hidup di DNS. Yang benar-benar terdampak adalah pengguna manual dari lima endpoint filtering, dan mereka setidaknya mendapat tenggat. Kedua, konsentrasi: makin banyak DNS dari internet yang peduli privasi kini berjalan di balik satu yayasan Swiss, sebagian didanai oleh vendor yang penggunanya bergantung padanya. Apakah satu Quad9 yang sangat baik lebih baik daripada selusin resolver kecil? Saya sungguh tidak tahu. Ini senada dengan pola yang sering saya temui, dari session handle stateless yang berubah jadi kredensial sampai slot resolver yang diam-diam tidak lagi bermakna seperti tulisannya: batas kepercayaan yang bergeser sementara teks konfigurasinya sama persis.

Infrastruktur DNS sedang punya minggu yang ramai, dengan RCE Windows DNS Server CVSS 9.8 di sisi server dan ini di sisi resolver. Pendapat saya setelah meliput keduanya: resolver adalah infrastruktur, dan infrastruktur yang Anda konfigurasi sekali lalu tidak pernah diverifikasi ulang adalah liabilitas dengan nama yang ramah.

Apa yang perlu dibawa pulang?

• Enam endpoint Mullvad mati pada 2 November 2026; lima di antaranya memfilter iklan, dan tidak ada varian Quad9 yang memfilter iklan sama sekali.
• Jebakan transport itu nyata: endpoint Mullvad memaksa DoH/DoT, Quad9 menjawab plaintext di port 53, jadi konfigurasikan hostname DoT atau template DoH Windows secara eksplisit alih-alih sekadar menukar IP.
• Audit dengan urutan ini: file konfigurasi, template DoH Windows, profil Apple, pengaturan browser, lalu pilih resolver sekunder Anda sendiri sebelum fallback memilihkan ISP Anda.

Jadi, giliran Anda: apakah Anda pindah ke Quad9, lompat ke AdGuard DNS demi tingkat filtering, atau sekarang self-host unbound? Dan pertanyaan yang lebih tajam di bawahnya: haruskah vendor privasi pernah mengubah apa yang difilter sebuah layanan, bahkan lewat migrasi otomatis, tanpa bertanya dulu? Kecenderungan saya, serah-terima ke Quad9 adalah keputusan yang tepat dan penurunan filtering yang diam-diam adalah bagian yang layak diperdebatkan.

Sumber primer: Pengumuman Mullvad (3 Sep) · Dokumentasi DoH/DoT Mullvad, tabel endpoint · Alamat layanan dan fitur Quad9 · Panduan setup Quad9 · Analisis migrasi PacketNebula (5 Sep) · mullvad/dns-blocklists