Tema

Alat populer

Cek Kesehatan DNS

Cek DNS domain, atau validasi domain untuk DNS: delegasi dari registri, setiap nameserver yang ditanyai langsung, SOA, DNSSEC, dan record email. 40 pengecekan, masing-masing dengan perbaikannya.

Tingkat dari Zonemaster dan RFC · setiap nameserver ditanyai lewat TCP · Google Public DNS · RDAP

Menelusuri dari server root ke registri .nl, lalu bertanya langsung ke setiap nameserver sidn.nl · 40 pengecekan · sekitar 3 detikregistri .nl → setiap nameserver · 40 pengecekan

Coba
ContohDirekam 23 Okt 2026 · dari server kami.nl3 NSDNSSEC ditandatangani

sidn.nl lulus setiap pengecekan yang dijalankan, termasuk DNSSEC

terdaftar di SIDN·2,9 dtk

40 lulus

A+: tidak ada yang di atas info. Setiap nameserver menjawab dengan otoritas dan sepakat dengan yang lain, timernya berada dalam rentang Zonemaster, dan Google Public DNS memvalidasi rantai DNSSEC dari root.

Masalah lebih dulu

Ditanyakan lewat TCP dari server kami di edge Cloudflare: root, registri .nl, dan setiap nameserver secara langsung; Google Public DNS dan Cloudflare untuk record email dan validasi. Kami tidak menyimpan log apa pun dari yang Anda cek.

Apa saja yang diuji saat cek DNS domain?

Cek kesehatan DNS menelusuri sebuah domain seperti cara resolver menemukannya dan menguji setiap langkahnya: delegasi dari registri, setiap nameserver yang ditanyai langsung, apakah server-server itu sepakat, record SOA, DNSSEC, dan record email. Alat ini menjalankan 40 pengecekan dalam tujuh kelompok dan menilai masing-masing pada tingkat yang ditetapkan otoritasnya.

Kebanyakan alat cek DNS bertanya ke resolver lalu menilai apa yang kembali. Cara itu menyembunyikan server di baliknya: resolver menjawab dari nameserver mana pun yang berfungsi, jadi server yang rusak tetap tak terlihat sampai server lainnya ikut gagal. Di sini setiap nameserver ditanyai lewat TCP dengan rekursi mati, salinan record NS milik registri dibandingkan dengan milik zona sendiri, dan rantai DNSSEC diverifikasi dari DS di registri sampai tanda tangan di dalam zona.

Gunakan sebagai audit DNS setelah setiap perubahan: alat ini mengecek DNS record yang diandalkan sebuah domain, bukan hanya apakah situsnya terbuka (untuk itu, Cek Website Down memeriksa situsnya sendiri). Salin laporan mengubah hasilnya menjadi laporan DNS berupa teks biasa yang bisa Anda tempel ke tiket.

Rooth.root-servers.net
.comRegistri .comh.gtld-servers.net
8 nameserverRoute 53 + NS1
Zonagithub.com
  • DNSSEC7 pengecekanrantai kepercayaan dari root: github.com berhenti di .com (tanpa DS)
  • Induk & delegasi6 pengecekanreferral dari registri: 8 nama · 295 byte · tidak perlu glue
  • Nameserver14 pengecekansetiap server ditanyai langsung: 8 dari 8 otoritatif · lewat TCP · EDNS · tanpa rekursi
  • Konsistensi3 pengecekanapakah server-server sepakat: 2 serial SOA, satu per penyedia DNS · MX dan SPF yang sama
  • SOA4 pengecekantimer di bawah batas bawah Zonemaster: catatan
  • CAA1 pengecekan7 record · 4 CA diizinkan
  • DNS email5 pengecekanMX di Microsoft 365 · SPF 10 dari 10 lookup · DMARC quarantine
