Skip to main content
DevOps dari nol · Pelajaran 17 dari 25 · 13 menit

Jenis DNS Record dan Fungsinya: A, CNAME, MX, TXT, dan TTL

Jenis DNS record dan fungsinya: ikuti satu lookup dari resolver ke server authoritative, pahami A, CNAME, MX, TXT, NS, CAA, TTL, dan efek proxy Cloudflare.

Oleh Matthews WongDitinjau pada

Poin utama

DNS record adalah satu entri di zona sebuah domain yang menjawab satu pertanyaan tentang sebuah nama. A dan AAAA memberi alamatnya, CNAME menjadikannya alias nama lain, MX menyebut server mail-nya, TXT menyimpan teks seperti SPF, NS menyebut server authoritative-nya, dan CAA membatasi siapa yang boleh menerbitkan sertifikatnya. Setiap jawaban membawa TTL: berapa lama resolver boleh menyimpannya di cache.

Setelah pelajaran ini, Anda bisa

  • Menelusuri satu lookup dari stub resolver di laptop Anda, lewat recursive resolver, ke server root, TLD, dan authoritative, lalu mengulanginya dengan dig +trace.
  • Memilih tipe record yang tepat untuk tiap kebutuhan, dan menjelaskan kenapa CNAME tidak bisa dipasang di zone apex.
  • Membedakan nama yang di-proxy dari yang DNS only dengan dig, dan memperkirakan apa yang rusak ketika SSH atau CSP yang ketat bertemu proxy.
Lihat cara kerjanya

Ikuti diagramnya langkah demi langkah

Tekan Putar, atau melangkah dengan panah. Setiap langkah juga ditulis di bawah diagram.

Satu lookup DNS, lalu traffic yang diarahkan ke proxy

Stub resolver di laptop Anda bertanya ke recursive resolver, yang mengikuti rujukan dari root server dan server com sampai ke server authoritative milik zona. Jawaban yang di-proxy mengarahkan HTTPS ke Cloudflare, sedangkan SSH ke nama yang sama berakhir timeout.

Langkah 1 dari 7. Atas: server yang dikunjungi satu lookup nama. Bawah: ke mana traffic pergi setelah nama punya alamat. Namanya www.matthewswong.com, dan Cloudflare mem-proxy nama ini.

Tombol: ← → langkah · Home / End · K putar atau jeda

  1. Atas: server yang dikunjungi satu lookup nama. Bawah: ke mana traffic pergi setelah nama punya alamat. Namanya www.matthewswong.com, dan Cloudflare mem-proxy nama ini.

  2. Laptop Anda menjalankan stub resolver, yang tidak bisa menyelesaikan lookup sendiri. Ia mengirim pertanyaannya, A record untuk www.matthewswong.com, ke recursive resolver.

    dig @one.one.one.one www.matthewswong.com A

  3. Kalau cache masih kosong, resolver mulai dari root server. Root tidak tahu jawabannya. Ia mengembalikan rujukan (referral): daftar name server untuk com.

    dig +trace www.matthewswong.com

  4. Resolver bertanya ke server com, yang merujuknya ke NS record milik zona itu: dua name server Cloudflare, yang di-cache selama dua hari.

    dig matthewswong.com NS +shortTebak langkah berikutnya Nama ini di-proxy Cloudflare. Apa jawaban server authoritative? (Alamat server origin · Dua alamat milik Cloudflare · CNAME yang menunjuk ke origin)

  5. Server authoritative menjawab dengan dua A record milik Cloudflare, TTL 300. Nama yang di-proxy tidak pernah menampilkan alamat origin. Resolver menyimpan jawaban itu di cache selama 300 detik.

    dig @one.one.one.one www.matthewswong.com +noall +answer

  6. Browser terhubung ke alamat-alamat itu di port 443. Proxy menangani request, meneruskannya ke origin, dan bisa mengubah response: di sini ia menyisipkan beacon analytics.

    curl -sI https://www.matthewswong.com/en/Tebak langkah berikutnya Job deploy menjalankan ssh ke nama yang sama, yang di-proxy, di port 22. Apa yang terjadi? (Proxy meneruskannya ke origin · Proxy mengalihkannya ke port 443 · Tidak ada yang menjawab, dan koneksinya timeout)

  7. Secara default proxy hanya membawa port HTTP dan HTTPS. SSH di port 22 sampai ke alamat Cloudflare, tidak ada yang menjawab, dan deploy timeout. Pakai nama DNS only atau alamatnya langsung.

    curl --connect-timeout 5 telnet://www.matthewswong.com:22

