很长一段时间以来，我在使用家庭网络时遇到了一个与 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 也失败了。在我的 PC 或笔记本电脑上，一切都恢复正常。我之所以能解决这个问题，是因为我在媒体中心 (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 应用的问题）。
至于配置第二个选项的具体细节，应该有很多网络教程，但重点是：