To spolu přeci vůbec nesouvisí. TLS mezi DNS servery zajistí skutečně jen komunikaci mezi nimi, nic víc. Nerozhoduje o autenticitě přeposílaných dat, tu zajišťuje DNSSEC a jím je podepsaný TLSA záznam s otiskem certifikátu/klíče. Vlastně se ty dvě věci (DNS zapouzdřené do TLS a DNSSEC s TLSA) nijak neovlivňují.
Preto D. J. Bernstein ku tinyDNS a TCP napisal poznamku (https://cr.yp.to/djbdns/tcp.html#why):
When are TCP queries sent?
If you're in one of the following situations, you need to configure your DNS server to answer TCP queries:
- You want to publish record sets larger than 512 bytes. (This is almost always a mistake.)
- You want to allow outgoing zone transfers, for example to a third-party server.
- A parent server refuses to delegate a name to you until you set up TCP service.
If you aren't in any of those situations, you have no need to provide TCP service, and you should not set it up. DNS-over-TCP is much slower than DNS-over-UDP and is inherently much more vulnerable to denial-of-service attacks. (This applies to BIND too.)
Posledna stabilna verzia djbdns bola vydana v roku 2001. To je pred 15 rokmi. Predpokladam, ze ta poznamka bola napisana tiez niekedy pred 15 rokmi.
Takze ta poznamka asi nepocita s niektorymi novymi vecami, ktore sa za tych 15 rokov medzicasom objavili... a to ako v DNS, tak aj v DoS.
Coz vubec neznamena, ze to stale neplati. Co treba polootevrena spojeni na tcp? Ono se UDP pouziva z dobreho duvodu. Na UDP kdyz mi nekdo posle paket, tak vratim odpoved, a tim to pro me konci. Na TCP musim nejdriv vyjednat pripojeni (a pak ho uzavrit) a co kdyz mezi tim prestane protistrana komunikovat? Nebo vlastne vubec nezacne? No tak budu cekat na nejaky timeout ... a mezi tim to cele drzet v ram.
A to pochopitelne vede, i pri zcela koser provozu, k nasobne vetsimu zatizeni. A taky to vede k tomu, ze DOSnout to DNS je nasobne jednodussi.
Nehovoril som, ze to neplati, ale ze medzicasom sa objavili nove veci.
Tak teda skusme konkretne priklady:
- Pred tymi 15 rokmi sa DNS servery masivne nezneuzivali na DoS utoky odrazom, takze to nikto nepotreboval riesit (a ta poznamka to vcelku logicky vobec nespomina). Tak co, nechame to tak? Pred 15 rokmi problem neexistoval, tak ani dnes ho nemusime riesit? Alebo ako by si si to predstavoval?
- Pred tymi 15 rokmi sa taktiez nedialo masivne falsovanie DNS odpovedi (ISP operatorom alebo statnymi organmi), pripadne kompletne presmerovavanie DNS requestov. Dnes sa vsak take veci deju (niekde vo velmi velkej miere), UDP DNS tomu vobec nedokaze zabranit (dokonca ani ak server podporuje DNSSEC) - a navyse falsovanie DNS vyjde ISP ci statnych cenzorov velmi lacno.
DNSSEC je funkcne proti nahodnym utocnikom, ale nie ked "utocnik" ma pod kontrolou celu siet (resp. je siet).
Falsovatel na urovni ISP alebo vlady mi posle "svoju" odpoved na moj DNS request (a originalnu odpoved od DNS servera mi nedoruci, pripadne zahodil ci presmeroval na seba uz moj request). A v tej sfalsovanej DNS odpovedi nie je o DNSSEC ani zmienka. Takze si mozem vybrat, ci zahodim odpoved, v ktorej DNSSEC nie je aj ked ja by som ho tam ocakaval, alebo ci zozeriem aj s navijakom, co v tej odpovedi je. Super, mam moznost volby! Skoda len, ze nech sa rozhodnem akokolvek, ja neviem spravnu IP-adresu a cenzor je rad, ze ma zablokoval.
Takový útok na DNSSEC není možný – není možné nenápadně zatajit část informací. Pokud přijede odpověď bez podpisů (nebo s neplatnými) a ty tam mají být, tak to resolver pozná a vrátí SERVFAIL. To je princip DNSSEC, nikdo nemůže po cestě ty informace měnit nebo zatajit existenci DNSSEC.
Samozřejmě je možné odpovědi prostě zatajit, což je logické – DNSSEC jsou podpisy, ne křišťálová koule. Takže odpovědi, které nedorazí, nedokáže vyvěštit.
Jak pozna ze tam ma byt? Zeby ... nijak ...
Aby si resolver moh myslet, ze nekde dnsec byt ma, tak se musi dostat a dotazat nadrizenyho serveru, a musi dostat odpoved ...a musi tam byt DS. Kdyz nedostane, coz lze trivialne zaridit, tak je domena akceptovana jako nepodepsana. Nazdar bazar, dnsec je v haji ...
Nepravda. Začátek řetězce je u kořenové zóny, o které resolver bezpečné ví, že má být podepsaná. Má k dispozici otisk jejího veřejného klíče. Takže tohle není možné obejít. No a pak řetězec pokračuje – pokud je v kořenové zóně DS záznam pro .CZ, pak resolver ví, že ta zóna musí být podepsaná a pokud… a tak dále. Takže ten řetězec je nepřerušitelný bez toho, aby si toho resolver všiml.
Jiste, nedoruceni odpovedi na DS je fakt neresitelnej problem ...
Navic, specielne kdyz se budem bavit o CZNICu, skocej, jak stat piskne, takze kdyz stat bude chtit aby fakovali dns, tak to budou delat.
A nevsim sem si, ze by resolvery uzivatelu (tedy tej 99%, kteri menaj vlastni DNS) vubec nejak resily dnssec.
DNSSEC je funkcne proti nahodnym utocnikom, ale nie ked "utocnik" ma pod kontrolou celu siet (resp. je siet).
To není pravda. Ani pokud má útočník pod kontrolou celou síť, nedokáže podvrhnout DNSSEC. Jediné, co dokáže, je „zabavit“ odpovědi – jenže když se uživateli nepodaří přeložit doménové jméno, u kterého si je jist, že by mělo existovat, přijde na to, že mu odpovědi někdo cenzuruje.
Falsovatel na urovni ISP alebo vlady mi posle "svoju" odpoved na moj DNS request. A v tej sfalsovanej DNS odpovedi nie je o DNSSEC ani zmienka.
Jenže z nadřazené domény vím, že tam DNSSEC má být. Takže vím, že ta odpověď je falešná.
Takze si mozem vybrat, ci zahodim odpoved, v ktorej DNSSEC nie je aj ked ja by som ho tam ocakaval, alebo ci zozeriem aj s navijakom, co v tej odpovedi je.
Proč bych používal zfalšovanou DNS odpověď? Vím, že je zfalšovaná, tak za prvé budu řešit, kdo na mne útočí, a za druhé se pokusím správnou odpověď získat jiným způsobem.
Skoda len, ze nech sa rozhodnem akokolvek, ja neviem spravnu IP-adresu a cenzor je rad, ze ma zablokoval.
Jenže vy víte, že došlo k manipulaci s DNS odpovědí, takže můžete tu adresu přeložit jinak. Třeba VPN tunelem do nějaké bezpečné sítě.
Vyborne... pomaly sa tam dostavame.
Za prve, nebudeme sem vnasat novy problem s VPN. To je samostatna tema (mimochodom velmi dlha). Debata bola o DNS, zostanem pri tom.
Za druhe: To vsetko o DNSSEC znie naozaj nadherne... lenze v praxi je mi uplne nanic, ze som sa dozvedel, ze odpoved je podvrhnuta. Cenzorovi o nenapadnost vobec nejde, ved ked je nieco scenzurovane tak si to nakoniec vsimnem tak ci tak. Mozem na to nadavat, mozem s tym dokonca aj nesuhlasit, ale to je asi tak vsetko, co proti tomu mozem robit.
Teda... keby som bol obzvlast naivny idiot, tak sa mozem skusit stazovat u ISP (u toho, co mi falsuje DNS odpovede), pripadne toho ISP zazalovat na sude (toho statu, ktoreho vlada tomu ISP to cenzurovanie internetu nariadila). Super. Vlastne este mozem skusat agitovat v okoli, ako to nefunguje (a byt za blazna, pretoze "im predsa ten internet funguje" - kedze ani nemaju vlastny resolver a zeru vsetko z resolverov ISP). Alebo sa odpojit a nepouzivat net vobec. Same skvele moznosti. Technicke riesenie to v kazdom pripade nema.
Najpragmatickejsi postup v takejto situacii je teda nevyzadovat na svojom resolveri validaciu DNSSEC, pocitat s tym, ze DNS je skratka dokurvene (a s cenzurou sa vysporiadat uplne inac).
Takze opakujem, DNSSEC je pekna vec, aj funkcna, ale v takomto pripade mi nijako nepomoze - a pokial viem, cielom DNSSEC ani nikdy nebolo uplne znemoznenie cenzury cez DNS, takze ja sa tu ani nestazujem, len popisujem iste veci, ktore sa deju.
A za tretie: V tomto vlakne sme sa povodne bavili o tom, ci 15 rokov stare pravdy su postacujuce pre rozhodovanie v dnesnom svete. A ja dalej trvam na svojom nazore, ze nie. To, co popisujem v tomto prispevku, je len jedna z veci, ktore sa dnes deju (nie vsade, v CZ mozno vobec, ale inde sa deju, aj masovo) a pred tymi 15 rokmi sa nediali.
lenze v praxi je mi uplne nanic, ze som sa dozvedel, ze odpoved je podvrhnuta
Vám je to možná a nic. Pro mne je to zásadní informace, která mi umožní za prvé pátrat po tom, jak je možné, že dostávám podvržené odpovědi, za druhé zkusit získat validní odpověď jinou cestou.
mozem skusit stazovat u ISP (u toho, co mi falsuje DNS odpovede)
Odpovědi může falšovat někdo jiný, než ISP.
toho ISP zazalovat na sude (toho statu, ktoreho vlada tomu ISP to cenzurovanie internetu nariadila)
K falšování DNS nemusí docházet jen na základě rozhodnutí státu. Naopak v demokratickém státě by jen těžko stát nařídil falšování DNS.
Najpragmatickejsi postup v takejto situacii je teda nevyzadovat na svojom resolveri validaciu DNSSEC, pocitat s tym, ze DNS je skratka dokurvene (a s cenzurou sa vysporiadat uplne inac).
Nejlepší postup je vykašlat se na pohádky o státní cenzuře a začít řešit reálné problémy – tedy falšování DNS nestátními útočníky.
pokial viem, cielom DNSSEC ani nikdy nebolo uplne znemoznenie cenzury cez DNS
Ne, cílem DNSSEC nikdy nebylo znemožnit cenzuru, protože to v té většině světa, kde bylo DNSSEC navrhováno, není reálný problém. A v té menšině států, kde k cenzuře skutečně dochází, se to stejně musí řešit politicky, technicky to řešit nejde.
len popisujem iste veci, ktore sa deju
Když mohou v Číně zakázat přístup na nějaký web a řešit to Velkým čínským firewallem, nebude pro ně problém úplně stejně řešit i jakékoli jiné technické řešení. Pokud by bylo možné blokování DNS obejít TCP spojením s TLS, prostě zakážou DNS dotazy přes TCP s TLS.
Jiste, DNSSEC nepodrvrhetem, ale co kdyz ISP proste pro jednu konkretni domenu validaci vypne? Proste se bude tvarit, ze DNSSEC (pro konkretni domenu) vubec nepodporuje... Navic, 99% klientu zadnou validaci nedela. Obvykle jsou koncova zarizeni, ktere zakaznici pouzivaji, natolik zoufale provedena, ze jsou rady, ze vubec funguji (stub resolver v modemu, routeru a pod.), natoz aby delaly DNSSEC validaci.
Proč o DNSSEC pořád diskutují lidé, kteří se ani neobtěžují zjistit, jak DNSSEC funguje? Podepsaná je kořenová zóna, každý validující klient má u sebe veřejný klíč kořenové zóny. Dotaz na nějakou doménu vždy směřuje do nadřazené domény, ze které přijde jedna za tří možných podepsaných (pokud daná zóna podporuje DNSSEC) odpovědí: hledaná doména neexistuje, hledaná doména má server tam a tam a následující DNSSEC klíč, nebo hledaná doména má server tam a tam a DNSSEC nepoužívá. Takže pokud jsou všechny domény v cestě od požadované domény až ke kořenové podepsané, musejí být podepsané všechny odpovědi a klient je vždy může ověřit v nadřazené zóně, až kořenovou zónu ověří proti uloženému klíči.
Jak to tedy bude vypadat, když ISP validaci „prostě vypne“? Ano, správně, klient bude mít z nadřazené domény informaci, že doména DNSSEC používá, a přitom dostane odpověď bez DNSSEC. To je jeden ze dvou nejtypičtějších útoků, proti kterým má DNSSEC bránit, a všichni, kdo pracují s DNSSEC, samozřejmě vědí, že klient musí takovou situaci vyhodnotit jako pokus o útok.
*Validujici* klient ano. Ale to neni typicka situace. Spise vyjimka. Bezny klient (v LAN, za napr. ADSL modemem, 4G modemem), ktery ma nastaveny jako resolver svuj router, se nidy nedozvi, ze konkretni domena pouziva DNSSEC. Jeho router (stub resolver) slepe vse preposila na resovery pridelene od ISP. Tj. pokud se na ISP resolveru pouzije direktiva domain-insecure (Unbound), takova DNSSEC podepsana domena se resolvi, bez ohledu na to, jestli je je retezec duvery OK nebo ne.
Pochopitelne. Jenze podle diskuse vyse by neznaly mohl nabyt dojmu, ze pokud si spravce domeny tuto podepise, v tu chvili je vse vyreseno a nikdo nikdy nemuze *beznemu* DNS klientu podvrhnout jiny zaznam, zatajit zaznam a pod. S tim, jak to realne v sitich funguje, bohuzel muze (a DNSSEC za to samozrejme nemuze)
Mimochodem, napr. Google v Android telefonech pro rezoluce svych sluzeb uz nespoleha na operatorem pridelene DNS, ale pouziva svoje DNS, cimz se IMHO snazi podobnym manipulacim vyhnout.
djbdns sa nevyvyja lebo na nom nie je co vyvyjat, To co ma robit robi a chybu tam nasiel pokial sa pamatam len 1 clovek pred 10timi rokmi. A to aj napriek tomu ze Bernstein ponuka $1000 za najdenu chybu v djbdns (https://cr.yp.to/djbdns/guarantee.html)
Stale tinydns/dnscache pouzivam. Podporuje vsetko (aj IPv6), takze nevidim dovod menit.
Původní djbdns nepodporuje IPv6, nepodporuje třeba také DNSSEC. Dělá to, co DJB tvrdí, že má dělat, což je bohužel v čím dál větším rozporu s tím, co většina lidí od DNS serveru očekává. Na druhou stranu je smutné, že v některých vlastnostech djbdns nejen, že nebyl překonán, ale zatím ani nebyl dostižen.
to ze nepodporuje IPv6 je mytus. Bernstein sa kritikou IPv6 nikdy netajil (vacsina dovodov ma hlavu a patu), ale IPv6 podporu tinyDNS ma - cez record type 28.
Existuje este fefe's patch ktory navyse riesi aj IPv6 glue record a vlastny prefix pre IPv6
Neviem co ine cakat od DNS serveru nez odpovedanie na DNS dotazy klientov. Transfery zon - staci scp na data file z primarneho serveru na sekundarne. Dostupne ihned, daemon sam zisti ze subor sa zmenil.
Dokonca aj to TCP sa da rozbehat.
Bernstein ma mne sympaticky minimalisticky pristup. BIND je moloch ktory ked by clovek velmi chcel, tak by ho presvedcil aby servoval dynamicke html stranky v php.
Vela kodu a vela zbytocnych funkcii = velka sanca na chyby a diery. Presne problem OpenSSL a podobnych monstrprojektov.
> Server má dotazy přicházející TCP spojením řešit paralelně a odpovědi posílat v libovolném pořadí, jakmile je má k dispozici.
Sice jsem s TCP na Linuxech delal jenom na skole a v malem mnozstvi, ale nezajistuje TCP stack ze zpravy prijdou (budou dostupne ke cteni v programu) ve stejnem poradi v jakem byly odeslany? Cist jak pakety chodi by vyzadovalo zasah primo do kernelu ne?
Opravte me jestli se pletu :/
Jinak super souhrn! Kudos :)
TCP protokol nepřenáší zprávy, ale proud bajtů. A zajišťuje, že bajty budou přijaty v tom pořadí, v jakém byly odeslány. DNS nad tím přenáší zprávy, a ty tedy z principu TCP musí být doručeny v pořadí, v jakém byly odeslány. Jednotlivé požadavky (zprávy) ale nemusí být vyřízeny stejně rychle – takže server může dostat třeba požadavky „přelož mi 1“, „přelož mi 2“ a „přelož mi 3“, ale příprava odpovědi pro 2 mu bude z nějakého důvodu trvat dlouho. DNS server ale má povoleno odpovědět „odpověď na 1“, „odpověď na 3“, „odpověď na 2“.
To je jednoduchy, budes muset svuj certifikat zaregistrovat podobne jako domenu ... zaplatit prislusnej spravni poplatek ... a pokud o tobe nekdo rekne ze ses zlej hoch, tak prestane tvoje DNS fungovat (a je jedno jestli v podobe vlastniho DNS serveru nebo primo klienta) ... a voiala ... mame vyreseno 100% efektivni blokovani domen, protoze neautorizovanej DNS nic neprelozi.
V komunikaci stub to resolver bych to přesně takhle viděl (tj. pinning)... Samotné skoro-RFC k tomu říká toto:
The client will then authenticate the server, if required. This document does not propose new ideas for authentication. Depending on the privacy profile in use (Section 4), the DNS client may choose not to require authentication of the server, or it may make use of a trusted Subject Public Key Info (SPKI) Fingerprint pinset.
Pokud se bavíme o komunikaci resolver<->autoritativní DNS, tak tam dává nejvíc smysl použít TLSA.
P.S.: Díky Lennartovi a jeho "opportunistic DNSSEC" v systemd-resolved máte od teď v RH zakázáno používat slovo oportunistický ;)