多數人聽到 DNS設定，第一個想到的是手機或電腦網路設定裡那串 8.8.8.8。但網站換主機、信箱換服務時要動的 DNS，其實是另一份東西，一份放在網域那一側、記錄著「這個名稱要指到哪裡」的紀錄清單。
兩件事共用同一個縮寫，位置卻完全不同。裝置上的設定改了，網站不會因此換到新主機；在註冊商後台加了紀錄，如果網域早已交給別處管理，也沒有任何一台伺服器會讀到它。「明明填了，網站卻沒變」是很常見的求助說法，原因多半就在這裡。
而紀錄存在哪裡、由誰負責回答，正是動手改任何一筆紀錄之前最該先弄清楚的事。
DNS設定改的是網域紀錄，不是電腦上的 DNS 伺服器
「DNS設定」這個詞同時指兩件事。第一件在裝置上，電腦、手機或分享器的網路設定裡可以填入 DNS 伺服器的位址（例如公共 DNS 常見的 8.8.8.8），決定這台裝置遇到網址時要向誰詢問。第二件在網域上，替自己的網域設定紀錄，讓網站連到主機、讓信箱收得到信。網站換主機、信箱換服務時要動的是第二件，裝置上的設定不必碰。
網域這一側，管理者編輯的是一份存在名稱伺服器上的紀錄清單。每一筆紀錄都在回答同一個問題，也就是某個名稱的某種類型，答案是什麼。以龐果設計的官網為例，example.com 的 A 紀錄是 192.0.2.10，代表訪客問「example.com 在哪台主機」時，得到的是這個位址；example.com 的 MX 紀錄指向某台郵件伺服器，代表寄信的人問「這個網域的信要送去哪」時，得到的是那個主機名稱。
存放紀錄的一方和替使用者查詢的一方，是兩個不同的角色。RFC 1034 把 DNS 拆成三個主要元件：網域名稱空間與資源紀錄（也就是資料本身）、名稱伺服器（保存網域樹的結構與資料，對自己負責的那一段握有完整資訊，稱為該段的 authority），以及解析器（代使用者向名稱伺服器取資料的程式）。Cloudflare 的說明文件也這樣描述名稱伺服器的工作，它替自己負責的網域回答查詢，保存該網域的權威紀錄，並在解析過程中給出最終的答案。換句話說，名稱伺服器是握有答案的一方，解析器只是替使用者跑腿去問的一方。
裝置上填的 DNS 位址，指定的是跑腿的解析器，不是存放答案的名稱伺服器，兩邊各改各的，互不影響。Google Workspace 的說明文件提到，使用 Google 服務時，要依各服務的要求修改網域的 DNS 紀錄，例如改 MX 紀錄，把網域的信件導向 Google 的郵件伺服器，指的就是網域這一側的修改。
解析器遇到不認識的名稱時，會從根開始往下問，經過頂級網域（TLD）的名稱伺服器，一路問到負責該網域的那一組。逐層查詢的細節屬於基本概念，對設定紀錄來說，最後負責回答的，永遠是網域目前登記的那一組名稱伺服器。
DNS 代管的位置由網域目前指向的名稱伺服器決定
「後台明明加了紀錄，為什麼沒用」，最常見的原因是網域在哪裡買，和 DNS 紀錄在哪裡管，其實是兩個不同的地方。
根據 ICANN 的說明，網域是向 ICANN 認證的註冊商（或其經銷商）註冊的；註冊商負責辦理註冊，registry 則負責維護各 TLD 的註冊資料，並提供名稱伺服器來發布 zone 資料。費用、轉移、續約這些條款，由你與註冊商之間的合約規範。「買網域的地方」與「管 DNS 的地方」本來就是兩個角色，只是經常由同一家提供，才讓人以為是同一件事。
真正算數的，是網域目前登記的名稱伺服器（NS）。NS 指向哪裡，世界各地的查詢就會被送到哪裡，其他地方加的紀錄不會被採用。舉個典型情境，龐果設計在註冊商後台新增了 example.com 的 A 紀錄，卻忘了網域的 NS 早已改指到 Cloudflare。於是查詢全被送到 Cloudflare，註冊商那份清單沒有人來讀，新增的紀錄自然沒有任何效果。
註冊商、主機商與 Cloudflare 三種常見的代管形式
紀錄可能放在三種地方，沒有哪一種天生比較好，差別只在紀錄要到哪裡改。表中 NS 的值用 RFC 2606 保留的示範網域代替，實際值由各平台指定，不能照抄。
| 代管形式 | 什麼情況下是這種形式 | NS 的樣子（示範值） | 紀錄要到哪裡改 | 更換時要留意 |
|---|---|---|---|---|
| 註冊商提供的 DNS | 網域註冊後沒改過 NS | ns1.example.com | 註冊商的 DNS 管理介面 | 換註冊商時，先確認紀錄一併帶走 |
| 主機商提供的 DNS | NS 改成主機商給的那一組 | ns1.example.net | 主機商後台 | 換主機時，先確認紀錄一併帶走 |
| 第三方 DNS 代管（如 Cloudflare） | NS 改成該平台給的那一組 | ns1.example.org | 該平台的 DNS 頁面 | 換 NS 前先抄齊紀錄並處理 DNSSEC |
DNS 放在主機商的人要特別注意，那份紀錄清單不會自動跟著網域走，換主機之前得先確認所有紀錄都已經抄出來，否則換完 NS 就等於把原本的紀錄丟掉。
Cloudflare 把這件事分成不同的設定方式。Primary（Full）setup 是把 Cloudflare 當成主要的 DNS 提供者，紀錄全部在 Cloudflare 管理；CNAME（partial）setup 則是保留原本的 DNS 提供者，只讓個別子網域走 Cloudflare 的代理，這種方式要 Business 以上的方案才有，Free 與 Pro 方案只有 Full setup。另外，向 Cloudflare Registrar 註冊的網域，會自動使用 Cloudflare 的權威 DNS，這正是「註冊商與 DNS 代管可以是同一家」的一個實例。
先查 NS 紀錄，確認該登入的後台
不確定自己現在是哪一種形式，用一行指令就能查出來：
nslookup -type=NS example.com
dig example.com NS +shortCode language: plaintext (plaintext)兩條指令擇一即可，example.com 換成自己的網域。看到的名稱伺服器屬於誰，就到誰的後台改紀錄。
如果連註冊商是誰都不確定，可以用 ICANN Lookup 查詢。NS 查到的是「DNS 在哪」，ICANN Lookup 查到的是「網域向誰註冊」，兩者可能是不同的對象，登入哪個後台改紀錄，以 NS 的結果為準。
更換名稱伺服器前，先抄齊既有紀錄並關閉 DNSSEC
把 DNS 從註冊商搬到 Cloudflare 這類第三方代管時，最常造成網站或信箱斷線的，是搬過去的紀錄不完整，或是 DNSSEC 沒先處理。以下用 Cloudflare 的流程當示範，其他代管業者的介面名詞不同，背後的邏輯是一樣的。
Cloudflare 的設定流程依序是：
- 在新的代管處新增網域，建好全部紀錄（可以選自動掃描，或手動新增）。
- 到註冊商關閉 DNSSEC。
- 移除舊的名稱伺服器，填入新代管給的那一組，名稱必須逐字相同。
- 等待生效。
- 確認網域狀態變成 Active。
順序不能顛倒，每一步都有原因。自動掃描匯入的紀錄，Cloudflare 明確表示不保證找到所有既有的 DNS 紀錄，所以掃完一定要人工核對：根網域的網站紀錄（A、AAAA 或 CNAME，內容取決於網站所在的主機商）、www 與其他子網域，以及 Email 相關的紀錄（MX、SPF、DKIM、DMARC）。Cloudflare 的範例中，Email 紀錄包含 mail 的 A 紀錄、MX、_dmarc 的 TXT、*._domainkey 的 TXT 與 SPF 的 TXT，實際的值則依郵件服務商而定。其中漏抄 MX，信箱就會直接斷線。
還有一點容易疏忽。NS 一換，舊 DNS 後台裡的紀錄就不再被採用，所以「舊後台還留著那些紀錄」不代表安全。至於 DNSSEC，Cloudflare 的原話是，在 DNSSEC 啟用的狀態下更換名稱伺服器，網域可能變得無法連上，因此要先在註冊商關閉；等網域狀態變成 Active 之後，再回 Cloudflare 重新開啟。名稱伺服器要逐字複製，則是因為少一個字元，網域就無法正確解析。
等待時間要如實看待，因為 Cloudflare 的文件給了兩個不同的說法。設定頁寫的是最多等 24 小時，等註冊商更新名稱伺服器，完成時會收到 Cloudflare 的通知信；另一份 DNS 最佳實務的學習路徑則寫，名稱伺服器變更的傳遞通常從幾分鐘到 48 小時不等。兩個數字不必硬合併成一個，以自己網域狀態是否變成 Active 為準。確認時可以用 dig example.com NS @8.8.8.8 與 dig example.com NS @1.1.1.1 檢查兩個公共解析器是否一致回報新的名稱伺服器，生效之後再測 A 與 MX 這些關鍵紀錄。
每筆紀錄都由主機名稱、類型、值與 TTL 組成
不同後台把欄位叫成不同的名字，是新手最容易填錯格的原因。一筆紀錄的結構其實很固定：名稱（這筆紀錄屬於誰）、類型（問的是哪一種資料）、值（答案）與 TTL（這個答案可以被快取多久）。MX、SRV 這兩種類型則多了優先順序之類的欄位。
| 概念 | 在管什麼 | 後台常見的叫法 |
|---|---|---|
| 名稱 | 這筆紀錄屬於哪個名稱 | Name、Host、主機、別名 |
| 類型 | 問的是哪一種資料 | Type、類型 |
| 值 | 查詢得到的答案 | Value、Content、Target、Answer、目的位置 |
| TTL | 答案可以被快取多久 | TTL |
Microsoft Learn 就提醒過，Target 欄位在不同註冊商可能叫 Content、IP Address、Target Host 或 Value。名稱不同，位置和作用都一樣，照上表對應就不會填錯格。
Cloudflare 的文件還補充了幾條名稱的限制。Name 可以是子網域，也可以是 zone apex（用 @ 表示）；每一段標籤（label）不超過 63 個字元，完整的網域名稱不超過 253 個字元；建議只用字母、數字與連字號（LDH）。底線在 DNS 裡是合法的，常用在服務類的紀錄，像 Email 驗證會用到的 _dmarc 與 _domainkey。
@、www 與子網域的主機名稱寫法
名稱欄填的是「相對名稱」，不是完整的網域：
@代表網域本身，也就是根網域 example.com。www代表 www.example.com。blog代表 blog.example.com。
RFC 1035 對這點有明確規定，不以句點結尾的名稱是相對名稱，會與 origin 串接；以句點結尾才是絕對名稱。後台自動補上網域，就是這個機制在運作。
有些後台要求「留空」而不是填 @。Google Workspace 的 MX 說明寫的是名稱欄「留空或輸入 @」，要替子網域設定時，則填子網域的值，例如 support；Microsoft 在 SRV 的說明裡也提到，如果後台不接受 @，就把欄位留空。Google 談 TXT 紀錄時也是同樣的規則，主機是網域本身而不是子網域時，指定 @。遇到後台的寫法不同，以後台的欄位提示為準。
值欄位的格式與結尾句點
值欄位依類型填不同的東西：A 與 AAAA 填 IP，CNAME、MX、NS 填主機名稱，TXT 則填整段文字。
同樣的值，各家後台要求的格式並不一致。Google 的 MX 設定說明提到，有些註冊商要求在結尾加半形句點（smtp.google.com.），有些則把優先順序和目的位置放在同一行（1 smtp.google.com）。Microsoft Learn 也有類似的提醒，有些註冊商要求 Target 欄以句點結尾，要向註冊商確認。結尾句點要不要加，沒有通用答案，照服務商給的值填，格式不對再依後台的說明調整。
TTL 與優先順序兩個數字欄位
TTL 的單位是秒，3600 是 1 小時，86400 是 24 小時。TTL 越長，查詢越容易命中快取，網站解析也就越快，但紀錄更新後要等越久才會全面生效。Cloudflare 的 Auto 是 300 秒；走代理（Proxied）的紀錄，TTL 固定為 Auto，無法編輯，DNS only 的紀錄則可以設定 60 秒（非 Enterprise 方案）到 1 天。TTL 該設多少，取決於紀錄多常變動。
優先順序只出現在 MX 與 SRV。RFC 1035 把 MX 的 PREFERENCE 定義成 16 位元的整數，數值越低越優先，主要用來安排備援。
A、AAAA 與 CNAME 負責把網站指向主機
網站要連上主機，只會用到三種紀錄，選哪一種取決於主機商或平台給的是「IP」還是「主機名稱」。對方給 IP 就用 A（IPv6 則用 AAAA），給主機名稱就用 CNAME。Cloudflare 的說明也指出，根網域所需的紀錄類型（A、AAAA 或 CNAME）與內容，取決於託管網站或應用程式的提供者。
以下是龐果設計官網的範例，IP 只用 IETF 保留給文件與範例的位址。192.0.2.10 來自 RFC 5737 的 TEST-NET-1，2001:db8::10 則來自 RFC 3849 的 IPv6 文件前綴。
| 名稱 | 類型 | 值 |
|---|---|---|
@ | A | 192.0.2.10 |
@ | AAAA | 2001:db8::10 |
www | CNAME | example.com |
blog | CNAME | sites.example.net |
實際填寫時，把值換成主機商或平台提供的內容。A 與 AAAA 的值是主機（origin）的位址，不是 Cloudflare 的 IP，Cloudflare 的文件明確說明這一欄不可以填 Cloudflare 的位址。
A 與 AAAA 把名稱指向 IPv4 與 IPv6 位址
A 對應 IPv4，AAAA 對應 IPv6，兩種紀錄都可以讓同一個名稱對應到一個或多個位址，每一筆都會被當成有效答案。以範例來說，根網域 @ 的 A 紀錄填 192.0.2.10，訪客輸入 example.com 就會連到這台主機。
主機如果沒有 IPv6，就不要補 AAAA。補了卻不通，只有走 IPv6 的訪客會連不上，其他人看起來一切正常，排查起來特別費工。
CNAME 是另一個主機名稱的別名，不能與其他紀錄並存
CNAME 的意思不是「轉址」，而是「這個名稱是另一個名稱的別名，查它就等於查那個」。平台指定主機名稱、IP 又可能變動的時候最適合用，例如把 www 設成 CNAME 指向 example.com，或指向平台給的主機名稱。Cloudflare 的文件說明，CNAME 可以串接多層，但最後必須指向一個有有效 A 或 AAAA 的主機名稱，否則解析不出 IP。
CNAME 有一條最重要的限制，同一個名稱底下，CNAME 不能與其他紀錄並存。RFC 1034 第 3.6.2 節寫明，節點上有 CNAME 就不應該再有其他資料，以免規範名稱與別名的資料不一致；RFC 1912 第 2.4 節更直接點名，MX、A 甚至 TXT 都不能與 CNAME 共存；RFC 2181 第 10.1 節只替 DNSSEC 相關的紀錄開了例外，任一名稱底下要不就是 1 筆 CNAME，要不就是沒有 CNAME 的其他紀錄。另外，Cloudflare 提醒，CNAME 如果指到另一個 Cloudflare 帳號，會出現 Error 1014。
www 與根網域需要各自一筆紀錄
example.com 與 www.example.com 在 DNS 裡是兩個不同的名稱，不會自動互通。只設了其中一個，另一個就打不開，這是很常見的狀況。Cloudflare 的建議是，即使不需要特定的子網域，也至少設定 www，因為有 www 紀錄，訪客在網址前面打 www 才找得到網站。
常見的搭配有兩種，一種是根網域放 A、www 用 CNAME 指回根網域，另一種是兩個名稱各自放 A。www 通常指向與根網域相同的內容，或者設定成轉址，轉址本身由主機或平台處理，不在 DNS 裡設定。因為是兩個名稱，驗證時也要分別查，不能查了其中一個就當作另一個也好了。
blog、shop 等子網域指向各自的服務
同一個網域底下，blog、shop、support 可以各自指到不同的主機或平台。Cloudflare 的說明文件建議，要在子網域放內容，先確認主機商能服務該主機名稱（<subdomain>.example.com），再建立對應的 A、AAAA 或 CNAME，名稱欄填子網域標籤，例如 blog、www、store。對方還沒設定好之前，紀錄指過去也連不上。子網域如果要整個交給別人管理，則改用 NS 委派。
使用 Cloudflare 時多出代理狀態欄位
DNS 放在 Cloudflare 時，A、AAAA、CNAME 會多一個代理開關。Proxied（橘雲）時，網頁流量會經過 Cloudflare 的網路，享有快取與 DDoS 防護等功能；DNS only（灰雲）時，Cloudflare 只回覆紀錄的值，不代理流量。
這個欄位常被忽略，後果是郵件主機或驗證用的 CNAME 被誤開了代理。Cloudflare 的建議是，驗證第三方服務網域的 CNAME 用 DNS only，Cloudflare 的 Email 範例中，mail 的 A 紀錄也是 DNS only。另外要知道，只有 A、AAAA、CNAME 這類 IP 解析紀錄能走代理，MX 與 TXT 不行；走代理的紀錄 TTL 固定為 Auto（300 秒），是為了讓 anycast IP 有異動時能快速生效。
走代理的紀錄還有一個容易嚇到人的現象。查詢 A 紀錄時，看到的是 Cloudflare 的位址，不是自己主機的 IP。這是正常的，代表代理正在運作，不要誤判成設錯。
根網域不能放 CNAME，改用 flattening 或 ALIAS
不少平台只給主機名稱，要求使用者設 CNAME；但想把根網域（@）也指過去時，後台常會直接拒絕。原因在於 CNAME 所在的名稱不能有其他資料，而根網域一定同時有 SOA 與 NS，信箱的 MX 也常掛在根網域底下，所以在根網域放 CNAME 就會和這些紀錄衝突。
實務上有三條出路：
- 平台如果同時提供 IP，就改用 A。
- DNS 代管若有 CNAME flattening、ALIAS 或 ANAME 這類「根網域別名」功能，就用它。
- 兩者都沒有的時候，把根網域轉址到
www。
Cloudflare 採用的是 CNAME flattening，它會找出 CNAME 最終指向的 IP（可能需要多次查詢），回應時給的是這個 IP，而不是 CNAME 本身。在根網域設定 CNAME 時，這個功能預設自動啟用，各種方案都一樣。同類的機制在各家叫法不同，ALIAS、ANAME、apex alias、Route 53 的 alias 與 CNAME flattening 都是；它們的共通點是解析設定的目標，再用目標的位址回答根網域的查詢，但控制資料的方式、失敗時的行為與 TTL 政策各家不同。這類功能目前沒有統一的標準，也不是每個 DNS 代管都支援，需要使用時，要查自己 DNS 代管的說明文件。
用 flattening 時，要留意兩個陷阱：
- 付費方案可以選擇讓所有 CNAME 都 flatten，但如果第三方服務用 CNAME 來驗證網域，flatten 之後驗證方看不到 CNAME 本體，驗證可能因此失敗。
- CNAME 最終的目標如果沒有 A 或 AAAA（也就是目標已失效），flatten 會回傳空答案（NODATA），看起來就像紀錄一直沒生效。
Email 要設的紀錄包括 MX、SPF、DKIM 與 DMARC
信箱相關的 DNS設定集中在四組紀錄。MX 管「信往哪裡送」，SPF、DKIM、DMARC 則管「寄出去的信是不是真的從這個網域來」。設定順序是先 MX，再 SPF、DKIM，最後 DMARC，因為 DMARC 要建立在 SPF 與 DKIM 之上。所有的值都以信箱服務商後台給的為準，DKIM 金鑰這類每個網域專屬的值，不能照抄範例。
MX 紀錄指定收信伺服器與優先順序
MX 通常放在根網域，名稱填 @ 或留空，值是收信伺服器的主機名稱，優先順序的數字越小越優先。依 RFC 2181 與 RFC 1035，MX 的值必須是有位址紀錄的主機名稱，不能填 IP，也不能指向 CNAME。換信箱服務時，舊的 MX 要刪掉，否則信會繼續送去舊系統，或是被分流。
SPF 只能有一筆，查詢次數也有上限
SPF 是放在根網域的一筆 TXT，以 v=spf1 開頭，列出有資格代表這個網域寄信的伺服器。Google Workspace 的寫法如下：
v=spf1 include:_spf.google.com ~allCode language: plaintext (plaintext)依 RFC 7208，同一個名稱下出現 2 筆 v=spf1 紀錄，驗證結果就是 permerror，要用多個寄信服務時，把 include 合併進同一筆。include、a、mx 這類項目會計入 DNS 查詢次數，被 include 進來的紀錄也要一起累計，ip4、ip6 則不計入，總數超過 10 次，同樣會失敗。
DKIM 公開金鑰放在 _domainkey 子網域
DKIM 的公開金鑰放在 <selector>._domainkey 這個名稱底下（RFC 6376），名稱和值都由信箱服務產生。Google Workspace 用 1 筆 TXT，Microsoft 365 用 2 筆 CNAME，照後台給的內容建立即可。2048 位元的金鑰很長，部分後台會限制 TXT 的長度，貼上後要讀回來核對是否完整。
DMARC 紀錄放在 _dmarc，政策從 none 開始
DMARC 是 _dmarc 子網域的一筆 TXT（RFC 7489），規定 SPF、DKIM 沒通過的信該怎麼處理，並請收信方寄回統計報表。SPF 與 DKIM 穩定運作之後，再以 p=none 起步：
v=DMARC1; p=none; rua=mailto:[email protected]Code language: plaintext (plaintext)確認合法的寄件來源都通過驗證，再逐步調整為隔離（quarantine），最後才是拒絕（reject）。
網域驗證 TXT 與 CAA、SRV、NS 的填寫方式
除了網站與 Email，網域還會遇到幾類比較少動、卻常被服務商要求的紀錄。依 Cloudflare 的定義，TXT 是以雙引號包住的一或多段文字，通常用來證明網域的擁有權；CAA 指定哪些憑證機構（CA）可以替網域簽發憑證；SRV 指定特定服務（像 VoIP、即時通訊）使用的主機與連接埠；NS 則指定由哪一組伺服器負責權威 DNS，只有在設定子網域，或是把子網域委派出去時，才需要加進紀錄表。
| 類型 | 名稱 | 值（示範） | 用途 |
|---|---|---|---|
| TXT | @ | 服務商給的整段文字 | 證明網域擁有權 |
| CAA | @ | 0 issue "ca.example.net" | 限定可以簽發憑證的機構 |
| NS | blog | ns1.example.net | 把子網域交給別處管理 |
| SRV | _sipfederationtls._tcp | 100 1 5061 sipfed.online.lync.com | 指定服務的主機與連接埠 |
網域擁有權驗證的 TXT 可與 SPF 並存
Google、Microsoft 等服務為了確認網域是你的，會給一段文字，要求新增成 TXT。很多人看到前面「SPF 只能 1 筆」，就誤以為根網域不能有第二筆 TXT。實際上，受限的只有「以 v=spf1 開頭」的那種紀錄，驗證用的 TXT 可以和 SPF 並存在同一個 @ 底下。
填法很單純，類型選 TXT，主機填 @，值把服務商給的整段文字貼上。RFC 7208 第 4.5 節是這麼規定的，解析器取回紀錄集之後，會先丟棄不以 v=spf1 開頭的紀錄，剩下的如果多於 1 筆，結果才是 permerror。Google 建議同一個網域的 TXT 紀錄不要超過 200 筆，這是大多數網域支援的上限；Microsoft 則表示，網域驗證用的這筆 TXT 只用來確認擁有權，不影響其他設定。
CAA 限定可以簽發憑證的機構，一般網站不一定要設
CAA 是網域擁有者交給憑證機構（CA）的一份授權清單。RFC 8659 規定，合規的 CA 在簽發憑證之前，必須先檢查網域是否發布了相關的 CAA 紀錄；如果有，除非確認請求與 CAA 一致，否則不得簽發。如果紀錄集中沒有任何限制簽發的屬性標籤，CAA 就不構成限制。所以一般網站不一定需要設 CAA，沒有設定時，不會影響憑證的簽發。
格式範例如下：
example.com. CAA 0 issue "ca.example.net"Code language: plaintext (plaintext)issue 指定可以簽發一般憑證的機構，issuewild 針對萬用字元憑證，issue ";" 則代表不允許任何 CA 簽發。真的要設的人，最容易出事的是限制得太嚴，結果連自己的主機商或憑證服務都發不出憑證。設定之前，先向憑證服務確認它所使用的 CAA 識別字串，再填進紀錄。
SRV 指定服務連接埠，NS 把子網域交給別處
SRV 與子網域的 NS 屬於進階紀錄，但偶爾會遇到。SRV 讓某項服務找到正確的主機與連接埠，名稱格式是 _service._proto.name，值依序是優先順序、權重、連接埠、目標主機。RFC 2782 的完整格式為 _Service._Proto.Name TTL Class SRV Priority Weight Port Target，服務名稱前加底線，是為了避免與自然出現的 DNS 標籤衝突。
後台的欄位不一定齊全，Microsoft 提供了變通做法，沒有「服務」與「協定」欄位時，把 _sipfederationtls._tcp 直接寫進主機名稱欄；沒有優先順序、權重、連接埠欄位時，依序把數字寫進目標欄，例如 100 1 5061 sipfed.online.lync.com。有些後台還要求目標結尾加句點，欄位的名稱也各家不同，以後台的說明為準。
子網域的 NS，則是把 blog.example.com 整個交給另一組名稱伺服器管理，例如 blog 這個名稱的 NS 值填 ns1.example.net。Cloudflare 的說明指出，想讓子網域的 DNS設定完全在 Cloudflare 之外、由沒有 Cloudflare 帳號權限的人管理，才需要用到委派。依 RFC 1912，同一個委派建議不超過 7 個名稱伺服器，Cloudflare 本身的上限是 10 筆。
紀錄生效的時間取決於 TTL 與快取
「改了要等多久」，常被一句「最多 48 小時」帶過。實際決定等待時間的是快取，各地的解析器各自把舊答案存著，存到 TTL 到期才會重新來問。所以「生效」並不是全球 DNS 同步完成的那一刻，而是各地快取陸續到期、重新查到新答案的過程。
Google 的 DNS 基礎知識說明，TTL 是 DNS 紀錄中的值，定義紀錄後續變更生效前的秒數。紀錄目前的 TTL，決定現在所做的變更需要多久才會生效，例如 TTL 為 86400 秒，變更最多要 24 小時。Google 建議平時 TTL 設為 3600；計畫要改動之前，先調成 300 秒，萬一需要快速還原也來得及；改好、確認無誤之後，再改成 86400。
有一點容易搞錯。調短 TTL 只對「下一次」更新有用。Google 的說明指出，較短的 TTL 只會在先前的時間到期後生效，已經被快取的舊答案，仍然照舊的 TTL 過期。假設現在的 TTL 是 86400 秒，換主機前一天才調成 300 秒，那麼調整前剛被快取的舊答案，仍可能保留最久 24 小時，所以要提早調。
各類紀錄的等待上限，說明文件給的數字並不相同，如實列在下表：
| 變更內容 | 說明文件給的等待時間 | 出處 |
|---|---|---|
| 更換名稱伺服器 | 最多等 24 小時 | Cloudflare 設定頁 |
| 更換名稱伺服器 | 通常從幾分鐘到 48 小時 | Cloudflare 學習路徑 |
| MX | 最多 72 小時內辨識完成 | |
| SPF | 最多可能需要 48 小時 | |
| DKIM | 新增後最多 48 小時才會運作 |
更換名稱伺服器的兩個數字都出自 Cloudflare，實際仍以網域狀態變成 Active 為準。
「查不到」也會被快取。紀錄還不存在時被人查詢，「不存在」這個答案會依 SOA 的負向快取設定被存起來，RFC 2308 對此有規範，Cloudflare SOA 紀錄中負向快取的 Minimum TTL 預設是 1800 秒。所以建好紀錄之前，不要反覆去查，否則「不存在」這個答案可能被快取起來，反而讓自己更晚看到新紀錄。
用 nslookup 與 dig 驗證紀錄
改完紀錄，不要只靠瀏覽器重新整理，直接向名稱伺服器查詢最準確。nslookup 在 Windows、macOS、Linux 都有，dig 的輸出更精簡，也方便指定要詢問哪台伺服器。環境裡沒有 dig 時，可以用 nslookup，或是 Google Admin Toolbox 的 Dig 工具，Google 的 MX 說明就提到過。至於網頁式的 DNS 查詢工具，Cloudflare 提醒，多半使用快取的查詢結果，更新可能慢一步。
以下的指令都以 example.com 為例，換成自己的網域即可。
nslookup 查詢各類紀錄的指令
依 Microsoft Learn 的 nslookup 說明，非互動模式的第一個參數是要查的名稱，第二個參數是指定的 DNS 伺服器，省略就用預設值。-type= 指定紀錄類型。常用的查詢如下：
- 名稱伺服器：
nslookup -type=NS example.com - IPv4 位址：
nslookup -type=A example.com - IPv6 位址：
nslookup -type=AAAA example.com - 別名：
nslookup -type=CNAME www.example.com - 收信伺服器：
nslookup -type=MX example.com - 文字紀錄（含 SPF）：
nslookup -type=TXT example.com - DMARC：
nslookup -type=TXT _dmarc.example.com - DKIM：
nslookup -type=TXT google._domainkey.example.com - 指定向 1.1.1.1 詢問：
nslookup -type=MX example.com 1.1.1.1
在 Windows 上，如果查回來的結果看起來對不上，例如出現與網域無關的 SOA，可能是系統自動在名稱後面補上本機的網域尾碼。這時在網域名稱結尾加一個句點，寫成 example.com.，代表這是完整的網域名稱，系統就不會再補尾碼。
Windows 本機還可以用 ipconfig /flushdns 清除並重設 DNS 用戶端的解析器快取，Microsoft 說明這個指令在疑難排解時，可以用來丟棄負向快取項目與其他動態新增的項目。
dig 向公共解析器與權威名稱伺服器查詢的指令
dig 的語法是 dig [@server] [-t type] [name] [type]，@server 是要詢問的名稱伺服器，預設查詢類型是 A，加上 +short 就只輸出精簡的答案。
dig example.com A +short
dig example.com MX +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig example.com NS +short
dig example.com NS @8.8.8.8
dig example.com NS @1.1.1.1Code language: plaintext (plaintext)除了公共解析器，還可以直接問網域的權威名稱伺服器，繞過各地快取，確認「紀錄本身有沒有改成功」。做法是先用 dig example.com NS +short 取得名稱伺服器的名稱，再詢問那一台：
dig example.com A @ns1.example.netCode language: plaintext (plaintext)其中的 ns1.example.net，要換成上一步查到的實際名稱。權威伺服器對自己負責的區段握有完整資訊，回答的是目前紀錄本身，不受解析器快取影響。
查詢結果要核對的 3 個重點
同樣一份輸出，要知道看哪裡。核對順序可以記成三步：
- NS 是否為預期的代管：名稱伺服器要和自己正在編輯的後台對得上。
- 值是否與服務商給的逐字相同：MX 要核對優先順序與主機，TXT 要確認沒有被截斷、沒有多餘的空格。
- 不同解析器的答案是否一致：一致，才算生效。
不同解析器的答案不一樣，通常是快取還沒到期，不是設錯，回頭對照 TTL 那一節的時間就能判斷。Cloudflare 的學習路徑也提醒，要看的是 Cloudflare 的名稱伺服器有沒有被一致地回報。
DNS設定的常見錯誤集中在填寫格式與殘留的舊紀錄
DNS設定出問題時，紀錄看起來通常都填了，只是填法有誤，或是殘留的舊紀錄讓結果和預期不同。
主機名稱欄被重複補上網域
症狀是紀錄列表裡出現 example.com.example.com 這樣的名稱，查詢時自然找不到。原因是很多後台會自動在名稱後面補上網域，使用者又填了完整的網域，結果被補了兩次。
修法是名稱欄填相對名稱就夠了，像 @、www、_dmarc。如果後台明確要求填完整名稱，就照辦，再用查詢指令複核。新增之後，也要看紀錄列表實際顯示的完整名稱。Google 談 DMARC 時也提醒，部分網域代管商會自動加上網域名稱，新增或更新 TXT 後，要確認紀錄的網域名稱格式正確。
舊的 A 或 MX 紀錄沒有刪除
症狀是網站時好時壞，或是信有時收得到、有時收不到。原因是新增了新紀錄，卻沒刪舊的，A 紀錄有 2 個 IP，訪客有一部分會連到舊主機；MX 有 2 台，信一部分進了舊系統。Cloudflare 的文件說明，A 與 AAAA 可以對應到一或多個位址，所以並存不會被拒絕，也不會有警告。
修法是搬完、確認無誤之後，明確刪掉舊的。MX 也是同樣的道理，Google 與 Microsoft 的說明都要求移除舊 MX，或是把舊的排在後面。刪除之前，先確認舊系統裡的資料都已經搬完，尤其是舊信箱裡的郵件。
TXT 的引號、換行與長度出錯
TXT 的值是一整段文字，貼上時常被後台加引號、換行，或是被截斷。症狀通常是驗證一直失敗，或是 SPF、DKIM 看起來設了卻沒作用。
Cloudflare 的規則是，TXT 內容由一或多段以雙引號包住的文字組成，引號不一致（例如 "this 或 "these" ones"）會導致驗證錯誤；新紀錄如果沒有帶引號，Cloudflare 會自動補上雙引號。長金鑰（像 2048 位元的 DKIM）還會受到單段字串長度和後台限制影響，Google 就提醒部分網域供應商會限制 TXT 的長度。背景知識是，RFC 1035 規定單段字串最長 255 個字元（含長度位元組共 256 個八位元組），長值會被拆成多段，後台通常會自動處理，不需要手動拆。
修法是貼完之後，一定要用查詢指令把結果讀回來，與服務商給的內容逐字比對。
已停用服務的 CNAME 仍留在紀錄裡
子網域曾經指到某個平台，服務不用了、帳號也關了，DNS 的 CNAME 卻還留著。輕的情況是解析出空答案，像前面 flattening 遇到目標失效時回傳的 NODATA，看起來就像紀錄尚未傳遞。重的情況是這筆留下來的紀錄，成了被他人接管子網域的缺口。
修法是停用服務的同時，也刪掉對應的 DNS 紀錄，並且定期盤點子網域，確認每一筆紀錄背後的服務還在運作。
紀錄正確卻仍看到舊結果時的排查順序
紀錄看起來都對，卻還是看到舊的結果時，照下面的順序走，就不會亂改：
- NS 是否指向正在編輯的後台：用 nslookup 查 NS 類型，確認改的地方是對的。
- 直接問權威名稱伺服器：用 dig 指定那一台，看新值在不在。
- 換幾個公共解析器查：用 dig 分別指定兩個公共解析器，看答案是否一致。
- 等 TTL 與負向快取到期：對照前面的生效時間，別在到期前反覆修改。
- 清本機快取：在 Windows 執行
ipconfig /flushdns。 - 只有特定網路或裝置得到錯誤答案：才往 DNS 劫持、污染的方向查。
下一次 DNS設定看起來沒生效，先別急著再改一次紀錄。先確認改對了地方，再看快取有沒有過期，多數時候，問題在這兩件事裡就能找到，不必動到紀錄本身。DNS 的紀錄只是一份清單，真正決定結果的，是誰在回答，以及舊答案還在不在。