The Own Lab The Own Lab

Cloudflare DNS

DNS 運作原理、常用 Record 類型,以及 Cloudflare Proxy 模式的實務設定

Overview##

DNS(Domain Name System)是網際網路的電話簿——把人類看得懂的域名翻譯成機器需要的 IP 位址。當你在瀏覽器輸入 example.com,背後經過一連串查詢才找到對應的伺服器。

查詢流程:

graph LR
  A[瀏覽器快取] --> B[OS 快取]
  B --> C[Router 快取]
  C --> D[ISP DNS]
  D --> E[Root DNS]
  E --> F[TLD DNS]
  F --> G[權威 DNS]
  G --> H[回傳 IP]

每一層都是快取——如果在前面的層就找到了,就不需要往後查。這也是為什麼 DNS 更新不會立即生效,需要等 TTL(Time To Live)過期。

Note

Cloudflare 提供的是權威 DNS 服務——當你把域名的 NS(Name Server)指向 Cloudflare,它就成為你域名的權威 DNS。

Record Types##

DNS Record 是電話簿裡的每一筆紀錄。不同的 record type 回答不同的問題:

A / AAAA###

最基本的紀錄——域名對應到 IP 位址:

# A Record(IPv4)
example.com.    IN  A     93.184.216.34

# AAAA Record(IPv6)
example.com.    IN  AAAA  2606:2800:0220:0001::
類型對應使用場景
AIPv4 位址最常用,指向伺服器
AAAAIPv6 位址IPv6 環境

CNAME###

域名指向另一個域名(別名):

# CNAME Record
www.example.com.    IN  CNAME  example.com.
app.example.com.    IN  CNAME  my-app.pages.dev.
blog.example.com.   IN  CNAME  my-blog.vercel.app.

Warning

CNAME 不能設在根域名(example.com)上——這是 DNS 規範的限制。Cloudflare 透過 CNAME Flattening 繞過這個限制,在根域名上也能使用 CNAME,但實際回傳的是解析後的 IP。

MX###

指定郵件伺服器,處理 @example.com 的 email 收發:

# MX Record(數字是優先級,越小越優先)
example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  20  mail2.example.com.

常見的設定是指向 Google Workspace 或 Microsoft 365 的郵件伺服器。

TXT###

儲存任意文字資訊,最常用於驗證和安全

# SPF — 指定哪些伺服器可以寄送你域名的 email
example.com.    IN  TXT  "v=spf1 include:_spf.google.com ~all"

# DKIM — email 數位簽章
google._domainkey.example.com.    IN  TXT  "v=DKIM1; k=rsa; p=..."

# 域名驗證 — 證明你擁有這個域名
example.com.    IN  TXT  "google-site-verification=abc123..."
TXT 用途說明
SPF防止 email 被偽造(指定合法發信伺服器)
DKIMemail 內容的數位簽章驗證
DMARCSPF + DKIM 的政策定義
域名驗證向第三方證明域名所有權

NS###

指定域名的權威 DNS 伺服器:

# NS Record — 告訴網際網路去哪裡查這個域名的紀錄
example.com.    IN  NS  ns1.cloudflare.com.
example.com.    IN  NS  ns2.cloudflare.com.

Tip

把 NS 指向 Cloudflare 是使用 Cloudflare DNS 的第一步——在你的域名註冊商處修改 NS 紀錄即可。

Proxy Mode##

Cloudflare DNS 的獨特功能——每筆 A / AAAA / CNAME 紀錄都可以選擇開啟 Proxy:

模式圖示DNS 回傳效果
Proxy 開啟橘色雲朵 ☁️Cloudflare 的 IPCDN + DDoS 防護 + SSL + 快取
DNS Only灰色雲朵你的真實 IP純 DNS 解析

Proxy 開啟時###

用戶 → Cloudflare Edge(CDN、WAF、SSL)→ 你的伺服器

Cloudflare 做了以下事情:

  • 隱藏真實 IP — 攻擊者無法直接連到你的伺服器
  • 自動 SSL — 免費的 HTTPS 憑證
  • CDN 快取 — 靜態資源在全球節點快取
  • DDoS 防護 — 過濾惡意流量
  • 自動管理 TTL — 你無法自訂 TTL

DNS Only 時###

用戶 → 直接連線 → 你的伺服器

需要自己處理 SSL、快取、防護。適用場景:

  • MX 紀錄(郵件不能走 Proxy)
  • 需要精確控制 TTL
  • 後端使用自己的 reverse proxy(Nginx / Traefik)

DNS vs Reverse Proxy##

這是常見的混淆點——DNS 和 Reverse Proxy 工作在不同的層級:

用戶輸入 app.example.com


┌─ DNS ──────────────────────────────┐
│  "app.example.com 在哪?"          │
│  回答:IP 位址                     │  ← 電話簿:查號碼
└────────────────────────────────────┘


┌─ Reverse Proxy(Nginx / Traefik)──┐
│  請求到達後,轉發到哪個服務?       │
│  /api  → port 3000                │  ← 總機:轉分機
│  /app  → port 8080                │
└────────────────────────────────────┘


     你的應用程式
面向DNSReverse Proxy
解決的問題域名 → IP(找到機器)請求 → 服務(找到程式)
工作層級網路層(連線之前)應用層(連線之後)
類比電話簿查號碼公司總機轉分機
工具Cloudflare, Route 53Nginx, Traefik, Caddy

Tip

Cloudflare Proxy 模式同時扮演了 DNS 和 Reverse Proxy 的角色——這是它跟純 DNS 服務的最大差異。

Quiz##

Single Choice

當你把域名的 NS 紀錄指向 Cloudflare,Cloudflare 扮演什麼角色?

Single Choice

為什麼 CNAME 不能設在根域名(example.com)上?

Single Choice

開啟 Cloudflare Proxy(橘色雲朵)後,DNS 查詢會回傳什麼?

Single Choice

以下哪個場景不適合開啟 Cloudflare Proxy?

Single Choice

SPF、DKIM、DMARC 這三個 TXT 紀錄的共同目的是什麼?

Summary##

  • DNS 是網際網路的電話簿——域名到 IP 的翻譯系統
  • 常用 Record:A(IPv4)、AAAA(IPv6)、CNAME(別名)、MX(郵件)、TXT(驗證)、NS(權威 DNS)
  • Cloudflare Proxy 同時提供 DNS + Reverse Proxy(CDN、SSL、DDoS 防護)
  • Proxy 模式隱藏真實 IP 並自動管理 TTL;DNS Only 適用於郵件和需要自訂 TTL 的場景
  • DNS 解決「找到機器」,Reverse Proxy 解決「找到程式」——層級不同

留言 (0)

登入後即可留言