Troubleshooting DNSSEC SERVFAIL: cek DS, DNSKEY, RRSIG, dan chain of trust dengan dig

Masalah

Gejala DNSSEC yang paling membingungkan adalah domain terlihat benar di authoritative DNS, tetapi resolver publik mengembalikan SERVFAIL. Ini dapat terjadi ketika resolver mengharapkan chain of trust yang valid namun DS, DNSKEY, atau signature tidak lagi cocok. Contoh umum adalah nameserver berpindah tetapi DS lama masih tersimpan di parent zone. Tujuan troubleshooting adalah membuktikan titik putusnya sebelum melakukan perubahan.

1. Ambil baseline dari resolver validating

Mulai dari resolver publik yang melakukan DNSSEC validation. Tujuan langkah ini adalah membuktikan gejala dari sisi client. Perhatikan status pada header, flags, ANSWER SECTION, dan SERVER. Jika status NOERROR dan jawaban tampil normal, jangan langsung menganggap DNSSEC rusak. Jika SERVFAIL konsisten pada validating resolver, lanjutkan ke query dengan validation bypass untuk membedakan error DNSSEC dari error DNS biasa.

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

2. Bandingkan dengan +cd untuk menguji hipotesis DNSSEC

Flag +cd meminta resolver mengembalikan data tanpa memaksakan DNSSEC validation untuk query tersebut. Jika query normal menghasilkan SERVFAIL tetapi query +cd mengembalikan A/AAAA yang masuk akal, itu adalah indikasi kuat bahwa data DNS tersedia tetapi validation gagal. Ini bukan perbaikan dan bukan alasan untuk mematikan DNSSEC; gunakan hanya sebagai bukti diagnosis.

dig @1.1.1.1 example.com A +dnssec
dig @1.1.1.1 example.com A +dnssec +cd

Contoh output simulasi: pola yang perlu diperhatikan

Contoh ini hanya simulasi. Pola pentingnya adalah query validating menghasilkan SERVFAIL, sedangkan +cd mengembalikan jawaban. Jika kedua query sama-sama gagal, masalah dapat berada pada delegasi, authoritative nameserver, connectivity, atau konfigurasi DNS lain sehingga diagnosis harus diperluas.

; validating query
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

; validation disabled with +cd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
example.com. 300 IN A 192.0.2.10

3. Pastikan delegasi NS mengarah ke authoritative yang benar

Sebelum membedah key, pastikan parent zone mendelegasikan domain ke nameserver yang memang aktif. Nameserver lama yang masih terdelegasi dapat membuat hasil tidak konsisten. Bandingkan NS dari resolver publik dengan nameserver yang dikonfigurasi di registrar atau provider DNS. Jika delegasi salah, selesaikan delegasi terlebih dahulu sebelum menilai DS dan DNSKEY.

dig @1.1.1.1 example.com NS
dig example.com NS +trace

4. Periksa DS yang dipublikasikan parent zone

DS berada di sisi parent delegation dan mengikat domain child ke DNSKEY tertentu. Perhatikan key tag, algorithm, digest type, dan digest. Bila provider DNS atau key berubah tetapi DS lama masih ada di parent, validating resolver akan mencoba membangun trust chain menggunakan informasi yang sudah tidak cocok. Catat TTL DS karena perubahan pada registrar tidak selalu langsung terlihat pada semua resolver.

dig example.com DS
dig example.com DS +trace

5. Periksa DNSKEY langsung pada authoritative nameserver

Query DNSKEY pada apex domain ke authoritative nameserver yang benar. DNSKEY dengan flag 257 umumnya digunakan sebagai Key Signing Key/secure entry point, sedangkan key lain dapat digunakan untuk signing RRset. Yang penting untuk troubleshooting adalah memastikan key yang dirujuk oleh DS memang masih tersedia pada zone yang aktif.

dig @nama-ns-authoritative.example example.com DNSKEY +dnssec

6. Pastikan record memiliki RRSIG dan cek flag AD

Gunakan +dnssec untuk meminta DNSSEC records yang relevan. RRSIG menunjukkan RRset ditandatangani. Ketika query melalui validating resolver berhasil dan resolver sudah memvalidasi chain, flag ad dapat muncul pada header sebagai authenticated data. Jangan menyimpulkan valid hanya karena RRSIG ada; signature tetap harus dapat ditelusuri melalui DNSKEY dan DS sampai trust anchor.

dig @1.1.1.1 example.com A +dnssec
dig @1.1.1.1 example.com DNSKEY +dnssec

7. Interpretasikan mismatch DS dan DNSKEY

