FINANCE.czFINANCE.cz

Vlákno názorů k článku Soukromí v DNS: krátké dotazy a šifrovaná komunikace od muf - Když jsem kdysi v 90. letech začínal s...

  • Článek je starý, nové názory již nelze přidávat.
  • 4. 7. 2016 12:13

    muf (neregistrovaný)

    Když jsem kdysi v 90. letech začínal s DNS, _dlouho_ jsem se domníval, že "iterativní" dotazování probíhá přesně tak, jak je uvedeno na druhém obrázku(minima­lizace dotazů). Pořád mně tam něco nesedělo a tak jsem po určité době přišel na to, kde je pravda... Ale nechápal jsem, proč původní návrháři zvolili to "standardní", ne moc elegantní, řešení.
    To, že je moje původní myšlenka dnes již standardizována mě samozřejmě potěšilo :-)))

  • 4. 7. 2016 12:51

    Michal Pastrňák

    Dá se jen předpokládat, že to je dáno tím, že první verze DNS byla vytvořena v roce 1983, ještě v ARPANETu, dávno před internetem. A jak to tak bývá, nároky se časem změnily, ale základ zůstal. Původně prostě neběžel DNS server na každé kravině a bylo pravděpodobné, že se ke správné hodnotě dostaneš dříve, než se prokoušeš celým názvem. Ušetřilo to značnou část režie a v době, kdy se rychlosti počítaly v jednotkách, maximálně desítkách kilobitů a to ještě za dobrého větru, to bylo výhodnější, než se jednoho a toho samého serveru ptát postupně třikrát jen proto, abych nakonec zjistil, že se stačilo zeptat jednou, maximálně dvakrát. Co se týká bezpečnosti, internet vznikl jako médium pro sdílení, ne pro utajování, takže nebyl důvod tento archaický a funkční systém nějak měnit. Ostatně, internet je (respektive donedávna byl) plný zajímavostí, které z bezpečnostního hlediska nedávají smysl a které se v posledních pár letech "lepí" různými rozšířeními. Krásným příkladem je třeba SMTP, což je ještě mnohem horší, než "děravé" DNS. Bohužel, ačkoliv by bylo spoustu věcí třeba předělat od základů, nelze jen tak ze dne na den něco utnout a spustit něco nového, viz IPv6.

  • 4. 7. 2016 14:44

    Filip Jirsák
    Stříbrný podporovatel

    Původně se počítalo, že DNS půjde víc do hloubky (dnes se rozšiřuje hlavně do šířky). Třeba typická adresa v univerzitním prostředí - zarizeni.kate­dra.fakulta.u­niverzita.edu­.stat. Nemusí mít každá katedra svůj DNS server, pokud bude na úrovni fakulty nebo univerzity, ušetří se jeden nebo dva dotazy. Zároveň býval sloučený do jednoho serveru autoritativní server i resolver. Takže ve výše uvedeném případě, i kdyby DNS server měla každá fakulta, univerzitní server by mohl mít daný záznam nakešovaný a odpovědět jím rovnou.

    Mne naopak překvapilo, že každá zóna musí mít svůj server. DJBDNS v konfiguraci běžně zóny „přeskakuje“, je zvykem třeba jmenné servery pojmenovávat a.ns.example.com, b.ns.example.com atd., přičemž zónu ns.example.com nikde nedefinujete. Vždycky jsem si myslel, že ta zóna není potřeba, právě proto že se v dotazu posílá vždy celé jméno. Nevím, zda DJBDNS ten SOA záznam pro doménu ns.example.com syntetizuje, nebo jestli porušuje RFC a s minimalizací nebude fungovat. Ostatně do zónového souboru, který používají jiné servery, je také možné napsat jména s tečkou. Jsem zvědav, jak ta minimalizace bude fungovat v praxi.

  • 4. 7. 2016 21:05

    Ondřej Caletka
    Zlatý podporovatel

    Každá zóna rozhodně nemusí mít svůj server. Krásně je to vidět třeba na reverzních IPv6 záznamech, kde rozhodně není samostatný server co každá tečka ve jméně. Pokud se zeptáte na neúplné jméno, dostanete takzvaný Empty Non-Terminal, tedy návratový kód NOERROR a žádná data:

    $ dig 0.0.0.8.6.0.0.c.7.6.0.1.0.0.2.ip6.arpa ns @ns.iinfo.cz
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2452
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
    …
    ;; QUESTION SECTION:
    ;0.0.0.8.6.0.0.c.7.6.0.1.0.0.2.ip6.arpa.        IN NS
    
    ;; AUTHORITY SECTION:
    8.6.0.0.c.7.6.0.1.0.0.2.ip6.arpa. 3600 IN SOA   ns.iinfo.cz. hostmaster.adminit.cz. 2015090701 21600 7200 2419200 3600

    Unbound obsahuje optimalizaci, že pro reverzní IPv6 záznamy skáče po osmi labelech. Větší problém je, že spousta autoritativních DNS serverů se nechová v souladu se standardy a odpovídá návratovým kódem NXDOMAIN v případě dotazu na ENT. Příkladem je třeba tato zóna:

    $ host wildcard.whitehouse.gov.edgekey.net
    wildcard.whitehouse.gov.edgekey.net is an alias for wwws.eop-edge-lb.akadns.net.
    wwws.eop-edge-lb.akadns.net is an alias for e4036.dscb.akamaiedge.net.
    e4036.dscb.akamaiedge.net has address 104.103.75.94
    e4036.dscb.akamaiedge.net has IPv6 address 2a02:26f0:11a:19f::fc4
    e4036.dscb.akamaiedge.net has IPv6 address 2a02:26f0:11a:195::fc4
    
    $ host whitehouse.gov.edgekey.net
    Host whitehouse.gov.edgekey.net not found: 3(NXDOMAIN)

    Protože kód NXDOMAIN říká, že dané jméno neexistuje a neexistuje celý podstrom končící na dotazované jméno, je takové chování vcelku nebezpečné, protože položí-li někdo neúplný dotaz, otráví cache rekurzivního serveru, který přestane odpovídat i na poddotazy. Minimalizace dotazovaného jména tuto vadu autoritativních serverů exploituje ve velkém. Proto Unbound obsahuje úpravu proti standardu, kdy vypíná minimalizaci dotazovaného jména při návratovém kódu jiném než NOERROR. To také dává aktivním útočníkům návod, jako minimalizaci eliminovat ;)

    Více informací k Unboundu zde: https://ripe72.ripe.net/archives/video/219/

  • 4. 7. 2016 21:35

    Filip Jirsák
    Stříbrný podporovatel

    V tom případě dotazování s minimalizací musí být složitější, než jak je popsané v článku – dotaz na celé jméno je potřeba poslat i v případě, kdy klient dostane odpověď NOERROR.

  • 5. 7. 2016 23:06

    Ondřej Caletka
    Zlatý podporovatel

    Ne nutně na celé jméno, přidá se jen další label. Je to přesně ten okrajový případ, kde minimalizace dotazů způsobuje nadpočetné sady dotazů a odpovědí.

  • 6. 7. 2016 8:32

    Filip Jirsák
    Stříbrný podporovatel

    Přidávat po jednom labelu je podle mne řešení pro extrémně paranoidní jedince. Ten případ bez zóny bude v drtivé většině případů koncové jméno, nebo-li se tím postupným přidáváním labelů postupně stejně dostanu na celé jméno a budu se ptát pořád toho samého serveru. Ale proti gustu…