Dotaz: Výpadky připojení k internetu zřejmě způsobené bind9

[Tomáš Kozák]

Dobrý den,

už delší čas řeším zvláštní problém v síti UPC. Na svém MacBook Pro (El Capitan) mám pomocí hoebrew nainstalovaný bind, který slouží zároveň jako cache DNS a jako DNS pro domény 1. řádu localhost a dev (pro vývoj web aplikací).

Nedávno jsem také přidal loopback alias 172.0.0.1, aby byl server dostupný i z virtualizovaných Windows přes Parallels Desktop.

Vše funguje perfektně, pokud jsem připojen k wi-fi přes jakýkoliv jiný AP než AP od UPC, je vše bez problémů. Pokud se však připojím k UPC modemu (vyzkoušeny 3 modemy různých uživatelů), pak čas od času připojení vypadne. Výpadky jsou cca po 30 minutách (ale nepravidelně). K wifi jsem stále připojen, na router se připojím, do adminu se dostanu.

Tento problém nenastává pokud odstraním IP adresy lokálního DNS z nastavení připojení a tím využívám DNS UPC. Nicméně během výpadku nepingnu ani IP adresu (77.75.79.39 - seznam.cz). Podle mne tedy nesouvisí se samotným překladem adresy.

Pokud nechci čekat na "konec" výpadku, stačí vypnout a zapnout wifi v OS X.

Bohužel mé znalosti jsou nedostatečné k tomu, abych byl schopný problém diagnostikovat. Takto nakonfigurovaný bind už mám 2 roky a nikdy jsem výpadky nezaznamenal dokud jsem se nepřestěhoval a nezačal využívat UPC, protože zde jiná možnost není.

Předem děkuji za reakce. Níže přikládám pro začátek config. Log je prázdný.

/usr/local/etc/named.conf

include "/usr/local/etc/rndc.key";

controls {
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; } keys { "rndc-key"; };
};

acl goodclients {
    192.168.0.0/24;       # LAN
    10.211.55.0/24;      # Parallels
    localhost;
    localnets;
};

options {
  directory "/usr/local/var/named";

  recursion yes;
  allow-query { goodclients; };

  forwarders {
    217.31.204.130; # Nic.cz DNS
    193.29.206.206; # Nic.cz DNS
    8.8.8.8;        # Google Public DNS
    8.8.4.4;        # Google Public DNS
    208.67.222.222; # OpenDNS.org
    208.67.220.220; # OpenDNS.org
  };

  forward first;

  dnssec-enable no; 
  dnssec-validation no;

  auth-nxdomain no;

  listen-on-v6 { any; };

};

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

zone "localhost" {
  type master;
  file "localhost.zone";
};

zone "dev" {
  type master;
  file "localhost.zone";
}; 

zone "0.0.127.in-addr.arpa" {
  type master;
  file "named.local";
};

logging {
  category default {
    _default_log;
  };

  channel _default_log  {
    file "/usr/local/var/log/named/named.log";
    severity info;
    #severity debug 10;
    print-category yes;
    print-time yes;
    print-severity yes;
  };
};

Odpovědi

[NN]

Podle popisu mas problemy s konektivitou. Resil bych to s poskytovatelem.

[Hapi]

S tím souhlasím. Nicméně to dělá jen pokud použiji své DNS. A nejedná se jen o mojí přípojku, ale jde o tři různé přípojky v různých částech Brna. Čili jde o globální problém sovisející s mou konfigurací. Jiná zařízení problém nemají. Během výpadku internet na mobilu (iPhone 5) normálně funguje a jiný notebook také.

A jistě znáš technickou podporu těchto firem. Baví se s tebou jak s někým, kdo neumí počítač ani zapnout. Ve finále ti řeknou, že problém není na jejich straně. Ať používáš jejich DNS, že jen tak ti zaručí, že to bude fungovat. A když si vyškemráš návštěvu technika, tak zaplatíš za stejnou informaci s tím rozdílem, že ti jí řekne do očí.

Tohle je prostě problém v mé konfiguraci vs jejich modemy nebo síť. A vsadím se, že to bude dělat všude v jejich síti v rámci ČR. Protože jestli to dělá v Židenicích, na Veveří a v Obřanech a pokaždé na jiném modemu, pak se nejedná jen o mou přípojku. Tohle snad ani není jedna větev.

[Hapi]

