「網站打不開，但 LINE 和 Teams 都還能用。」
這句話聽起來有點矛盾。
既然通訊軟體可以正常連線，代表電腦應該有網路；但瀏覽器卻一直顯示找不到網站，使用者自然還是會把它歸類成：
網路壞了。
這時先不要急著重新插線，也不要直接重啟 Firewall。
如果改用網站的 IP Address 可以連線，但輸入名稱卻失敗，那麼底層網路可能根本沒死，只是負責「把名稱翻譯成 IP」的 DNS 發生問題。
當然，DNS 經常背鍋，不代表這次就能直接判它有罪。
我們還是得先看證據。
平常我們會輸入：
intranet.example.local
但網路設備實際傳送封包時，需要的是目的 IP，例如：
10.10.50.10
DNS 的工作，就是將容易記憶的名稱解析成 IP Address。
概念上像這樣：
使用者輸入名稱
→ Client 查詢 DNS
→ DNS 回覆 IP
→ Client 對該 IP 建立連線
如果 DNS 查詢失敗，Client 連目的 IP 都還不知道，自然無法開始後面的 TCP 或 HTTPS 連線。
所以使用者看到的是網站打不開，但真正卡住的地方，可能發生在封包前往網站之前。
新手很容易把 DNS 理解成：
輸入名稱，某台 Server 回傳 IP。
概念沒錯，但企業環境通常更複雜。
一次 DNS 查詢可能經過：
應用程式
→ 作業系統 Resolver
→ 本機 Cache
→ Hosts File
→ 設定的 DNS Server
→ DNS Cache
→ Forwarder
→ Root／TLD／Authoritative Server
若是企業內部名稱，可能還涉及：
因此，「DNS 不通」只是大分類。
真正要查的是：
假設 Client 要查詢：
www.example.com
簡化後的流程如下。
Client 可能先查看：
如果已有有效答案，就不一定需要立刻向 DNS Server 查詢。
如果本機沒有答案，Client 會向網卡設定中的 DNS Server 發出 Query。
常見 Port 為：
UDP 53
但 DNS 也可能使用：
TCP 53
例如：
因此，只開 UDP 53 不一定能支援所有 DNS 情境。
DNS Server 可能：
DNS Server 回覆 Record 和 TTL，Client 將結果保存一段時間，接著使用解析出的 IP 建立真正的服務連線。
DNS 問題不是只有「查不到」。
至少要分辨：
Timeout 代表 Client 沒有在時間內收到回覆。
可能原因包括：
典型訊息可能是：
DNS request timed out.
這代表「沒有得到答案」，但不表示名稱一定不存在。
NXDOMAIN 代表 DNS Server 明確回答：
這個名稱不存在。
可能原因包括：
這和 Timeout 不同。
Timeout 是沒人回答；NXDOMAIN 是有人回答你「沒有這個人」。
這種情況更麻煩，因為 DNS 查詢表面上是成功的。
可能原因包括：
例如正確 Server IP 應為：
10.10.50.10
Client 卻解析成：
10.10.60.20
此時瀏覽器仍會嘗試連線，只是一路前往錯誤的地方。
結果可能是：
這類問題不能只看 nslookup 是否「有回覆」，還要確認答案是否正確。
Windows、Linux 與 macOS 都常能使用：
nslookup intranet.example.local
可能得到：
Server: dns01.example.local
Address: 10.10.10.53
Name: intranet.example.local
Address: 10.10.50.10
重點不只是最後的 IP，還要看：
如果顯示：
Server: Unknown
不一定代表 DNS Server 故障。
有時只是 DNS Server IP 缺少對應的 PTR Record，因此 nslookup 無法反向解析它的名稱。只要後續查詢正常，它仍可能可以使用。
這個畫面很常嚇到人，但先別急著替 DNS Server辦後事。
可以直接指定要詢問的 DNS Server：
nslookup intranet.example.local 10.10.10.53
這能協助比較：
例如：
預設查詢：失敗
指定 10.10.10.53：成功
這時可能表示：
如果指定公司 DNS 仍失敗，才繼續檢查 Server、路徑與 Record。
把 DNS 改成公共 DNS，是網路教學裡非常常見的建議。
在家用環境，它有時可以避開 ISP DNS 問題；但在企業環境裡，直接改成公共 DNS 可能製造更多問題。
公共 DNS 通常不知道公司的內部 Zone，例如：
intranet.example.local
fileserver.corp.example.com
dc01.example.local
而 Active Directory 也依賴 DNS 尋找：
如果 Domain Client 改用公共 DNS，可能出現：
所以，企業環境裡的正確方向通常是：
Client 使用企業 DNS，再由企業 DNS 處理內部 Zone，並將外部查詢轉送至適當上游。
不是叫每台 Client 各自逃去公共 DNS。
這樣外網可能被你治好了，內網卻順手變成大型密室逃脫。
DNS 不只是名稱對 IP。
常見 Record 包括：
| Record | 用途 |
|---|---|
| A | 名稱對應 IPv4 |
| AAAA | 名稱對應 IPv6 |
| CNAME | 名稱別名 |
| MX | 郵件伺服器 |
| PTR | IP 反向解析名稱 |
| NS | Zone 的 DNS Server |
| TXT | 驗證或文字資訊 |
| SRV | 服務位置 |
| SOA | Zone 基本資訊 |
例如：
intranet.example.local
→ 10.10.50.10
例如：
portal.example.local
→ web01.example.local
Client 還需要繼續解析 web01.example.local 的 A 或 AAAA Record。
反向解析：
10.10.50.10
→ web01.example.local
PTR 常用於：
SRV Record 可以告訴 Client 某個服務位於哪台主機及哪個 Port。
Active Directory 很依賴 SRV Record。
因此，AD 環境中的 DNS 問題可能不只是「網站打不開」，還可能影響登入與網域服務。
企業可能對同一網域提供不同答案，稱為 Split DNS 或 Split-horizon DNS。
例如：
portal.example.com
內部 Client 解析：
10.10.50.10
外部使用者解析：
203.0.113.10
這樣可以讓：
但如果 Client 使用錯誤 DNS，就可能拿到錯誤版本的答案。
例如公司內部 Client 使用公共 DNS，結果解析到 Public IP；Firewall 又不支援或未設定 Hairpin NAT，於是同一網站外面能開，公司裡反而不能開。
這時看起來像 Firewall 問題，根本原因也可能是 DNS 回覆不符合 Client 所在位置。
企業裡可能有多個 DNS Namespace。
例如 A 廠管理：
factory-a.example.local
B 廠管理：
factory-b.example.local
A 廠 DNS 不需要知道 B 廠所有 Record，只需設定 Conditional Forwarder：
查詢 factory-b.example.local
→ 轉送到 B 廠 DNS
如果 Conditional Forwarder：
就可能只有特定網域解析失敗。
外部網站正常、A 廠名稱正常、只有 B 廠名稱失敗時，這條線索就很明顯。
使用者有時會輸入：
fileserver
而不是完整名稱：
fileserver.example.local
作業系統可能根據 DNS Suffix Search List，自動嘗試：
fileserver.example.local
如果 DNS Suffix 缺少或錯誤，就可能出現：
例如：
nslookup fileserver.example.local
成功，但：
ping fileserver
失敗或等待很久。
這時應檢查：
不要因為短名稱失敗，就立即建立一堆重複 DNS Record。
先確認 Client 原本應該如何補齊名稱。
DNS 回覆通常包含 TTL：
Time To Live
它表示這筆答案可以被快取多久。
例如：
TTL：3600 秒
Client 或 DNS Server 可以在一小時內繼續使用這筆資料，不必每次重新查詢 Authoritative Server。
這可以減少：
但當 DNS Record 修改後，舊答案可能仍留在不同層級的 Cache 中。
因此會出現：
這不一定是 DNS 複寫失敗，也可能只是 TTL 尚未到期。
查看 Cache：
ipconfig /displaydns
清除 Cache：
ipconfig /flushdns
但清除前最好先記錄：
如果一開始就 Flush，可能把重要證據清掉。
而且 Flush 只會清除 Client 本機 Cache。
如果錯誤資料存在於：
只清 Client 並不能解決根因。
如果已知服務即將切換 IP，可以提前降低 TTL。
例如原本：
TTL：86400 秒
代表最多可能快取一天。
若預計明天切換，可以提前將 TTL 降為：
300 秒
等原本長 TTL 的 Cache 逐漸過期後，再修改 Record。
切換穩定後，再把 TTL 調回合理數值。
如果到了切換當下才把 TTL 從一天改成五分鐘，已經拿到舊答案的 Client 仍會按照舊 TTL 保存。
DNS 不會因為你現在很急，就回到過去替所有 Cache 改設定。
Windows Hosts File 通常位於：
C:\Windows\System32\drivers\etc\hosts
Linux 通常為：
/etc/hosts
如果裡面有：
10.10.60.20 intranet.example.local
即使 DNS 已改成：
10.10.50.10
Client 仍可能優先使用 Hosts File 的舊設定。
這常出現在：
測試結束後沒有移除，幾個月後就會變成一顆很安靜的地雷。
當只有單一 Client 解析錯誤，而其他人都正常時，Hosts File 是值得檢查的地方。
Client 通常會設定 Preferred DNS 與 Alternate DNS。
很多人以為：
第一筆查不到，就自動問第二台。
但實際行為不是這麼單純。
如果第一台 DNS 正常回覆 NXDOMAIN，Client 可能不會因為不喜歡答案就去問第二台。
Alternate DNS 主要用於第一台無法回應等情況，不是用來讓兩台 DNS 各自管理不同資料。
因此，多台 DNS 應該提供一致、可用的資料。
不能設計成：
Client 沒有義務理解公司的創意架構。
有些問題不是完全查不到，而是輸入主機名稱後固定等待數秒才成功。
常見原因包括：
如果每次都差不多慢五秒，這個固定時間本身就是線索。
它通常暗示某個查詢流程先等待 Timeout，才進入下一個解析方式。
這種問題會在後面的名稱解析文章進一步討論。
DNS 通常透過指定的 DNS Server 查詢。
mDNS 是 Multicast DNS，常使用：
224.0.0.251
UDP 5353
它常見於：
.local
mDNS 主要設計於同一個 Layer 2 區域。
它的 Multicast 通常不會自動跨越：
因此：
raspberrypi.local
在 NixOS 同網段可以立即解析，從 Windows 經過另一個網段或 VPN 卻可能失敗或等待數秒。
這不一定是傳統 DNS Server 故障，而是名稱原本依賴 mDNS。
需要跨網段穩定存取的服務，更適合建立正式 DNS Record，而不是期待 Multicast 自己穿過所有網路邊界。
假設環境中有一台 Raspberry Pi。
測試結果：
.local 後，部分工具行為又不同這時可以分別測試：
Raspberry Pi IP
短主機名
完整 DNS 名稱
.local 名稱
如果 IP 立即成功，說明基本路由存在。
如果短名稱等待後才成功，可能是：
如果 .local 只在同網段正常，則要考慮 mDNS 的 Multicast 邊界。
真正的解法不一定是一直縮短 Resolver Timeout。
縮短 Timeout 可以讓失敗快一點，但如果服務需要跨網段被穩定找到，更合理的方式可能是：
否則只是把五秒等待改成一秒等待，架構問題仍然很安穩地待在原地。
遇到「IP 可以連，名稱不行」時，可以依序檢查。
分別測試：
.local
確認問題真的是解析，而不是服務本身。
Windows：
ipconfig /all
確認：
nslookup hostname.example.local
記錄：
nslookup hostname.example.local 10.10.10.53
比較：
從不同位置測試：
並確認使用者原本的應用真的恢復。
當 IP 可以連線、名稱卻失敗時，DNS 確實是重要嫌疑人。
但 DNS 問題還可以細分成：
因此，不要只用「改成公共 DNS」處理所有問題。
企業 DNS 往往還負責內部 Zone、AD 與跨站服務。外網能開，不代表整體真的被修好了。
iThome鐵人賽
看影片追技術