Bandingkan key tag dan algorithm pada DS dengan DNSKEY yang tersedia. DS juga menyimpan digest dari DNSKEY, jadi kecocokan key tag saja belum cukup sebagai validasi penuh. Jika DS menunjuk key lama yang sudah tidak tersedia, chain menjadi bogus dan resolver validating dapat mengembalikan SERVFAIL. Jika tidak ada DS di parent, zone dapat diperlakukan sebagai insecure delegation meskipun authoritative masih menyajikan DNSKEY/RRSIG; itu berbeda dari broken chain.

8. Tentukan tindakan berdasarkan skenario, bukan tebakan

Jika nameserver baru sudah aktif tetapi DS lama masih ada, perbaikan biasanya berfokus pada DS di registrar/parent sesuai prosedur provider. Jika DS sudah benar tetapi DNSKEY yang dirujuk tidak ada, periksa status DNSSEC/signing pada authoritative provider. Jika authoritative belum berubah tetapi SERVFAIL hanya terjadi pada satu resolver, bandingkan cache dan TTL sebelum membuat perubahan. Untuk migrasi nameserver, urutan perubahan DNSSEC harus direncanakan karena mengubah NS sebelum DS lama kedaluwarsa dapat memutus resolusi validating.

9. Decision path: dari SERVFAIL ke next step

Gunakan alur ini: SERVFAIL pada validating resolver → jalankan +cd. Jika +cd berhasil, periksa NS, DS, DNSKEY, dan RRSIG. Jika NS salah, fokus ke delegasi. Jika NS benar tetapi DS tidak cocok dengan DNSKEY, fokus ke registrar/parent DNSSEC. Jika DS dan DNSKEY tampak konsisten tetapi validation tetap gagal, periksa signature validity, authoritative responses, clock/signing state, dan gunakan DNSViz sebagai pembanding visual. Jika +cd juga gagal, troubleshooting tidak boleh berhenti di DNSSEC; periksa authoritative availability, delegation, network, dan record biasa.

Kesalahan umum

Jangan menghapus DS hanya untuk melihat apakah domain kembali resolve tanpa memahami dampak security dan TTL. Jangan mengganti nameserver dan DNSSEC key sekaligus tanpa urutan migrasi. Jangan menganggap keberadaan DNSKEY berarti DNSSEC aktif end-to-end. Jangan menganggap RRSIG otomatis valid. Jangan menggunakan +cd sebagai setting permanen atau bukti bahwa validation sebaiknya dimatikan.

Checklist verifikasi

Simpan timestamp dan timezone, hasil dua validating resolver, hasil +cd, delegasi NS, DS beserta TTL, DNSKEY authoritative, RRSIG, dan flag AD. Setelah perubahan, ulangi query normal tanpa +cd dari lebih dari satu resolver. Target akhir adalah NOERROR pada validating resolver dengan jawaban yang diharapkan dan chain of trust yang konsisten; bukan sekadar membuat SERVFAIL menghilang dengan menonaktifkan validation.

Contoh visual / prompt gambar

Visual yang paling membantu adalah diagram chain of trust DNSSEC yang memperlihatkan root → TLD/parent → DS → DNSKEY → RRSIG → A record, ditambah cabang merah untuk skenario DS lama yang tidak cocok dengan DNSKEY baru. Jika ingin memakai screenshot nyata, ambil output dig untuk NS, DS, DNSKEY, query +dnssec, dan +cd lalu sensor domain internal, public IP yang tidak perlu, serta identifier sensitif. Prompt gambar siap pakai tersedia pada blok berikut.

Create a clean technical infographic for an Indonesian networking tutorial about DNSSEC troubleshooting. Show a left-to-right trust chain: Client -> Validating Resolver -> Parent Zone (DS) -> Authoritative DNS (DNSKEY + RRSIG) -> A/AAAA answer. Add a second broken path in red where an OLD DS points to a NEW DNSKEY and causes SERVFAIL. Include small labels: '1. Check SERVFAIL', '2. Compare +cd', '3. Verify NS', '4. Compare DS and DNSKEY', '5. Validate RRSIG / AD flag'. Flat vector style, white background, simple network icons, readable Indonesian labels, no brand logos, no fake dashboard screenshots, 16:9.

Pelajaran

DNSSEC troubleshooting menjadi jauh lebih sederhana ketika chain of evidence diikuti dari resolver sampai authoritative key. SERVFAIL hanyalah gejala. Pembeda utama adalah apakah data muncul ketika validation dilewati, apakah delegasi NS benar, apakah DS parent menunjuk DNSKEY yang masih aktif, dan apakah RRset memiliki signature yang dapat divalidasi. Dengan urutan ini, perubahan DNS dapat dilakukan pada komponen yang tepat dan risiko outage tambahan dapat dikurangi.