Odklánění DNS provozu jako bonus
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.
-
technik isp (neregistrovaný)
Zdravim, resil jsem pripojku na jednom nejmenovanem mestskem urade, kde maji hlavni linku od nas a od O2 maji pres xdsl zalohu, mikrotik jim resi pripady vypadku a preklopi provoz. Jake bylo zdeseni, kdy jsme meli planovanou odstavku kvuli upgradu trasy a "jim to nejelo". Nakonec se zjistilo, ze ne ze O2 odklani dns provoz, ale blokuji cokoliv jineho, takze meli nastavene nase dns a nejeli, pridal jsem i dns O2 a ejhle internet se rozjel, tomuto rikam pekna prasarna.
-
Pepa reloaded (neregistrovaný)
ad 2: Nerozumim, muzu poprosit o vysvetleni... Vas klient - mestsky urad (MU) - mel nastavene adresy DNS serveru na Vase DNS servery. Od tech bych cekal, ze budou odpovidat jen, pokud budou dostavat dotazy z Vasi site (napr. onen MU), ale nebudou odpovidat na dotazy z venku (treba z O2 site). Pak je jasne, ze po preklopeni na zalozni linku od O2 ztratily na MU DNS odpovedi a O2 za to vubec nemuze (nemusi nic blokovat nebo odklanet).
Je to tak nebo jsem to spatne pochopil? -
Ondřej Caletka (neregistrovaný)
[3.] Taky to tak chápu. V xDSL síti TO2 jsem nikdy nezaznamenal jakoukoli manipulaci s DNS provozem, tedy kromě toho, že jejich DNS servery některá jména správně neresolvovaly v rámci ochrany klientů před dětským pornem. Ale to se netýkalo síťového provozu a bylo jen na uživatelích, zda si zvolí operátorem doporučený DNS server, nebo jakýkoli jiný, který podobnou ochranou netrpí.
-
Franta (neregistrovaný)
Ad „ž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.“
Tak tohle je vážně kokotismus – kvůli neschopným uživatelům rozbijí připojení všem ostatním? Tuhle politiku „přizpůsobování se blbcům“ bych rozhodně nepodporoval.
Ad „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á.“
Technika chválím, kéž by takový přístup měli i jinde. Nicméně bych jim ještě napsal, ať to hodí někam do FAQ – až příště někdo jiný narazí na záhadné chování DNS, ať ví, o co jde a že se to dá takhle řešit.
A asi nejlepší by bylo trochu kastovat uživatele – do formuláře jim dát nějakou kontrolní otázku, která by vyselektovala BFU a těm by se pak daly dělat takové odporné hacky, a ostatním by fungoval normální internet (a nesli by odpovědnost za to, že si správně nastaví DNS).
-
Pepa reloaded (neregistrovaný)
ad [6]: Ale odklaneni DNS provozu (nastesti) znefunkcni DNSSEC. A o tom to je - lze primo demonstrovat, ze obavy meho poskytovatele o me dusevni zdravi a cistotu me duse porusuji zakladni funkcionality chodu Internetu a taktez nase zakony. /dle meho nazoru/
Nevim, jak je takove odklaneni bezne u velkych poskytovatelu, ale me T-Mobile uznal moje argumenty a pomerne rychle jej ze sve site odstranil. (priznam, byl jsem docela prekvapen)
Podle jejich vysvetleni byl odklon DNS dotazu nejakym vedlejsim efektem jineho provozu. Zmenou nastaveni firmwaru se to pry odstranilo.Pokud ISP svym klientum nabidne a treba i defaultne prednastavi takto upraveny DNS (ci jiny) server - budiz. Nekomu to i snad muze vyhovovat. Ale sit ma zustat neutralni!!!
-
Pavel Šimerda (neregistrovaný)
[6] odklon SMTP provozu dělají ISP z důvodu možných problémů s blacklisty, které ovlivňují i jiné uživatele než ty problémové. Neříkám, jestli je to v tom kterém případě nejlepší řešení, ale každopádně je to opodstatněný krok. To stejné se o DNS říct nedá, tam chybně nastavené DNS ovlivní pouze toho, kdo ho má chybně nastavené.
-
Majkl (neregistrovaný)
ad [8] odklon SMTP s odkazováním na boj proti virům/spamům je chvályhodný, ale musí se dělat správně (trasnsparentní filtrování), což 99% případů není. A má to stejné dopady jako u toho DNS, ale ještě víc zákeřnější od dob, co se používá SFP, domain signing, tak takového odklonění často znamená, že pošta jde jinudy než má (meodejde k odresátu ze serveru odpovídajícímu SFP, neprojde podepisujícím serverem) a končí jako spam.
Obzvláště je vtipné, pokud někdo odkloní spojení, kde jsou jako příjemnce neveřejné email adresy (např některé IS pojištoven takto fungují pro polní agenty, že data z noťasu posílají přímo na smtp server IS a email adresa není dostupná zvenku.
Nejhorší je, že někteří ISPíci to nechtějí pochopit, že tohle jako zákazník nechci a vnmám to jako únos spojení, což je něco, an co pamatuje trestní zákoník. -
Ondřej Caletka (neregistrovaný)
[9] Transparentní filtrování, že je správně? Právě takové chování by mi bylo nejvíce nepříjemné. To radši zablokovat komplet přístup na port 25 (a případně udělovat výjimky). Odesílat přímo e-maily z domácích adres je beztak nepoužitelné, spousta příjemců poštu od domácích přípojek nepřijímá, nebo ještě hůře v tichosti zahodí (vlastní zkušenost).
Pro předávání pošty relay serveru je už dlouhou dobu vyhrazen port 587, takže drtivou většinu legitimních uživatelů zaříznutí portu 25 neovlivní. Nehledě na to, že lidé dnes posílají poštu přes webmail.
-
Franta (neregistrovaný)
[8] To je sice oprávněný argument, ale má se to řešit zablokováním na firewallu a poskytnutím vlastního SMTP(S) serveru – nikoli nějakým pokoutným přesměrováním/odklonem (ve skutečnosti MITM útok), kdy si uživatel myslí, že komunikuje se smtp.někdo-venku.cz a ve skutečnosti (v důsledku přesměrování IP) komunikuje se smtp.jeho-zaprděný-isp.cz. Z toho jsou akorát problémy a nedorozumění. A vůbec největší ksindl je, když nějaká rádoby chytrá krabička (klidně i od věhlasného výrobce) strká rypák do příkazů daného protokolu (třeba SMTP nebo FTP) a občas nějaké zahodí nebo pozmění. To je pak „radost“ ladit a odhalovat takové chyby :-/
-
Matas (neregistrovaný)
Zdravim, staram se o jednu mensi sit a napriklad co se SMTP(/S) tyce tak sme byli donuceni (mimo nase servery ktere maji zakaznici k dispozici) k blokaci portu nejen 25 ale i 465 (ktery uz by se pouzivat nemel a v prislusnem RFC je oznacen jako obsolete), ucinili jsme tak po nekolika vetsich problemech s odesilanim (octnuli jsme se na blacklistech). Co se DNS tyce, presmerovani v nekterych castech site (bohuzel) provozujem take (jinak v ramci site validujeme pres DNSsec), rozumim tomu ze to muze byt chapano jako poruseni sitove neutrality, ale pral bych opravdu si zkusit resit se zakazniky ty problemy co my... clovek potom rezignuje na blbost a odkloneni je opravdu mensi zlo, s tim ze pokud nekdo da vedet ze to neni v poradku udela se bez problemu vyjimka nebo se to zrusi...
-
User zase (neregistrovaný)
Když tak nad tím přemýšlím, tak tomu preventivnímu zablokování SMTP nerozumím...
Nechcete se ocitnout na blacklistu, aby nenastal stav, že z Vaší sítě nepůjde odeslat mail. A bloknete port 25, takže to zablokujete Vy sami a raději hned. :-)
Ale možná je tam komunikační šum... -
admin (neregistrovaný)
[14] Stejné řešení jsem aplikoval v jedné síti se spoustou (tisíce) uživatelů za NATem, z toho prostého důvodu že uživatelé, kteří jsou donucení používat oficiální SMTP server (kde musejí povinně použít pro odeslání každého mailu jméno a heslo) jsou mnohem lépe kontrolovatelní než ti, kteří si přes NAT posílají maily sami. Dokud to totiž mohli dělat, stačil jediný zavirovaný počítač (rozesílající spam) k tomu aby všem uživatelům přestaly odcházet maily (sdílená IP adresa se dostala na různé blacklisty). To nebylo z dlouhodobého hlediska únosné. Proto byl port 25 pro odchozí provoz zablokován, tím byly různé spamovací viry odstaveny a je klid. Bylo sice nutno uživatele informovat o nutnosti používat oficiální SMTP server (který má rozumně nastavená pravidla proti spamu) což vygenerovalo krátkodobě dost práce, ale z dlouhodobého hlediska se to jednoznačně vyplatilo.
-
mukrin (neregistrovaný)
Jeden místní vcelku velký ISP má problém se SMTP vyřešen podle mě vcelku dobře...
Port je normálně otevřen, ale je monitorován. V případě, že začne nějaký klient spamovat (práh nebo metodu netuším), je mu během chvíle zablokován internet celkově a http je přesměrováno na hlášku, že a proč byl zablokován a co má dělat, přičemž pokud problém odstraní, automaticky se zas během chvíle internet i SMTP odblokuje.
-
Ondřej Caletka (neregistrovaný)
[20.] Jako dočasné řešení budiž, je to na stejné úrovni jako použití jiného UDP portu, což ostatně je potřeba udělat i pro DNSCrypt.
Správné je ale upozornit ISP, že má v síti něco špatně. Čím více lidí si bude stěžovat na problém s jeho sítí, tím je větší pravděpodobnost, že od podobného odklánění upustí.
-
Matas (neregistrovaný)
[13] duvody jsou proste a stejne jak je napsano v clanku, spatna konfigurace na strane klientu a to hlavne pripade kdy prechazeji od jineho providera... zakaznik je vam schopen tvrdit ze ma vse naprosto v poradku, kdyz po 3 dnech hledani chyby dojdete na misto nestacite se divit jak maji nektere veci nastaveny... Kdyby se jednalo o ojedinely pripad clovek by nad tim mavnul rukou, ale kdyz to resite po Xte tak to proste vzdate...
Na druhou stranu, v par vyjimecnych pripadech jsem sem krome toho setkal napr. s pokusy o obejiti QoS/shaperu nebo docasneho omezeni provozu z duvodu dluhu tunelovanim bezneho provozu pres DNS dotazy nebo pres obsah ICMP paketu... inu obcas se clovek nestaci divit co vsechno dokazou zakaznici vymyslet :-)[18] velmi podobne reseni ma jeden velky narodni ISP (a UPC to neni), posilaji si kopie SYN paketu sestavujici spojeni na port 25 na Linuxovy stroj ktery si dela statistiky, a kdyz to prekroci provoz "bezny" limit proste se spojeni na tento port (a pouze na nej) docasne blokne...
ČLÁNKY DO MAILU