Tempat setiap kelompok pengecekan melihat, pada jalur nyata github.com (23 Oktober 2026): dari root melalui registri .com ke nameserver zona di Route 53 dan NS1.
Hasil cek DNS untuk github.com: nilai A, 40 pengecekan dalam tujuh kelompok, dan jalur dari root ke 8 nameserverHasil cek DNS untuk github.com: nilai A, 40 pengecekan dalam tujuh kelompok, dan jalur dari root ke 8 nameserverNilaiHanya dari tingkat temuan: tanpa kritis, tanpa kesalahan, dua peringatan menghasilkan A. Cincinnya menunjukkan skor, 90 dari 100.40 pengecekan, satu sel masing-masingDikelompokkan seperti urutan di halaman. Sel kuning dan biru adalah peringatan dan catatan; sel berarsir tidak bisa dijalankan.Masalah lebih duluKelompok yang punya sesuatu untuk diperbaiki terbuka paling atas, setiap baris dengan otoritas dan perbaikannya.JalurnyaSebuah server root, registri .com yang dijalankan Verisign, lalu setiap nameserver yang ditanyai langsung: jawaban, serial, dan EDNS-nya.Rantai kepercayaanJalur DNSSEC di samping jalur utama: hijau jika tersambung, putus-putus jika berhenti, merah jika rusak.
Cek kesehatan DNS untuk github.com. Pilih sebuah nomor untuk melihat apa yang ditunjukkan setiap bagian.

Bagaimana nilainya dihitung?

Huruf nilai hanya berasal dari tingkat temuan yang gagal, tidak pernah dari tabel poin: masalah kritis apa pun berarti F, dua kesalahan atau lebih D, satu kesalahan atau lima peringatan atau lebih C, tiga atau empat peringatan B, satu atau dua peringatan (atau hanya catatan) A, dan tidak ada yang di atas info A+.

Tingkatnya adalah milik otoritas yang dikutip: profil default Zonemaster jika Zonemaster mendefinisikan ujinya, MUST atau SHOULD dari RFC jika tidak. Angka dari 100 hanya mengurutkan domain di dalam satu huruf (100 − 30 per kritis, 12 per kesalahan, 4 per peringatan, 1 per catatan). Pengecekan yang tidak bisa dijalankan server kami tidak pernah merugikan domain; jika seperempat atau lebih tidak bisa dijalankan, nilainya bertanda sebagian.

  1. A+100tidak ada yang di atas infoINFO “jelas tidak menunjukkan adanya masalah”sidn.nl100
  2. A90–991–2 peringatan, atau hanya catatanNOTICE “perlu diketahui oleh administrator zona, tetapi belum tentu merupakan masalah sama sekali”github.com90example.com95bücher.de90
  3. B75–893–4 peringatanWARNING “dalam keadaan tertentu akan menjadi masalah, tetapi kemungkinan besar tidak disadari oleh pengguna biasa”cloudflare.com87google.com83
  4. C60–741 kesalahan, atau 5 peringatan atau lebihERROR “sangat mungkin (atau bahkan pasti) berdampak buruk pada fungsi zona”tidak ada di sampel
  5. D45–592 kesalahan atau lebihdnssec-failed.org55
  6. F0–44masalah kritis apa punCRITICAL “secara wajar dapat dikatakan tidak ada”sebuah domain .com44

skor = 100 − 30 × kritis − 12 × kesalahan − 4 × peringatan − 1 × catatan, tetap di dalam rentang hurufnya

sebagianseperempat atau lebih pengecekan tidak bisa dijalankan dari server kami, jadi nilainya menyatakan hal itu

Tangga nilai, dengan domain yang kami cek pada 23 Oktober 2026 ditempatkan menurut nilai yang terekam. Tingkat dikutip dari definisi tingkat keparahan Zonemaster.

Apakah record NS induk dan anak cocok?

Seharusnya cocok: registri (induk) dan zona (anak) masing-masing mempublikasikan set NS, dan RFC 1912 §2.8 meminta keduanya dibuat sama. Jika registri menunjuk ke server yang tidak menjawab untuk zona itu, itulah delegasi lame: server menjawab REFUSED, atau menjawab tanpa flag otoritatif (AA).

