Błąd sieci w aplikacji YouTube podczas korzystania z sieci domowej

Od dłuższego czasu mam do czynienia z irytującym problemem dotyczącym aplikacji YouTube podczas mojej domowej sieci. Aplikacja często wyświetla komunikat „sprawdź połączenie sieciowe”, gdy ją otwieram, gdy reszta Internetu działa dobrze. Dziwne jest to, że dzieje się TYLKO z aplikacją YouTube na moim telefonie z Androidem i iPhonie mojej żony. Jednocześnie dostęp za pośrednictwem strony internetowej YouTube działa bezbłędnie (z obu telefonów), to samo dotyczy dostępu z mojego komputera lub laptopa i pozostałej części Internetu. To naprawdę tylko YouTube za pośrednictwem aplikacji.

Wysłałem swój problem tutaj na błąd serwera, ponieważ mocno wierzę, że musi to mieć coś wspólnego z serwerem DNS bind9, który zainstalowałem kilka miesięcy temu na moim Banana Pi. Zasadniczo po prostu go skonfigurowałem, aby wygodnie rozpoznawać nazwy hostów w mojej sieci lokalnej. DNS jest więc skonfigurowany jako DNS przekierowujący, który przekazuje wszystkie nazwy hostów, których nie może rozpoznać na serwerach Google 8.8.8.8 i 8.8.4.4.

Nie mam dużego doświadczenia w zakresie sieci lub DNS, ale znam podstawy. Ale teraz doszedłem do punktu, w którym nie wiem, w jakim kierunku należy dalej badać.

Próbowałem ustawić kilka opcji w konfiguracji DNS tam iz powrotem, ale bezskutecznie. Po skonfigurowaniu routera do wysyłania 8.8.8.8 jako serwera DNS przez DHCP aplikacja działa na moim telefonie i wszystko jest w porządku. Gdy zmienię go z powrotem na wysyłanie lokalnego DNS, aplikacja nie działa. Pamiętaj: WSZYSTKIE inne strony internetowe, a nawet usługi Google nadal działają.

To jest moja konfiguracja bind9, jeśli to pomoże:

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;
};

Czy ktoś może mi w tym pomóc i dać mi wskazówkę, gdzie mogę dalej badać? Czy mogą być zaangażowane inne porty tylko podczas korzystania z aplikacji YouTube lub niektórych usług blokowanych przez Google? A może po prostu mój DNS jest skonfigurowany poprawnie dla 99,999% internetu, a YouTube wymaga dodatkowego leczenia?

Proszę pomóż. Wszelkie porady są mile widziane!

EDYCJA: Zapomniałem wspomnieć, że ostatnio zauważyłem, że nie mogę również uzyskać dostępu www.googleapis.comze swojego smartfona. Nazwa hosta po prostu nie rozwiązuje się w przeglądarce (Chrome), zwykły ping lub nslookup również się nie udaje. Wszystko znów jest w porządku na moim komputerze lub laptopie. Zrozumiałem to, ponieważ korzystam z wtyczki YouTube w moim centrum medialnym (Kodi), która również popsuła się i narzeka host or service unknownpodczas próby uzyskania dostępu do www.googleapis.com.

Czy może istnieć jakaś korelacja? Mam nadzieję, że pomoże to w zawężeniu problemu.

EDYCJA 2: Od czasu zmiany opcji przekazywania w powiązaniu z

forward first;

do

forward only;

aplikacja YouTube znów działa od kilku dni bez zauważalnych przerw. Dlatego uważam, że problem został na razie rozwiązany.

Uwaga: w przypadku komentarzy PO, użycie forward onlyzamiast forward firstwydaje się, że rozwiązało ten problem.

Jeśli chodzi o aplikację YouTube, anegdotyczne dowody wydają się sugerować, że może być wybredna w odniesieniu do limitów czasu połączenia, szczególnie w przypadku BIND. Domyślamy się, że czasami rozwiązanie trwa dłużej niż (raczej słabe) kodowanie kont aplikacji YouTube i po prostu stwierdza, że ​​połączenie jest niedostępne.

Osobiście najpierw zasugerowałem wypróbowanie spedytorów innych niż Google - miałem z nimi pecha w BIND. Kiedy korzystałem z usług przesyłania dalej, zawsze wracałem do moich serwerów ISP lub innych publicznych opcji DNS .

Jeśli zmiana usług przesyłania dalej nie pomaga, inną opcją do rozważenia jest wykonanie własnej rozdzielczości przez dodanie strefy wskazówek dotyczących roota, np .:

zone "." {
     type hint;
     file "named.root";
};

Dodałbyś to po swoim optionsbloku. Dzięki tego rodzaju konfiguracji możesz komentować usługi przesyłania dalej i omijać wszelkie problemy związane z opóźnieniami lub rozwiązywaniem, które mogą powodować.

Prawdopodobnie pod pewnymi względami jest to potencjalnie wolniejsza konfiguracja niż serwer nazw, ale okazało się, że działa dobrze w przypadku mojej własnej konfiguracji (rzadko mam problemy z aplikacją YouTube).

Jeśli chodzi o szczegółowe informacje na temat konfigurowania drugiej opcji, powinno być wiele samouczków sieciowych, ale jako najważniejsze:

• Będziesz musiał pobrać kopię pliku wskazówek named.root (lub jego odmianę) za pośrednictwem ftp.internic.net .

• Będziesz chciał ustawić swój allow-recursionwpis na coś takiego jak np localnets.

• Być może trzeba będzie przeprowadzić trochę badań, aby znaleźć odpowiednią lokalizację named.root, ponieważ jej położenie może się różnić w zależności od dystrybucji.