Jak jsem odtušil. Žádné problémy u mě nevidí - to by mě nenapadlo. Zapne mi na deset dní podrobnou diagnostiku - a nejspíš zjistí velký kulový. Já si mam zapisovat časy výpadků - tak být normální zákazník, tak bych si co 20 min mohl psát tužkou do notýsku. A po třech výpadcích mi vymění modem :D Tak to aby tu za hodinu byli... A můžou vyměnit půlku modemů v republice. :D

[NN]

Podivej pises, ze na router vidis, dostanes se na rozhrani pro spravu, ale IP adresu 77.75.79.39 si nepingnes => problem za routrem. To nema s DNS nic spolecneho..

[logik]

Ještě by to mohl bejt problém s routováním, že není dobře nastavená default gateway, takže není vidět nic mimo lokální síť. Až ti to vypadne znova, tak si to zkontroluj, utilitka route

[Hapi]

Jop, dobrý nápad, zkusím. Díky

[Hapi]

Ano, myslim si to stejne. Nicmene, proc to dela, jen pokud to lokalni DNS pouzivam? Chapu, ze pokud se dostanu do admina routeru, pak je pripojeni k routeru OK. Taky pokud pingam IP, je DNS ze hry.

Me spis napadlo, jestli to DNS za to nemuze sekundarne. Posle nejaky packet, ktery se necemu po ceste nelibi? Ja nejsem sitar, ale programator, takze nevim. Snazil jsem se vyloucit vse. Taky to dela jen s mym notebookem. Kvůli vypadkum si poustim Apple Radio na mobilu a hraje mi tu cca 16 hod denne. Takze pokud by to vyadavalo globalne. Pak bych si toho vsiml okamzite. Vypadky jsou tak 5 min pokud rucne nerestartuju adapter na notebooku.

Navic chapu, ze oni ty modemy pujcuji dal. Ani ja nemel novej kus. Ale byla by velka nahoda, kdyby to delaly tri ruzne modemy, tri ruzne lokality a tri ruzne ucastnicke smlouvy.

Jedine logicke vysetleni je, ze za to muze muj notebook. Ale jak?

[MadCatX]

Nemůže mít UPC nějakou (skrytou) politiku ohledně nemožnosti provozu vlastního DNS v jejich síti? FW routeru by mohl být nějak ohnutý, aby odstřelil klienta, co se tváří jako DNS server. Máš možnost spustit ten BIND na jiném stroji v síti podívat se, jak se spojení chová tam?

[Hapi]

Bohužel momentálně ne. mám tu starej Thinkpad, ale musel bych k němu najít adaptér a přeinstalovat. Takže až bude čas. To co píšeš nezní nereálně, ale nezdá se mi, že by to zas dělal tak sporadicky. Navíc logika takového počínání mi uniká. Pochopil bych, kdyby něco blokovali kvůli sdílení obsahu nebo tak. Ale čemu by vadilo DNS? Naopak. Lepší by bylo, kdyby ho měli v routerech a šetřili si tak prostředky sítě.

Už jsem i přemýšlel nad VPN a bindu na serveru. Bohužel rád cestuji a pracuji ve vlaku, jenže repeaterů se u ČD asi nikdy nedočkáme. A /etc/hosts řešení neřešení, to bych tam mel stovky záznamů.

[dustin]

Bind na vnitřní síti připojené přes UPC běží ok, používáme spoustu let v lokalitách Praha a Plzeň.

Tipuji si, že problém bude nějaká blbost, kterou autor přehlédl a s DNS to nebude mít vůbec nic společného...

[Hapi]

No jó, to je tak vždycky, tomu se nebránim. :D V IT je to běžná praxe, čím větší blbost, tím delší čas k její odhalení. Kolik života už mi řešení takových blbostí vzalo :) Ale i tato informace je užitečná. A nejvíc mě vytočí, až vydá Apple aktualizaci a já zjistím, že to bylo chybou v systému. :D :D

[dustin]

To není nic proti tobě, to je prostě život

I ta chyba v OS (třeba v "libc" pro OSX) to může být, i když na to už by asi někdo narazil. Jseš si jistý, že zapnutím/vypnutím toho bindu se nemění i něco jiného?

[Hapi]

Neboj, jsem programátor. Dovolil bych si upravit známou repliku "K programování je zapotřebí lep ocelová a zadek olověný, jak se česky říká - Sic flajš" !" :D

Já ten bind ani nevypínám. Jen odstraním z nastavení DNS IP loopback aliasu. Ten alias vliv určitě nemá. Mám ho tam teprve týden. A dělalo to i před tím.