Resolver pindah ke server berikutnya, jadi satu server lame membuang waktu; jika setiap server yang tercantum lame, domain berhenti ter-resolve. Zonemaster menilai nama yang hanya dicantumkan registri sebagai kesalahan (EXTRA_NAME_PARENT), nama yang hanya dicantumkan zona sebagai catatan, dan tidak adanya server yang berfungsi sama sekali sebagai kritis.

github.comcocok

Registri .com
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
Zona
  • 8 yang sama

8 dari 8 menjawab dengan AA

sebuah domain .nettidak cocok

Registri .net
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
Zona
  • ns1.hover.com
  • ns2.hover.com

tidak ada nama yang sama · ns2.domaindirect.com REFUSED · 2 kesalahan

sebuah domain .comdelegasi lame

Registri .com
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
Zona
  • tidak ada yang menjawabSERVFAIL

setiap server REFUSED · resolver menjawab SERVFAIL · CRITICAL

Tiga delegasi yang direkam pada 23 Oktober 2026. Nama dua delegasi yang rusak dirahasiakan; nameserver dan jawabannya nyata.

Berapa banyak nameserver yang dibutuhkan sebuah domain?

Minimal dua, dan yang disarankan tiga. RFC 1034 §4.1 mewajibkan setiap zona tersedia di setidaknya dua server, dan RFC 2182 §5 menyarankan tiga untuk kebanyakan zona tingkat organisasi. Satu nameserver adalah kesalahan di Zonemaster; dua lolos dengan catatan info.

Lokasinya lebih penting daripada jumlahnya, jadi cek nameserver ini juga melihat jaringannya. Server dalam satu jaringan gagal bersama-sama: Zonemaster memberi peringatan jika setiap alamat berada di satu autonomous system (IPV4_ONE_ASN), bahkan untuk host anycast seperti Google, Cloudflare, atau Akamai, yang setiap alamatnya menjawab dari banyak lokasi. Anycast menyebarkan beban; operatornya tetap satu.

  • google.com4 NS · 1 jaringansatu jaringan
  • github.com8 NS · 2 jaringantersebar
  • sidn.nl3 NS · 2 jaringantersebar
  • cloudflare.com5 NS · 1 jaringansatu jaringan
  • nasa.gov6 NS · 1 jaringansatu jaringan
  • example.com2 NS · 1 jaringansatu jaringan

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

“Disarankan agar tiga server disediakan untuk sebagian besar zona tingkat organisasi, dengan setidaknya satu yang harus berada jauh dari yang lain.” RFC 2182 §5
Satu titik per nameserver, diwarnai menurut jaringan (AS) tempat alamatnya diumumkan, dari pengecekan yang direkam pada 23 Oktober 2026. Satu jaringan saja adalah peringatan IPV4_ONE_ASN dari Zonemaster, anycast atau bukan.

Apakah nilai record SOA Anda sudah benar?

Jika diatur oleh penyedia DNS besar, nilainya hampir pasti baik-baik saja, meskipun ditandai oleh alat cek. Refresh, retry, dan expire hanya mengatur server sekunder yang menyalin zona lewat zone transfer. Minimum adalah TTL negative caching (RFC 2308): berapa lama resolver mengingat bahwa sebuah nama tidak ada.

RIPE-203 (1999) menyarankan refresh 86400, retry 7200, expire 3600000, dan minimum 172800; yang terakhir berasal dari masa sebelum RFC 2308. Zonemaster menetapkan batas bawah yang lebih rendah: refresh 14400 dan retry 3600 (catatan), expire 604800 (satu-satunya peringatan), minimum antara 300 dan 86400 (catatan). Nilai default Cloudflare, Route 53, dan Azure berada di bawah batas bawah refresh dan retry; expire 3 hari milik Google Cloud DNS adalah satu-satunya peringatan di antara penyedia besar.