Apa itu DNS record?

DNS mengubah nama menjadi data, dan DNS record, yang di RFC disebut resource record atau RR, adalah satu potong data itu. Setiap record punya nama pemilik, tipe, TTL, dan nilai: www.matthewswong.com, tipe A, TTL 300, dan sebuah alamat. Record untuk satu domain dikumpulkan dalam satu zona, dan name server authoritative milik zona itulah yang menjawab untuknya.

Baca selengkapnya (1)

dig menampilkan persis bagian-bagian itu. Dengan +noall +answer, dig hanya mencetak bagian answer, satu record per baris: nama, TTL, class, tipe, dan nilai. Tampilan itulah yang dipakai lesson ini, dan bagian coba sendiri menjalankannya ke nama situs ini.

Bagaimana lookup DNS berjalan, dari browser sampai server authoritative?

Laptop Anda tidak menelusuri pohon DNS sendiri. Ia menjalankan stub resolver, yang menurut RFC 9499 adalah resolver yang tidak bisa menyelesaikan seluruh resolusi sendiri, jadi seluruh pertanyaan diserahkan ke recursive resolver: yang tercantum di /etc/resolv.conf, atau resolver publik seperti milik Cloudflare, yang bisa dipanggil dengan nama one.one.one.one. Dalam mode rekursif, kata RFC 1034, server pertama mengejar jawaban atas nama klien ke server lain.

Baca selengkapnya (2)

Recursive resolver yang cache-nya kosong mulai dari root, yaitu zona yang apex-nya label kosong. Root server tidak tahu jawabannya; ia mengembalikan rujukan ke server untuk com, top-level domain satu lapis di bawah root. Server com mengembalikan rujukan berikutnya, yaitu NS record milik matthewswong.com. Baru setelah itu resolver sampai ke server yang menjawab secara authoritative.

dig +trace memutar ulang perjalanan itu. Manualnya menyebut opsi ini melacak jalur delegasi dari root name server dan menampilkan jawaban dari setiap server yang dipakai. Kalau Anda bertanya langsung ke server authoritative, balasannya membawa flag aa, yang menurut RFC 1035 berarti server penjawab adalah otoritas untuk nama yang ditanyakan. Setelah itu semuanya soal cache: resolver menyimpan jawaban selama TTL-nya dan melayani penanya berikutnya tanpa menelusuri pohon lagi.

Tipe DNS record mana yang penting, dan apa fungsi masing-masing?

A menyimpan alamat host, yaitu IPv4, dan AAAA menyimpan satu alamat IPv6. CNAME menjadikan sebuah nama sebagai alias: nilainya adalah nama kanonik, dan menurut RFC 1034 server menyertakan CNAME itu di response lalu mengulang query ke nama tersebut. Pakai A dan AAAA kalau Anda tahu alamatnya, dan CNAME kalau alamatnya dimiliki nama lain, misalnya platform hosting atau CDN.

Baca selengkapnya (2)

MX menyebut server mail untuk sebuah domain, masing-masing dengan angka preference, dan nilai yang lebih kecil lebih diutamakan. RFC 1912 mengulang aturan lama bahwa MX record tidak boleh menunjuk ke alias yang didefinisikan dengan CNAME. TXT menyimpan teks, dan sistem lain menaruh datanya sendiri di sana: SPF, misalnya, wajib dipublikasikan sebagai TXT record, dan nilainya diawali v=spf1.

NS mendaftar name server authoritative untuk sebuah zona. RFC 1034 menempatkan NS record di node teratas zona, dan di titik potong tempat zona induk mendelegasikan ke zona anak, persis rujukan yang diberikan server com. CAA menyebut certificate authority yang boleh menerbitkan sertifikat untuk domain itu, dan RFC 8659 menyatakan CA yang patuh wajib memeriksanya sebelum menerbitkan.

