很長一段時間以來，我在家庭網路上遇到有關 YouTube 應用程式的煩人問題。當我打開應用程式時，該應用程式經常顯示「檢查您的網路連線」訊息，而網路的其餘部分運作正常。奇怪的是，只有我的 Android 手機和我妻子的 iPhone 上的 YouTube 應用程式才會出現這種情況。同時，透過 YouTube 網站的存取工作完美（從兩部手機），同樣適用於從我的 PC 或筆記型電腦以及網路的其餘部分存取它。這實際上只是透過應用程式存取 YouTube。
我在 serverfault 上發布了我的問題，因為我堅信它一定與我幾個月前在我的 Banana Pi 上安裝的 bind9 DNS 伺服器有關。我基本上只是為了輕鬆解析本地網路內的主機名稱而設定它。因此，DNS 只是設定為轉送 DNS，它將所有無法自行解析的主機名稱轉送到 Google 的伺服器 8.8.8.8 和 8.8.4.4。
我在網路或 DNS 方面沒有太多經驗，但我了解基礎知識。但現在我已經到了不知道該往哪個方向進一步調查的地步。
我嘗試在 DNS 配置中來回設定一些選項，但沒有成功。當我設定路由器透過 DHCP 發送 8.8.8.8 作為 DNS 伺服器時，該應用程式可以在我的手機上運行，一切正常。當我將其更改回發送本地 DNS 時，應用程式失敗。請記住：所有其他網站甚至 Google 服務都可以繼續運作。
這是我的bind9配置，如果有任何幫助的話：
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
8.8.8.8;
8.8.4.4;
};
forward first;
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
query-source address * port 53;
query-source-v6 address * port 53;
allow-query { any; };
allow-query-cache { any; };
allow-recursion { any; };
response-policy { zone "overrides"; };
cleaning-interval 60;
};
誰能幫我解決這個問題，並給我一個線索，讓我進一步調查？是否只有在使用 YouTube 應用程式或 Google 封鎖的某些服務時才會涉及其他連接埠？或者只是我的 DNS 配置對 99.999% 的網路正確，而 YouTube 需要一些額外的處理？
請幫忙。任何建議都將受到高度讚賞！
編輯：
忘了提及，我最近注意到我www.googleapis.com也無法從智慧型手機存取。主機名稱根本無法在瀏覽器 (Chrome) 中解析，簡單的 ping 或 nslookup 也會失敗。我的電腦或筆記型電腦上一切都恢復正常了。我之所以想到這一點，是因為我在媒體中心 (Kodi) 上使用了 YouTube 插件，該插件host or service unknown在嘗試訪問 www.googleapis.com 時也出現故障並抱怨。
可能有一些相關性嗎？希望這有助於縮小問題範圍。
編輯2： 自從改變了向前綁定中的選項
forward first;
到
forward only;
YouTube 應用程式已經恢復運行幾天了，到目前為止沒有任何明顯的中斷。所以我認為這個問題暫時解決了。
答案1
注意：根據OP的評論，使用forward only而不是forward first似乎已經解決了這個問題。
關於 YouTube 應用程序，傳聞證據似乎表明它對連接逾時可能很挑剔，尤其是 BIND。據猜測，解決方案有時會比 YouTube 應用程式的編碼（相當糟糕）花費的時間更長，並且它只是簡單地決定連接不可用。
就我個人而言，我首先建議嘗試使用 Google 以外的轉發器——我在 BIND 中使用它們時運氣不佳。當我使用轉發器時，我總是退回到我的 ISP 伺服器或其他公共 DNS 選項。
如果更改轉發器沒有幫助，可以考慮的另一個選擇是透過新增根提示區域來執行自己的解決方案，例如：
zone "." {
type hint;
file "named.root";
};
你會添加這個後你的options街區。透過這種設置，您可以註解掉轉發器並繞過它們可能導致的任何延遲或解析問題。
可以說，在某些方面，這種設定可能比轉發名稱伺服器慢，但我發現它非常適合我自己的設定（我很少遇到 YouTube 應用程式問題）。
至於配置第二個選項的具體細節，網路上應該有很多教程，但重點介紹一下：
您需要取得一份命名.root提示檔案（或其某些變體）透過ftp.internic.net。
您需要將
allow-recursion條目設定為例如localnets。您可能需要做一些研究才能找到 的正確位置
named.root，因為它的位置可能因發行版而異。