refreshZonemaster ≥ 4 j · ◆ 1 hrretryZonemaster ≥ 1 j · ◆ 2 jexpireZonemaster ≥ 7 hr · ◆ 41,7 hrminimumZonemaster 5 mnt – 1 hr · ◆ 2 hr
Cloudflare2,8 j40 mnt7 hr30 mnt2 catatan
Amazon Route 532 j15 mnt14 hr1 hr2 catatan
Google Cloud DNS6 j1 j3 hr5 mnt1 peringatan
Azure DNS1 j5 mnt28 hr5 mnt2 catatan
GoDaddy8 j2 j7 hr1 jlulus
Namecheap BasicDNS12 j1 j7 hr1 jlulus
google.com (milik sendiri)15 mnt15 mnt30 mnt1 mnt1 peringatan · 3 catatan

di bawah batas bawah ZonemasterluluscatatanperingatanRIPE-203 (1999)

Nilai setiap penyedia seperti yang disajikan zonanya lewat dig pada 23 Oktober 2026: Cloudflare, Route 53, dan Google Cloud DNS sesuai dengan dokumentasinya; halaman bantuan GoDaddy menyebut minimum 600, tetapi zona contohnya menyajikan 3600; kami tidak menemukan nilai default yang dipublikasikan untuk Azure DNS atau Namecheap BasicDNS, jadi nilainya diambil dari zona mereka. Skala log dari 1 menit sampai 6 minggu.

Cek DNSSEC: DS, DNSKEY, dan tanda tangan

Cek DNSSEC menelusuri rantai kepercayaan: record DS di registri harus merupakan digest dari sebuah kunci (DNSKEY) di zona, kunci itu harus menandatangani set kunci zona, dan setiap tanda tangan (RRSIG) harus terverifikasi dan masih dalam masa berlakunya. Alat ini menghitung digest dan memverifikasi setiap tanda tangan sendiri, lalu bertanya ke Google Public DNS apakah zona itu tervalidasi.

Jika satu mata rantai saja putus, resolver yang memvalidasi menjawab SERVFAIL: domain hilang bagi semua pengguna di belakangnya. dnssec-failed.org, zona uji yang sengaja dibiarkan rusak, menunjukkan dua kerusakan sekaligus. Algoritma dinilai berdasarkan registri IANA (RFC 9904): 8, 13, dan 15 disarankan, sedangkan 5 dan 7, yang menandatangani dengan SHA-1, tidak boleh dipakai lagi (RFC 9905) dan dinilai Zonemaster sebagai kesalahan.

cloudflare.comaman

  1. DS 2371 di .comalgoritma 13 · SHA-256 · 329968…26F2B9
  2. digest cocok dengan kunci 2371
  3. DNSKEY 2371 · KSKflag 257 · ECDSA P-256 (13)
  4. menandatangani set kunci · sisa 50,8 hari dari 61 hari
  5. DNSKEY 34505 · ZSKflag 256 · ECDSA P-256 (13)
  6. menandatangani record · SOA: sisa 1 hari dari 2 hari
  7. Google Public DNSflag AD diatur: aman

dnssec-failed.orgtidak valid

  1. DS 42069 di .orgalgoritma 13 · SHA-256
  2. tidak ada kunci 42069 di zona
  3. DNSKEY 50719 · KSKkey-signing key asli milik zona
  4. tanda tangannya pada set kunci kedaluwarsa 112 hari yang lalu
  5. DNSKEY 32784 · ZSKmenandatangani SOA: valid, sisa 5,7 hari dari 7 hari
  6. tidak ada yang tepercaya yang menjangkaunya
  7. Google Public DNSSERVFAIL; menjawab setelah CD diatur: tidak valid