Kenapa CNAME tidak bisa dipasang di zone apex?

Apex adalah puncak sebuah zona, domain polos seperti example.com. RFC 9499 mendefinisikannya sebagai pemilik SOA record dan NS record authoritative milik zona, jadi apex selalu membawa record-record itu. RFC 1034 menyatakan bahwa kalau ada CNAME di sebuah node, tidak boleh ada data lain, dan RFC 1912 lebih tegas lagi: CNAME tidak boleh berdampingan dengan data apa pun. CNAME di apex harus berdampingan dengan SOA dan NS, dan itu dilarang aturan tadi.

Baca selengkapnya (2)

Penyedia DNS mengakalinya dengan me-resolve alias itu sendiri. CNAME flattening di Cloudflare mengembalikan alamat IP akhir, bukan CNAME, dan otomatis aktif kalau apex memakai CNAME. Amazon Route 53 punya alias record, yang tidak seperti CNAME bisa dibuat di zone apex, dan dig menampilkannya sebagai A atau AAAA biasa. Bagaimanapun caranya, resolver hanya pernah melihat record alamat.

Itulah salah satu alasan praktis banyak situs berjalan di www. Subdomain bisa menjadi CNAME biasa ke platform atau CDN di penyedia DNS mana pun, sedangkan apex butuh fitur khusus penyedia. Setiap URL kanonik di situs ini dibangun di atas www, dari satu konstanta di lib/seo.ts.

Apa itu TTL, dan apa sebenarnya propagasi DNS?

TTL adalah batas waktu, dalam detik, berapa lama sebuah record boleh disimpan di cache. Resolver yang mengambil www.matthewswong.com dengan TTL 300 boleh menjawab dari cache hingga lima menit, dan dua kali menjalankan dig berselang beberapa detik memperlihatkan sisa TTL yang terus berkurang. Di Cloudflare, setiap record yang di-proxy memakai TTL Auto, yaitu 300 detik, dan tidak bisa diubah.

Baca selengkapnya (2)

Jadi propagasi DNS bukanlah perubahan yang merambat ke seluruh internet. Begitu server authoritative memegang record baru, setiap resolver tetap menyajikan salinan cache-nya sampai TTL salinan itu habis, sehingga perubahan muncul resolver demi resolver. Dokumentasi Cloudflare menyebutnya terang-terangan: TTL yang lebih panjang berarti perubahan butuh waktu lebih lama untuk berlaku. Sebelum perubahan yang terencana, turunkan TTL dan tunggu TTL lama habis, supaya cache berumur pendek saat Anda berpindah.

Mengganti name server lebih lambat lagi, karena delegasinya ada di zona induk. Dalam dig +trace untuk situs ini, server com memberikan NS record domain ini dengan TTL 172800 detik, alias dua hari.

Apa yang diubah proxy Cloudflare, si awan oranye?

Record yang disetel Proxied dijawab dengan alamat IP anycast Cloudflare, bukan alamat server Anda, dan traffic HTTP serta HTTPS-nya lewat jaringan Cloudflare, tempat aturan caching, WAF, dan redirect berlaku. Kalau disetel DNS only, Cloudflare menjawab dengan alamat asli server Anda, yang menurut Cloudflare membuka alamat IP origin ke siapa pun yang menanyakan record itu. Hanya A, AAAA, dan CNAME yang bisa di-proxy; MX dan TXT selalu DNS only.

Baca selengkapnya (1)

Proxy adalah server kedua di jalur itu, dan dua akibatnya terlihat di repository ini. Secara default proxy hanya membawa port HTTP dan HTTPS yang didaftar Cloudflare, termasuk 80 dan 443, jadi SSH di port 22 ke nama yang di-proxy tidak sampai ke mana-mana. Proxy juga bisa mengubah response: dengan setup otomatis Web Analytics, Cloudflare menyisipkan beacon JavaScript ke halaman, yang harus diizinkan oleh Content-Security-Policy situs ini.

Cara situs ini melakukannya

Konfigurasi nyata di balik pelajaran ini

Kutipan dari repositori yang membangun dan men-deploy situs ini, apa adanya.