[Marek Sulik]

A akú máš IPčku pri pripojení na WIFI od UPC a akú pri inom AP.

Nemáš tam kolíziu s touto

10.211.55.0/24; # Parallels

[Hapi]

V LAN 192.xxx.xxx.xxx a WAN 70.xxx.xxx.xxx - a to by (snad) nemělo mít vliv... Nevšiml jsem si, že by něco v jejich síti začínalo 10. A kolize IP adres by snad nebyla tak nahodilá.

[nelson]

Pravděpodobně to nesouvisí s problémem, ale nastavit si na loopback adresu 172.0.0.1/cokoliv mně nepřijde úplně ideální 172.0.0.0/12 není blok rezervovaný pro speciální účely, ale normální internetová adresa, konkrétně pŕidělena pro AT&T.

[Hapi]

Díky za upozornění... no stackoverflow se věřit moc nedá :D zkopíroval jsem to bez rozmyslu včetně IP, když jsem hledal jak ho na OS X nastavit permanentně.

[Hapi]

Vypozoroval jsem, že občas nepadnou všechna spojení. Dnes jsem měl skype call a hovor běžel. Včera pspl import na server a dobehlo to a nic jinyho nejelo...

Nemuze se jednat o nejaky limit na pocet spojeni? Zde uz tapu, da se ten limit nejak zjistit? Trosku mi to pripomina limit o prvnich verzi Win XP, kde byl default limit 10 a v registrech to bylo potreba zvysit, protoze obyc torrent klient vycerpal limit a nic jinyho neslo.

Tech sluzeb co vyuzivaj pripojeni tu je dost. Treba bind obnovuje cache a vyzere spojeni?

[Hapi]

nebo spis limit na tom modemu/routeru

[Filip Jirsák]

Pokud ten modem dělá NAT (nebo je tam příliš vlezlý firewall), potřebuje si pamatovat jednotlivá spojení – a pak tam bude nějaký limit na počet spojení (a v hloupém zařízení ten limit může být nízký).

DNS server by ale neměl „obnovovat cache“ – pokud nějaký záznam je příliš starý, ta se z cache odstraní, ale nenačítá se znova. Záznamy se načítají až v okamžiku, pokud je někdo požaduje (a pokud nejsou v cache). Navíc DNS dotazy se dělají přes protokol UDP (pokud to jde), který „spojení“ nezná. Ale třeba NAT si musí pamatovat, odkud přišel UDP požadavek, aby věděl, kam poslat případnou odpověď, takže si jakousi „tabulku spojení“ musí vytvářet i pro UDP. U té je to ještě horší, než se skutečnými spojeními přes TCP, protože není jasné, kdy se spojení ukončí – takže jediná možnost je čekat na timeout.

[Hapi]

Děkuji, to dává smysl. Firewall jsem na routeru (TC7200) vypnul, ale s tím NAT by problém bát mohl. Nikde jsem nevygooglil žádné konkrétní hodnoty. Ale asi to nebude žádný kočár. Zkusím se ještě probrat tcpdumpem, jestli se třeba nenavazují nějaká zbytečná spojení, nebo to na něco nečeký dlouho.

Tady už opravdu tápu. Vyřešil by se problém přenastavením na bridge a použití druhéhou routeru? NAT tam přeci musí běžet též ne? Myslím na tom modemu.

[Filip Jirsák]

Pokud ten modem nastavíte do bridge režimu, bude jen předávat pakety z jedné strany na druhou a opačně, nebude do nich nijak zasahovat, tedy ani dělat NAT. NAT si pak musíte udělat na tom dalším routeru (pokud dostáváte jen jednu IP adresu a máte více zařízení).

[pavlix]

Hlavně bych si při tom srovnávání s bindem a bez bindu dával pozor na skutečnou dynamicky vytvářenou konfiguraci, která se propíše do /etc/resolv.conf nebo jak to na OS X mají. S tím pak člověk může experimentovat i přímo, navíc můžeš bind testovat programem dig, tak můžeš souvislost velmi rychle potvrdit nebo vyvrátit. Osobně bych sázel spíše na to vyvrácení.

Jinak ping doporučuju pouštět jako ping -n, ať nečekáš na zpětný překlad. To stejné platí pro spoustu jiných toolů, které se nedokážou dobře vypořádat s problémy s překladem jmen.

Pokud nechci čekat na "konec" výpadku, stačí vypnout a zapnout wifi v OS X.

Pak se nejspíše vůbec nejedná o výpadek.