Algoritma penandatanganan (registri IANA, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519gunakan ini
  • MAY14 ECDSAP384SHA384 · 16 ED448diizinkan
  • NOT RECOMMENDED10 RSASHA512Zonemaster WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster ERROR

kedua rantai di atas menandatangani dengan 13

Dua rantai yang direkam pada 23 Oktober 2026: rantai cloudflare.com utuh; rantai dnssec-failed.org putus di DS dan sekali lagi di tanda tangan yang kedaluwarsa.

DNS email: MX, SPF, dan DMARC

Pengecekan email membaca apa yang dibaca server penerima: record MX (atau null MX yang menyatakan domain tidak menerima email, RFC 7505), satu record SPF dalam batas 10 DNS lookup dari RFC 7208, dan kebijakan DMARC (RFC 9989, yang menggantikan RFC 7489 pada Mei 2026).

SPF dievaluasi, bukan sekadar ditemukan: setiap include diikuti dan dihitung. Record milik github.com butuh tepat 10 lookup ditambah satu void lookup: valid, tanpa sisa ruang. Domain yang tidak pernah mengirim email sebaiknya menyatakannya: example.com mempublikasikan set untuk domain parkir, yaitu null MX, v=spf1 -all, dan p=reject. Untuk detailnya, pemeriksa SPF dan pemeriksa DMARC membahas lebih jauh.

github.commengirim dan menerima

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 1 host · bukan alias
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all10 dari 10 DNS lookup1 dari 2 void lookup · valid, tanpa sisa ruang
DMARC
p=quarantine; sp=rejectmelapor ke 1 alamat · subdomain: reject

example.comset domain parkir

MX
0 .null MX: tidak menerima email (RFC 7505)
SPF
v=spf1 -alltidak mengirim email · 0 lookup
DMARC
p=reject; sp=rejectapa pun yang mengaku sebagai example.com ditolak
github.com dan example.com, seperti yang dipublikasikan pada 23 Oktober 2026.

Cek DNS dari baris perintah (dig)

Empat langkah dengan dig dan delv mengulang inti pengecekan ini: ikuti delegasi dari root, tanyai satu nameserver langsung dengan rekursi mati, bandingkan DS di registri dengan kunci zona, dan biarkan resolver yang memvalidasi menilai rantainya.

Tambahkan +tcp untuk melihat apa yang dilihat server kami; hilangkan untuk menguji UDP, yang tidak bisa dilakukan alat web di jaringan Cloudflare. Di header jawaban, aa menandai jawaban otoritatif; REFUSED, atau tidak adanya flag aa dari server yang dicantumkan registri, berarti delegasi lame.

Terminal · dig 9.20

$ dig +trace +tcp github.com NS
;; (dipersingkat)
com.          172800 IN NS a.gtld-servers.net.   ;; dari h.root-servers.net 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; dari h.gtld-servers.net: 8 NS 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; tanpa DS: tidak ditandatangani 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. Root merujuk .com ke 13 servernya
  2. Set NS registri untuk github.com, disimpan 2 hari
  3. aa: jawaban otoritatif, bukan cache
  4. SOA: serial 1, lalu refresh, retry, expire, minimum
  5. Tidak ada DS di .com: tidak ada yang perlu diverifikasi DNSSEC
  6. delv memvalidasi rantai dari root
Jawaban nyata untuk github.com dan cloudflare.com (23 Oktober 2026), dipersingkat. Tanda bernomor sesuai dengan catatannya.

Mengapa hasil alat cek DNS berbeda-beda?

Karena patokan angkanya berbeda. Alat cek klasik menandai nilai default penyedia: intoDNS menyebut expire 1800 detik milik google.com “NOT OK” dan memberi error pada dua serial github.com, yang wajar untuk dua penyedia DNS. Zonemaster menilai serial itu sebagai peringatan dan mengenali null MX; versi pertama alat kami sendiri keliru di keduanya.

Selain itu, mereka melihat jaringan dari tempat yang berbeda. Zonemaster (AFNIC dan Swedish Internet Foundation) bertanya lewat UDP dan TCP, di IPv4 dan IPv6. Pengecekan ini berjalan di edge Cloudflare: hanya bertanya lewat TCP, tidak menghubungi IPv6, dan tidak bisa terhubung ke alamat milik Cloudflare sendiri, jadi server-server itu dibaca lewat 1.1.1.1 dan pengecekannya ditandai tidak diuji, tidak pernah gagal. Sebagai alternatif intoDNS, alat ini menunjukkan otoritas di balik setiap tingkat, bukan sekadar OK atau NOT OK.

KasusintoDNSZonemasterDNS Robot v1Pengecekan ini
github.comdua serial SOA (dua penyedia DNS)kesalahan“Looks like your nameservers do not agree on the SOA serial.”peringatanMULTIPLE_SOA_SERIALSgagal“Serial mismatch detected: 1656468023 vs 1.”peringatandijelaskan: satu serial per penyedia DNS
google.comexpire SOA 1.800 dtktidak ok“Your SOA EXPIRE number is: 1800. That is NOT OK”peringatanEXPIRE_MINIMUM_VALUE_LOWERgagal“too low (min recommended: 14 days)”peringatanbeserta apa yang dipengaruhi expire
example.comnull MX (0 .)kesalahan“0 No A Record (no glue either)”infoZ09_VALID_NULL_MXlulus“Found 1 MX record(s)”lulusnull MX dikenali
cloudflare.comretry SOA 2.400 dtk—tidak dikutipcatatanRETRY_MINIMUM_VALUE_LOWERgagal“too high (max recommended: 15min)”catatandefault Cloudflare
cloudflare.comditandatangani dengan DNSSECtidak dicektanpa uji DNSSEClulusDNSSEC02 · 05 · 08: rantai terverifikasiperhatian“DNSSEC does not appear to be enabled for this domain.”lulusDS → KSK → RRSIG terverifikasi, Google memvalidasi
Domain yang sama di empat alat cek. Hasil intoDNS dan v1 dikutip dari halaman dan jawabannya pada 22–23 Oktober 2026; tingkat Zonemaster dari spesifikasi ujinya. Kolom terakhir adalah pengecekan ini: alternatif intoDNS yang menilai setiap temuan pada tingkat yang ditetapkan otoritasnya.

Cek kesehatan DNS: pertanyaan yang sering diajukan

Apa itu cek kesehatan DNS?

Cek kesehatan DNS, atau validasi DNS, menguji apakah DNS sebuah domain diatur agar bisa dijangkau dari seluruh internet: delegasi dari registri, setiap nameserver, record SOA, DNSSEC, dan record email. Setiap temuan dinilai menurut seberapa besar dampaknya, dari info sampai kritis, dan validator DNS ini menunjukkan aturan yang dipakainya (sebuah uji Zonemaster atau bagian RFC) beserta perbaikannya.

Apakah validasi domain sama dengan cek kesehatan DNS?

Tidak selalu. “Validasi domain” juga merujuk pada pengecekan yang dilakukan otoritas sertifikat sebelum menerbitkan sertifikat DV, dan pada record TXT yang diminta Google Workspace atau Microsoft 365 untuk membuktikan bahwa Anda pemilik domain. Validator domain ini mengecek DNS domain: delegasi, nameserver, SOA, DNSSEC, dan record email. Untuk sertifikat, lihat pemeriksa SSL.

Apa itu delegasi lame dan bagaimana cara memperbaikinya?

Delegasi lame adalah nameserver yang dicantumkan registri tetapi tidak menjawab untuk domain Anda: server itu menjawab REFUSED atau menjawab tanpa otoritas. Perbaiki di sisi tempat ketidakcocokannya berada: tambahkan zona di penyedia DNS tersebut, atau ganti nameserver di registrar ke server yang memegang zonanya. Jika setiap server yang tercantum lame, domain sama sekali tidak ter-resolve.

Penyedia DNS saya memakai anycast. Mengapa ada peringatan satu jaringan?

Karena satu operator berarti satu sumber kegagalan. Anycast membuat setiap alamat menjawab dari banyak lokasi, yang melindungi dari matinya satu lokasi, bukan dari gangguan penyedia itu sendiri atau kesalahan dalam konfigurasinya. Karena itulah Zonemaster mempertahankan IPV4_ONE_ASN di tingkat peringatan, dan RFC 2182 meminta server di jaringan yang beragam. Penyedia DNS kedua di jaringan lain menghilangkan peringatan itu.

Timer SOA saya ditandai. Apakah perlu diubah?

Biasanya tidak. Refresh, retry, dan expire hanya berpengaruh pada server sekunder yang menyalin zona Anda lewat zone transfer; penyedia besar seperti Cloudflare dan Route 53 tidak memakainya untuk zona Anda, dan nilai default mereka sudah tepat. Expire di bawah satu minggu adalah satu-satunya yang disebut Zonemaster sebagai peringatan. Ubah nilainya hanya jika Anda menjalankan server primer dan sekunder sendiri.

Mengapa sebagian pengecekan ditandai “tidak diuji”?

Karena server kami tidak bisa menjalankannya, bukan karena ada yang salah. Server kami berjalan di jaringan Cloudflare, yang tidak bisa membuka koneksi ke alamat milik Cloudflare sendiri, dan hanya bertanya lewat TCP serta tidak menghubungi IPv6. Server-server itu dibaca lewat resolver Cloudflare 1.1.1.1 sebagai gantinya. Pengecekan yang tidak diuji tidak pernah menurunkan nilai; jika jumlahnya seperempat atau lebih, nilainya ditandai sebagian.

Mengapa nameserver saya melaporkan serial SOA yang berbeda?

Bisa jadi server sekunder belum mengikuti sebuah perubahan, atau domain Anda memakai dua penyedia DNS yang tidak saling melakukan zone transfer, sehingga masing-masing menyimpan serialnya sendiri. Kasus kedua itu wajar: server Route 53 milik github.com menyebut 1 dan server NS1-nya 1656468023. Zonemaster mencatat perbedaan apa pun sebagai peringatan; kami menjelaskan kasus mana yang terjadi.

Apakah ini alat cek DNSSEC, dan apakah tanpa DNSSEC nilainya turun?

Ya: alat ini mencocokkan DS di registri dengan kunci zona dan memverifikasi setiap tanda tangan, lalu bertanya ke Google Public DNS. Zona yang tidak ditandatangani mendapat satu peringatan Zonemaster (DS07_NOT_SIGNED), jadi nilainya paling tinggi A. Rantai yang rusak jauh lebih buruk daripada tidak ada sama sekali: resolver yang memvalidasi menolak domain itu, sebuah kesalahan yang menurunkan nilai ke C atau lebih rendah.

Seberapa sering saya perlu cek DNS domain?

Setelah setiap perubahan pada nameserver, DNSSEC, atau record email, serta sebelum dan sesudah pindah ke penyedia DNS atau registrar baru. Selebihnya, sebulan sekali sudah cukup untuk menangkap tanda tangan yang akan kedaluwarsa, nameserver yang berhenti menjawab, atau perubahan di registri yang tidak Anda lakukan. Setiap hasil punya tautan sendiri, jadi Anda bisa membandingkan hasil dari waktu ke waktu.

Apakah domain yang saya cek disimpan?

Tidak. Pengecekan berjalan di server kami di edge Cloudflare dan bertanya ke root, registri, nameserver Anda, Google Public DNS, dan resolver Cloudflare; tidak ada yang dicatat bersama alamat Anda. Hasil yang sudah selesai disimpan 10 menit agar pengecekan ulang atau tautan yang dibagikan langsung terjawab, lalu dihapus. Nameserver Anda menerima sekitar 20 pertanyaan dari server kami per pengecekan.

Ada yang kurang?Usulkan fitur atau alat baru

Alat terkait