next.config.ts:134-145
            // The cloudflareinsights hosts are the Web Analytics beacon the
            // Cloudflare proxy injects into every page since www went behind
            // it; without them the beacon is blocked and logs a CSP error on
            // every page view.
            key: "Content-Security-Policy",
            value: [
              "default-src 'self'",
              "script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google-analytics.com https://static.cloudflareinsights.com",
              "style-src 'self' 'unsafe-inline' https://fonts.googleapis.com",
              "img-src 'self' data: blob: https: http:",
              "font-src 'self' https://fonts.gstatic.com",
              "connect-src 'self' https://www.google-analytics.com https://api.groq.com https://cloudflareinsights.com",

Bukti bahwa proxy bukan pipa pasif. Begitu www di-proxy, Cloudflare mulai menyisipkan script yang tidak pernah ditulis aplikasi, dan CSP milik aplikasi memblokirnya. script-src sekarang mengizinkan static.cloudflareinsights.com, tempat beacon dimuat. FAQ Cloudflare menyebut setup otomatis melapor ke /cdn-cgi/rum di domain situs sendiri, yang sudah tercakup 'self'; cloudflareinsights.com adalah endpoint untuk pemasangan manual.

lib/seo.ts:5
export const BASE_URL = "https://www.matthewswong.com";

Satu konstanta menentukan nama host situs: buildCanonical dan toAbsoluteUrl membangun setiap URL kanonik dan alamat sitemap di atasnya, jadi situs ini hidup di www. Subdomain seperti www bisa menjadi CNAME biasa di penyedia mana pun; apex tidak bisa, dan itu salah satu alasan menaruh situs di sana.

.github/workflows/deploy.yml:3-6
# Build a Docker image, push it to GHCR, then deploy it to the VPS over SSH.
# All app configuration is read from GitHub at run time:
#   Secrets  → GROQ_API_KEY, RESEND_API_KEY, VPS_SSH_HOST, VPS_SSH_USER, VPS_SSH_KEY
#   Variables→ CONTACT_FROM_EMAIL, CONTACT_TO_EMAIL, APP_PORT, DEPLOY_PATH, VPS_SSH_PORT

Target deploy adalah sebuah secret, VPS_SSH_HOST, bukan nama yang ditulis di workflow. Karena itu mudah keliru setelah perubahan DNS: kalau secret itu berisi nama yang sekarang di-proxy, deploy terhubung ke Cloudflare, bukan ke server. Isinya harus nama DNS only atau alamat server itu sendiri.

.github/workflows/deploy.yml:213-219
      - name: Deploy over SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.VPS_SSH_HOST }}
          username: ${{ secrets.VPS_SSH_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          port: ${{ vars.VPS_SSH_PORT || 22 }}

Tempat secret itu dipakai. Port-nya jatuh ke 22, yang tidak ada di daftar port yang di-proxy Cloudflare, jadi host yang di-proxy di sini tidak pernah sampai ke sshd. Step ini tidak langsung gagal dengan penolakan: koneksinya menunggu lalu timeout, sehingga terlihat seperti server mati, bukan salah DNS.

Yang sering rusak

Kesalahan yang benar-benar membuang waktu

  • Deploy lewat SSH timeout karena host-nya nama yang di-proxy

    Secara default Cloudflare hanya mem-proxy port HTTP dan HTTPS yang ada di daftarnya, dan 22 tidak termasuk. Nama yang di-proxy mengarah ke alamat Cloudflare, jadi ssh terhubung ke sana, tidak ada yang menjawab, dan step menggantung sampai timeout. Perbaiki di tempat host itu dikonfigurasi, di sini secret VPS_SSH_HOST: pakai nama DNS only atau alamat server. Saran Cloudflare sendiri untuk server SSH pun sama: jadikan nama itu DNS only.

  • Proxy tidak menyembunyikan apa pun kalau record lain menunjuk server yang sama

    Record yang di-proxy hanya menjauhkan alamat origin dari jawaban record itu. Record DNS only mana pun yang menunjuk mesin yang sama, misalnya subdomain admin atau host mail, mempublikasikan alamat itu ke siapa pun yang menanyakannya, seperti diperingatkan Cloudflare. Periksa semua record di zona, bukan hanya yang Anda proxy.

  • CNAME berdampingan dengan record lain, atau di apex

    CNAME tidak boleh berbagi nama dengan record lain, jadi Anda tidak bisa menambah MX atau TXT ke nama yang berupa CNAME, dan apex sama sekali tidak boleh berupa CNAME. RFC 1912 menambahkan bahwa server seperti BIND melihat CNAME itu dan menolak data lain untuk nama tersebut, sehingga NS di sebelahnya diabaikan. Arahkan MX ke nama yang punya A atau AAAA, jangan ke alias, dan pakai flattening atau alias record di apex.

  • Record sudah diubah, tetapi jawaban lama masih muncul

    Resolver Anda menyimpan jawaban lama di cache dan boleh memakainya sampai sisa TTL-nya habis. Tanyakan langsung ke salah satu name server zona dengan dig: kalau sudah menampilkan nilai baru, perubahannya selesai dan tinggal cache yang tertinggal. Resolver publik Cloudflare juga punya halaman Purge Cache di one.one.one.one/purge-cache untuk satu nama.

  • CSP yang ketat memblokir sisipan dari proxy

    Begitu proxy diaktifkan untuk situs yang memakai Content-Security-Policy, beacon Web Analytics yang disisipkan Cloudflare terblokir, dengan error CSP di setiap kunjungan halaman. Izinkan host beacon itu, seperti yang dilakukan next.config.ts situs ini, atau ubah pengaturan Web Analytics. Cloudflare juga mencatat bahwa Cache-Control public, no-transform mencegahnya mengubah halaman, jadi beacon tidak disisipkan sama sekali.

Proxied atau DNS only: efek tiap pilihan pada record Cloudflare
Yang dikembalikan digAlamat anycast CloudflareAlamat asli server Anda
Traffic yang dibawaHTTP dan HTTPS di port yang didaftar CloudflareTidak ada: klien langsung terhubung ke server Anda
Bisa mengubah responseYa: caching, WAF, redirect, beacon yang disisipkanTidak, traffic tidak pernah lewat Cloudflare
TTLAuto, 300 detik, tidak bisa diubahAnda yang memilih, hingga 1 hari
Tipe recordHanya A, AAAA, dan CNAMETipe apa pun; MX dan TXT selalu di sini
Cocok untukWebsite dan API HTTPSSH, mail, dan layanan non-HTTP lain
Coba sendiri

Lakukan di komputer Anda sendiri

Anda butuh terminal dengan dig dan curl; macOS sudah menyertakan keduanya, dan di Linux dig ikut paket BIND tools distribusi Anda. Semua langkah di sini hanya membaca jawaban publik, jadi aman dijalankan ke situs ini. Bandingkan hasilnya dengan deskripsi, bukan dengan angka persis, karena angkanya bisa berubah.

  1. Tanyakan A record ke resolver publik Cloudflare. Anda mendapat dua alamat milik Cloudflare, masing-masing dengan TTL 300 atau sedikit di bawahnya.

    dig @one.one.one.one www.matthewswong.com +noall +answer

  2. Jalankan lagi beberapa detik kemudian. TTL biasanya berkurang kira-kira sebanyak detik yang Anda tunggu: itulah salinan cache resolver yang sedang menghitung mundur.

    dig @one.one.one.one www.matthewswong.com +noall +answer

  3. Tanyakan tipe lain. AAAA mengembalikan dua alamat IPv6, juga milik Cloudflare. NS mengembalikan dua name server Cloudflare milik zona. MX mengembalikan tiga server mail, masing-masing dengan angka preference di depannya.

    dig @one.one.one.one www.matthewswong.com AAAA +short
dig @one.one.one.one matthewswong.com NS +short
dig @one.one.one.one matthewswong.com MX +short

  4. Telusuri delegasinya sendiri: root server, lalu server com, lalu name server zona, lalu jawabannya. Di jaringan tempat lesson ini diuji, trace biasa berputar-putar; menambahkan +tcp membuatnya berhasil.

    dig +trace www.matthewswong.com
dig +trace +tcp www.matthewswong.com

  5. Tanyakan langsung ke salah satu name server zona. Cari aa di baris flags: jawaban authoritative, dengan TTL penuh 300. Kalau aa tidak muncul, tambahkan +tcp; di jaringan uji, hanya query TCP yang kembali dengan aa.

    dig @$(dig +short matthewswong.com NS | head -1) www.matthewswong.com
dig +tcp @$(dig +short matthewswong.com NS | head -1) www.matthewswong.com

  6. Sekarang lihat proxy-nya. Header server berisi cloudflare, dan saat Anda meminta HTML seperti browser, halaman itu berisi script beacon yang tidak pernah ditulis aplikasinya.

    curl -sI https://www.matthewswong.com/en/ | grep -i '^server'
curl -s -H 'Accept: text/html' https://www.matthewswong.com/en/ | grep -o 'static.cloudflareinsights.com/beacon.min.js'

  7. Terakhir, coba port SSH. HTTPS langsung tersambung, tetapi port 22 di nama yang sama menunggu lalu gagal karena timeout, sebab proxy tidak membawanya.

    curl -sS --connect-timeout 5 -o /dev/null https://www.matthewswong.com/en/ && echo 443 ok
curl -sS --connect-timeout 5 telnet://www.matthewswong.com:22
Kuis singkat

Tiga pertanyaan sebelum lanjut

Pilih jawaban untuk melihat kenapa benar atau salah. Tidak ada nilai, jadi tebak saja dengan bebas; jawaban yang salah disimpan di browser ini agar kursus bisa menanyakannya lagi nanti.

  1. 1.Kenapa example.com sendiri tidak bisa berupa CNAME?
  2. 2.Anda mengubah A record dengan TTL 3600. Dua puluh menit kemudian rekan Anda masih mendapat alamat lama. Apa yang terjadi?
  3. 3.Step deploy melakukan SSH ke deploy.example.com, menggantung, lalu timeout. dig menunjukkan nama itu mengembalikan dua alamat Cloudflare. Apa perbaikannya?
Dari pelajaran sebelumnya

Dua pertanyaan dari pelajaran sebelumnya

Mengingat kembali pelajaran lama setelah jeda membuatnya lebih melekat. Jawab dari ingatan sebelum mencari apa pun.

  1. 1.Sebuah VPS menjalankan ufw yang hanya mengizinkan 22, 80, dan 443. Sebuah container di-publish dengan -p 8080:80. Apakah internet bisa menjangkau port 8080?
  2. 2.Repo punya script npm test dan job verify workflow deploy hanya menjalankan npm ci, typecheck, dan lint. Sebuah test mulai gagal. Apa yang terjadi pada push berikutnya ke main?

Dari: 16. Jaringan Docker untuk Pemula: Bridge, DNS, Port, dan ufw · 14. Quality Gate GitHub Actions: Periksa Sebelum Deploy

Pikirkan dulu

Jawab dalam hati, lalu cek

  1. 1.Saat resolver bertanya ke server com tentang www.matthewswong.com, apa yang kembali?Lihat jawabannya

    Jawaban:Sebuah rujukan, bukan alamat: NS record milik matthewswong.com, yang menyebut dua name server Cloudflare. Resolver lalu bertanya ke salah satunya, dan server itulah yang menjawab secara authoritative.

  2. 2.Kenapa awan oranye tidak bisa dinyalakan untuk MX record?Lihat jawabannya

    Jawaban:Cloudflare hanya mem-proxy record yang dipakai untuk resolusi alamat: A, AAAA, dan CNAME. MX dan TXT selalu DNS only, dan mail memang bukan traffic di port HTTP dan HTTPS yang dibawa proxy.

  3. 3.Apa itu propagasi DNS, dilihat dari TTL?Lihat jawabannya

    Jawaban:Cache yang kedaluwarsa. Begitu server authoritative memegang record baru, setiap resolver menyimpan salinan cache-nya sampai TTL salinan itu habis, jadi perubahan muncul resolver demi resolver dalam satu TTL lama.

Pelajari lebih dalam

Bahasan mendalam terkait di situs ini

Sumber

Sumber primer yang diperiksa pada tanggal riset. Ikuti tautannya untuk versi terbaru.

Pelajaran sebelumnyaJaringan Docker untuk Pemula: Bridge, DNS, Port, dan ufwPelajaran berikutnyaApa Itu SMTP: Cara Kerja Email, SPF, DKIM, dan DMARC