[NextDNS]一個被阻擋的網域導致微軟服務大罷工😕

最近幾天發現有時在與Copilot對談的時候，Copilot常常會出現無法連線的訊息。起初以為只是伺服器繁忙導致延遲，所以就沒過多在意。直到今天，整個Copilot直接罷工，連帶Bing搜尋也跟著一起罷工（不過我自己還是比較偏好Google）。經過一整天的鬥智鬥勇，還有與Gemini的討論下，總算找到了源頭。

dns.msftncsi.com

或許各位看官不知道這個網域是做什麼的。但是只要你的電腦用的是Windows，系統判定是否連上網路，就跟它有關係了。

怎麼說呢？

這是因為Windows系統會定期去Query這個網域，若返回正確結果，系統就會認定網路連線正常；反之，就可能會出現連線能力受限的警告，或是其他奇怪的症狀（比如本例的Copilot與Bing等等的通通罷工）。

首先我想到的是NextDNS，它是目前我用來給家中所有設備阻擋廣告用的，而且效果在大多數情況下都很不錯。唯一缺點就是免費方案有查詢次數限制，超過就只能當純DNS用；想取消限制？只要肯付點小錢，就不是難事。

但萬萬沒想到就是它，導致了這篇文提到的這一問題（其中又是因為下圖這一防護功能的關係）。

關於什麼是DNS重新綁定攻擊，由於小弟在這方面才疏學淺，雖然有看了一下相關資料。但為了避免誤導，所以還是給專業的來解釋（點此閱讀）。

總之上圖所示的功能，便是用來阻止這一攻擊方式；但在這篇文中的案例，它成了一把雙面刃：在防護的同時也把微軟相關的服務也”格殺勿論”了。

至於解決辦法，其實也非常簡單：只要把上述的網域加進NextDNS的白名單，稍候片刻便雨過天青，再次變得美好了。既能夠解決此次的問題，又不至於因噎廢食。

至於其原因，我這裡就把在Copilot詢問得到的結果放在下面，給看官們做為參考：

• TTL（生存時間）過短：dns.msftncsi.com 的 DNS 記錄可能設置了非常短的 TTL（例如 30 秒），這可能被誤判為重新綁定行為，因為攻擊者通常利用短 TTL 來快速更改域名的 IP 地址。
• 內網 IP 地址檢測：雖然 dns.msftncsi.com 不解析為內網地址，但某些防護機制可能會將其誤認為潛在威脅，特別是在其行為模式與典型的重新綁定攻擊相似時。
• 過濾規則過於嚴格：NextDNS 的防護規則可能過於保守，導致一些合法的域名被誤封。這種情況在涉及系統關鍵服務（如 Microsoft 的 NCSI）時尤其容易引發問題。
• 誤報：某些情況下，NextDNS 的威脅情報數據庫可能將 dns.msftncsi.com 誤標記為可疑域名，從而觸發封鎖。

一言以蔽之，就是NextDNS「太龜毛」。

2025年3月17日更新

今天Copilot又突然用不了，可是我都已經把上面的網域加白名單了耶！又會是哪裡出問題了？

就在我百思不得其解時，突然想起之前YouTube直播出包的解決方法；於是我就做了個實驗：

把AdGuard阻擋清單停用，改用OISD；NextDNS官方推薦的阻擋清單仍然保留。
上回YouTube直播不能看，原因是當時NextDNS官方推薦的阻擋清單可能有問題（我停用這一清單後就恢復正常，後來再啟用也沒復發，可見官方有修復其中的問題）；這次將AdGuard清單停用，改用OISD試試。

這回是有正常了一陣子，但之後又不行了。🙁

後來經過了一系列測試與調整：

1. 觀察記錄檔，將可能與之相關的網域加入白名單：無效
2. 關閉一些防護功能：無效
3. 關閉「設定」頁面的性能區段的所有選項：無效
4. 將路由器中的主要與次要DNS對調：成功

搞了半天，原來就是NextDNS設定檔中的DNS自己的問題。那為什麼咧？

它提供了兩個IP：45.90.28.X與45.90.30.X。出問題時，我是以前者為主要DNS；這次我就改以後者為主DNS，這才徹底解決了問題（不過還是需要觀察一陣子才能確定）。

我猜可能是因為45.90.28.X這組很多人用（列在第一順位），所以伺服器就被變相DDoS，GG了；不然怎麼解釋換成45.90.30.X這組就一切太平了呢？