交大建築所自 2006 年初開始採用 Google Apps for Education 雲端服務，已經邁入第十個年頭了（遠目），是全球第一批將電郵信箱交給 Gmail 代管的教育單位之一，也比咱們自家交大早了兩年呢。期間曾經發生一兩次無預警部分帳號與信件遭刪除。至今仍不確定原因，有可能是管理員帳號遭盜用或 Google Apps 本身問題。後來緊急去信 Google 客服求救，竟幸運找回多數遺失帳號和信件，少數則莎喲那拉了。除此之外，整體使用經驗非常好。畢竟零維修、容量大、妥善率高、跨平台普及，誰能不愛呢？
然而，2015年的一開始，建築所信箱就開始出現不同於以往的災情，包括被退信、收不到信、信件失蹤等狀況。如果是一般帳號出問題就算了（偏心），但竟然是最重要的所務公告也收不到！這事非同小可，得即刻解決！於是我自一月中旬開始調查，發現三個主要症狀：
不過這台老伺服器同時也是內網的 AD Server，掌管所內列印管理與帳號認證，升級 Win Server 2008 一來要再花錢，二來要不少準備工夫，很難在幾天內搞定。但完全移除它的 DNS 角色也不可行，因為那是 AD Server 的必要功能。和計網中心討論後，決定將內網、外網 DNS 分開，原有 DNS 只回應內網 query，相對減輕負擔。然後再增設新的 DNS 應付外部 query，作為正式對外管道。
同時我也向 Google for Work 客服反應信件遺失問題，很快獲得一位客服專員 Ashik 的回應。他表示的確部分 DNS 查詢失敗，也有部分 DNS 資料不同步，可能是導因，要我方先確認 DNS 資料正確性。
然而，2015年的一開始，建築所信箱就開始出現不同於以往的災情，包括被退信、收不到信、信件失蹤等狀況。如果是一般帳號出問題就算了（偏心），但竟然是最重要的所務公告也收不到！這事非同小可，得即刻解決！於是我自一月中旬開始調查，發現三個主要症狀：
- 寄到arch.nctu.edu.tw信件遭退件(reject)
可能原因：送信主機找不到arch.nctu.edu.tw網域，這應該是DNS問題。 - 寄到arch.nctu.edu.tw信件遺失(lost)
可能原因：信件轉寄過程出差錯，最初猜測也是DNS問題，但後來才知道其實是郵遞路徑(email routing)問題，二者大不相同。 - 登入 Google Apps 管理介面後看到 Mail Setup Incomplete 的提醒，表示該網域的 MX (mail exchange) 轉信機制尚未經過認證，這通常出現在剛剛登記使用 Google Apps 的網域上，怎麼會出現在用了將近十年的網域呢？即使按指示進行 MX 認證也等很久、一直失敗、等很久、一直失敗。期間還發現一個怪現象，Google 雖正確辨認建築所的上層網域是 nctu.edu.tw，但有時候卻會誤認為是 nchc.org.tw。（後來才知道不是誤認，交大的確有一台 NS 是在 NCHC）
- 建築所 DNS 是否被擋？
不過這台老伺服器同時也是內網的 AD Server，掌管所內列印管理與帳號認證，升級 Win Server 2008 一來要再花錢，二來要不少準備工夫，很難在幾天內搞定。但完全移除它的 DNS 角色也不可行，因為那是 AD Server 的必要功能。和計網中心討論後，決定將內網、外網 DNS 分開，原有 DNS 只回應內網 query，相對減輕負擔。然後再增設新的 DNS 應付外部 query，作為正式對外管道。
連夜趕工設定伺服器（嗯～用 NAS 架設真簡單），兩部新 DNS 伺服器上線，負責外網；老 DNS 伺服器負責內網，並用防火牆擋住來自外部的 query。接著計網中心更新 DNS 紀錄、刷新快取資料，等全球 DNS 快取資料都逐步更新後，趕緊測試... 校內、國內線路測試OK，少數信件收發恢復正常，正在高興，卻發現從國外測試還是老樣子，偶而找不到建築所網域，網域內互寄信件仍然會遺失。挫敗！
好，只要透過國內 DNS 就能找到建築所，透過國外就偶而找不到。這個「偶而找不到」就玄了，究竟是透過哪裡？成功失敗機率是多少呢？我從許多國外測試網站試了半天，覺得很怪，成功與失敗之間似乎有某種模式，但說不上來。可以確定的是 Google 的公共DNS 8.8.8.8 和 8.8.4.4 失敗率極高，只好再度求助 Ashik，往返討論幾次之後，知道了幾個更有效的測試管道。包括：
好，只要透過國內 DNS 就能找到建築所，透過國外就偶而找不到。這個「偶而找不到」就玄了，究竟是透過哪裡？成功失敗機率是多少呢？我從許多國外測試網站試了半天，覺得很怪，成功與失敗之間似乎有某種模式，但說不上來。可以確定的是 Google 的公共DNS 8.8.8.8 和 8.8.4.4 失敗率極高，只好再度求助 Ashik，往返討論幾次之後，知道了幾個更有效的測試管道。包括：
- Google Apps Toolbox：專門用來檢測 Google Apps 代管的網域是否可以正常運行，包括 DNS 查詢、郵件轉寄(MX)、信件檔頭(header)分析、強制更新 Google 公共DNS 的快取、...等。
- Squish DNS traversal checker：地毯式DNS追蹤查詢，從全球不同伺服器發出 DNS 查詢，統計成功率與 DNS 回應狀況，可快速了解特定網域的 DNS查詢效度。
經過 Ashik 的提示以及幾天的檢測後，才了解 DNS 和 mail routing 問題的差異。如果是我方 DNS 本身的問題，信件一寄出就會立刻被退件(reject)或回覆無法轉寄但會繼續嘗試(delivery error)的訊息，但如果是 mail routing 過程中途，轉寄管道太複雜，又遇到某台轉寄主機突然找不到我方 DNS 或 timeout，就會造成寄信主機以為成功，卻在中途莫名延遲或消失，就像海角七號的阿嘉把信藏到床底下一樣... 或者丟到清水斷崖去。
逐漸歸納到一個奇怪的可能性：只要透過 Google 的某些 DNS 查詢路徑就找不到！難怪 Ashik 察覺不到問題，而往我方 DNS 設定的方向追蹤。因為這個問題從我們的角度看得比較清楚（受害者啊～～），從 Google 方面就只是覺得一直看不到。做個比喻：Google 就像是光源，看不到自己發出的光線被誰遮住而造成陰影，甚至根本不知道光線被擋住，但因為我們在陰影下，知道肯定有人擋住了，只是不知道是誰。（那個誰就是阿嘉啦）
逐漸歸納到一個奇怪的可能性：只要透過 Google 的某些 DNS 查詢路徑就找不到！難怪 Ashik 察覺不到問題，而往我方 DNS 設定的方向追蹤。因為這個問題從我們的角度看得比較清楚（受害者啊～～），從 Google 方面就只是覺得一直看不到。做個比喻：Google 就像是光源，看不到自己發出的光線被誰遮住而造成陰影，甚至根本不知道光線被擋住，但因為我們在陰影下，知道肯定有人擋住了，只是不知道是誰。（那個誰就是阿嘉啦）
又經過幾天的追蹤，以及計網中心的調查後，有提到交大防火牆擋了部分外部 IP，可能因此影響到從 Google Apps 來查詢 DNS 的連線，校方嘗試降下防火牆後，DNS 連線有恢復一些，但仍未明顯改善。而另一個發現則令人大大驚訝而不解：
- 從 Google 特定的 IPv4 網段無法查詢到交大網域，但只要透過 IPv6 就一切順利。而這個有問題的 IPv4 網段，也包括 Google Apps Toolbox 和 Google Apps 的認證主機！（關於Google Public DNS 全球各地不同網段）
於是，計網中心將所有來自 Google 的 DNS 查詢重導至一部支援 IPv6 的 DNS 伺服器，並作為建築所的 slave server，更新設定後，再度經過全球 DNS 快取資料更新約莫一小時後，終於！終於在 2/9 這天，建築所信箱的收發信功能全面恢復正常！
雖然解決了燃眉之急，但不算是漂亮的方案，也不算是水落石出，只是個有效的應變措施（Ashik 說這是 a clever workaround），問題仍然存在。交大計網中心會持續調查、並向 Google 反應這個現象、搞清楚原因。透過這次事件，連帶對於 DNS 和 mail routing 的運作方式更加了解，也知道 email 掉信是極有可能發生的，就當作是收穫吧。
感謝交大計網中心（一直習慣用舊名稱，現在稱作「資訊技術服務中心」）的蘇俊憲先生的大力協助，他才是背後的大功臣！當然還要感謝遠在 Google 總部客服中心的 Ashik！
Thank you, Ashik, a staff from Google for Work Support Team, for your prompt replies and great support to help resolving the issue.
留言
張貼留言