Hlavní navigace

Odklánění DNS provozu jako bonus

15. 7. 2012 19:11 (aktualizováno) Ondřej Caletka

Mé stávající domácí připojení se nějak pokazilo a poslední měsíc jsem byl zcela odkázán na U:fonův hobby Internet. Což není tak špatné, jak to zní, ale začal jsem se poohlížet po řešení trvalejšího charakteru. Narazil jsem na nabídku společnosti InternetHome, s. r. o. vlastněné Telefónicou, nabízející v mém okolí bezdrátové připojení na bázi 5 GHz Wi-Fi. Nabízený tarif 5 Mbps za 350 Kč měsíčně mě zaujal, na domácí linku s občasným provozem to dostačuje.

Po prvotních komplikacích, kdy v domluvený den instalace technik volal, že mu nedorazilo zboží, a že musí přijít jindy, jsem se nakonec dočkal a přípojka mi byla zprovozněna, shodou okolností přesně v den, kdy Telefónika začala nabízet IPv6 na xDSL přípojkách. Že zde nebude k dispozici IPv6 mě nepřekvapilo, nenechal jsem se zaskočit ani tím, že za veřejnou IPv4 adresu se doplácí 50 Kč měsíčně. Jednoduše místní Wi-Fi provider je jiná liga, než celostátní kolos provozující xDSL, byť mají oba stejného majitele.

Bohužel se ukázalo, že připojení nefunguje tak, jak bych si představoval. Ping na IP adresu fungoval bez problému, rychlost je také přesně podle smluvních podmínek a doba odezvy průměrně 30 milisekund. Můj DNS server však s novým připojením spolupracovat nechtěl. U domén, které nemají DNSSEC, jako třeba google.com, server odpovídal nesmysly, jako třeba tento:

# dig google.com @127.0.0.1

; <<>> DiG 9.7.3 <<>> google.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46690
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; Query time: 479 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul  2 16:46:42 2012
;; MSG SIZE  rcvd: 28

Ano, vidíte správně. Podle této odpovědi jméno google.com v DNS existuje, ale není k němu přiřazená žádná IPv4 adresa. U domén s DNSSEC byla situace jednodušší, podvržené DNS záznamy nebylo možné validovat a server tak vrátil obligátní stavový kód SERVFAIL.

Nejdříve jsem myslel, že jde o nějaké problémy s MTU, to se však nepotvrdilo. Celé se to chovalo záhadně. Nejzajímavější bylo, že bind a unbound vykazovaly pro stejná jména rozdílné chování.  Nakonec se ukázalo, že jde o stejný problém, jaký se kdysi řešil na místím fóru. Totiž že veškerý provoz mířící na UDP port 53 je přesměrován na rekurzivní DNS server poskytovatele!

# dig nebezi.cz aaaa @254.254.254.254

; <> DiG 9.8.1 <> nebezi.cz aaaa @254.254.254.254
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38843
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nebezi.cz.                     IN      AAAA

;; ANSWER SECTION:
nebezi.cz.              3600    IN      AAAA    2a01:430:d:0:2cc:9eff:fe24:7e1a

;; Query time: 363 msec
;; SERVER: 254.254.254.254#53(254.254.254.254)
;; WHEN: Mon Jul  2 17:14:21 2012
;; MSG SIZE  rcvd: 55

Jak je vidět z předchozího výpisu, nedělal mému připojení problém ani vydávat se za adresu ze třídy E, které jsou jinak už na doživotí odsouzeny k „budoucímu použítí“. A rekurzivní DNS servery bohužel těžce nesou, jsou-li jejich autoritativní dotazy odchyceny a obslouženy rekurzivním serverem.

Provizorní řešení problému spočívá v rekonfiguraci DNS serveru, aby namísto řešení dotazů všechny přeposílal na jiný rekurzivní server, jehož adresu si můžeme vymyslet (i když lepší je použít adresu skutečného DNS serveru, aby fungovaly i dotazy po TCP, se kterými ISP nijak nemanipuluje). V případě unbounda je možné použít konfigurační volbu tcp-upstream, která zakáže použití UDP protokolu; tím se však DNS značně zpomalí, kvůli režii navazování a rušení TCP spojení. Poslední možností, pokud disponujete vlastním serverem, je spustit kdesi v Internetu vlastní DNS resolver na jiném UDP portu, takovém, který není manipulován a na něj následně přeposílat veškerý provoz. (To všechno hlavně proto, že při přeposílání dotazů na server BIND < 9.9.0 a zapnuté validaci není možné validovat některé žolíkové domény)

Správné řešení však spočívá v reklamaci nefunkčního připojení u ISP. Připravte se na to, že pracovník na první vlně technické podpory toho ví o fungování služby zpravidla méně než vy (čest výjimkám), takže budete pracně vysvětlovat, co že máte vlastně za problém. V mém případě pracovník poměrně rychle pochopil, že nemluví řečí mého kmene a slíbil předání informace technikovi, který se mi ozve a nastavení prověří. Po přibližně dvaceti hodinách se technik ozval. Byla s ním vcelku rozumná řeč. Kdyby to byl pan exministr Kocourek, vysvětlil by mi, že provoz na portu udp/53 odklánějí (směrem na adresu 8.8.8.8) od problémů, které vznikaly v souvislosti s tím, že jejich klienti měli špatně nastavenou adresu DNS serveru. I když přesně nechápal, jakým způsobem mě takovéto odklánění poškozuje, byl velmi ochotný nastavit pro mě výjimku na firewallu, který odklánění alias NATování provádí. Po chvíli se mu to podařit nastavilo a DNS provoz z mé přípojky tedy již není odkláněn a DNS server funguje, jak má. Příběh zde končí, prozatím happyendem.

Co ze zápisku plyne? Pokusím se to shrnout v několika bodech, i když se tím neubráním jistému zobecnění:

  • U lokálního ISP můžete očekávat poměrně neortodoxní řešení, která však většině uživatelů fungují.
  • Není velký problém dovolat se přímo na technika, který síť spravuje. Ten je ochoten vyhovět požadavkům zadaným ústně, aniž by k tomu potřeboval milion papírů a razítek a nechal si za podobnou službu účtovat měsíční příplatek.
  • Na druhou stranu, u velkého ISP máte naději, že služby budou na jisté úrovni, ověřené tisíci uživatelů a podobná neortodoxní řešení (tedy, až na již odkazovaný problém u T-Mobile Internet 4G) pravděpodobně neuvidíte. Takže i když se technikovi jistě tak snadno nedovoláte, zase ho pravděpodobně nebudete potřebovat.