# 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.

URL: https://www.matthewswong.com/id/learn/devops-from-zero/dns-records-explained/

DevOps dari nol · Pelajaran 17 dari 25 · Ditinjau pada 18 Oktober 2026 · Oleh Matthews Wong (https://www.matthewswong.com/id/about/)

> 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.

## 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.

1. **Kenali bagiannya.** 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. **Bertanya ke resolver.** 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. **Root memberi rujukan.** 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. **com merujuk ke zona.** 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 +short
   ```

   *Tebak:* Nama ini di-proxy Cloudflare. Apa jawaban server authoritative? (Alamat server origin / Dua alamat milik Cloudflare / CNAME yang menunjuk ke origin)
5. **Jawaban authoritative.** 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. **HTTPS sampai di proxy.** 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:* 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. **SSH ke nama yang di-proxy.** 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.

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.

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.

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.

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.

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.

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.

## Konfigurasi nyata di balik pelajaran ini

`next.config.ts:134-145`

```typescript
            // 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`

```typescript
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`

```yaml
# 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`

```yaml
      - 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

- **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

| Pertanyaan | Proxied (awan oranye) | DNS only (awan abu-abu) |
| --- | --- | --- |
| Yang dikembalikan dig | Alamat anycast Cloudflare | Alamat asli server Anda |
| Traffic yang dibawa | HTTP dan HTTPS di port yang didaftar Cloudflare | Tidak ada: klien langsung terhubung ke server Anda |
| Bisa mengubah response | Ya: caching, WAF, redirect, beacon yang disisipkan | Tidak, traffic tidak pernah lewat Cloudflare |
| TTL | Auto, 300 detik, tidak bisa diubah | Anda yang memilih, hingga 1 hari |
| Tipe record | Hanya A, AAAA, dan CNAME | Tipe apa pun; MX dan TXT selalu di sini |
| Cocok untuk | Website dan API HTTP | SSH, mail, dan layanan non-HTTP lain |

## Coba 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.

   ```bash
   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.

   ```bash
   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.

   ```bash
   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.

   ```bash
   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.

   ```bash
   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.

   ```bash
   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.

   ```bash
   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

1. **Kenapa example.com sendiri tidak bisa berupa CNAME?**
   A. CNAME hanya bekerja untuk nama dengan minimal tiga label
   B. Apex wajib memegang SOA dan NS, dan CNAME tidak boleh berbagi nama dengan data lain
   C. Browser menolak mengikuti CNAME di apex
   Jawaban: B. Apex memiliki SOA dan NS milik zona, dan RFC 1034 menyatakan tidak boleh ada data lain di samping CNAME. Flattening dan alias record menjawab dengan alamat sebagai gantinya.

2. **Anda mengubah A record dengan TTL 3600. Dua puluh menit kemudian rekan Anda masih mendapat alamat lama. Apa yang terjadi?**
   A. Resolver mereka menyimpan jawaban lama di cache dan boleh memakainya hingga satu jam
   B. Perubahannya belum sampai ke root server
   C. Server authoritative menolak record baru itu
   Jawaban: A. TTL adalah berapa lama resolver boleh menyimpan record di cache. Root server tidak pernah memegang record Anda; mereka hanya memberi rujukan. Tanyakan langsung ke name server zona untuk memastikan perubahannya sudah masuk.

3. **Step deploy melakukan SSH ke deploy.example.com, menggantung, lalu timeout. dig menunjukkan nama itu mengembalikan dua alamat Cloudflare. Apa perbaikannya?**
   A. Buka port 22 di firewall server
   B. Naikkan timeout SSH di workflow
   C. Arahkan deploy ke nama DNS only atau alamat server
   Jawaban: C. Nama itu di-proxy, jadi ssh sampai ke Cloudflare, yang secara default tidak membawa port 22. Server tidak pernah dihubungi, jadi firewall-nya dan timeout yang lebih panjang tidak mengubah apa pun.

## Pikirkan dulu

- **Saat resolver bertanya ke server com tentang www.matthewswong.com, apa yang kembali?** 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.
- **Kenapa awan oranye tidak bisa dinyalakan untuk MX record?** 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.
- **Apa itu propagasi DNS, dilihat dari TTL?** 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

- [Ekspos Layanan Self-Hosted dengan Aman via Cloudflare Tunnel](https://www.matthewswong.com/id/blog/cloudflare-tunnel-zero-trust-homelab/)
- [Cara Kerja CDN: Apa yang Perlu dan Jangan Di-cache di Edge](https://www.matthewswong.com/id/blog/how-cdn-works-edge-caching-explained/)
- [Desain High Availability: Redundancy, Failover dan Nines](https://www.matthewswong.com/id/blog/high-availability-redundancy-failover-design/)
- [Cara Setting Nginx Reverse Proxy untuk Docker di Cloudflare](https://www.matthewswong.com/id/blog/cara-setting-nginx-reverse-proxy-docker-cloudflare/)

## Sumber

- [RFC 1034: konsep dan fasilitas nama domain](https://www.rfc-editor.org/rfc/rfc1034)
- [RFC 1035: implementasi dan spesifikasi nama domain](https://www.rfc-editor.org/rfc/rfc1035)
- [RFC 1912: kesalahan operasional dan konfigurasi DNS yang umum](https://www.rfc-editor.org/rfc/rfc1912)
- [RFC 9499: terminologi DNS](https://www.rfc-editor.org/rfc/rfc9499)
- [RFC 3596: ekstensi DNS untuk IPv6 (AAAA)](https://www.rfc-editor.org/rfc/rfc3596)
- [RFC 8659: DNS Certification Authority Authorization (CAA)](https://www.rfc-editor.org/rfc/rfc8659)
- [RFC 7208: Sender Policy Framework (SPF di TXT record)](https://www.rfc-editor.org/rfc/rfc7208)
- [Dokumentasi Cloudflare: status proxy (proxied dan DNS only)](https://developers.cloudflare.com/dns/proxy-status/)
- [Dokumentasi Cloudflare: port jaringan yang didukung proxy](https://developers.cloudflare.com/fundamentals/reference/network-ports/)
- [Dokumentasi Cloudflare: mengatur CNAME flattening](https://developers.cloudflare.com/dns/cname-flattening/set-up-cname-flattening/)
- [Dokumentasi Cloudflare: time to live (TTL)](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)
- [Dokumentasi Cloudflare: FAQ Web Analytics (host beacon dan CSP)](https://developers.cloudflare.com/web-analytics/faq/)
- [Dokumentasi AWS: memilih antara alias record dan non-alias](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)
- [Manual BIND 9: dig](https://bind9.readthedocs.io/en/latest/manpages.html)

---

- HTML version: https://www.matthewswong.com/id/learn/devops-from-zero/dns-records-explained/
- English: https://www.matthewswong.com/en/learn/devops-from-zero/dns-records-explained/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json