Vlákno názorů k článku Principy fungování DNS: život jednoho dotazu od Mintaka - Díky za článek. Malá chybka se vloudila do věty: "Vybere...

Díky za článek.

Malá chybka se vloudila do věty:
"Vybere si jeden z autoritativních serverů pro doménu tl.cz, třeba bubo.tul.cz"

Že mohu přes lokální DNS server, který klientům propašuji přes DHCP podvrhnout adresy jiných stránek, to je celkem známá věc. Škoda že Firefox, ani moc neprotestuje a zobrazí jen malé upozornění.
Dá se tomu zabránit nastavením DNS serveru, třeba na 193.17.47.1

A co když v lokální síti budou podvržené IP adresy běžně používaných DNS serverů, jako 8.8.8.8, 1.1.1.1. a podvržené mohou být i adresy doménových serverů 193.17.47.1, ... i kořenových DNS serverů. Jaká by proti tomu byla obrana?

Ověřené šifrované spojení k resolveru. Všechny tři vyjmenované jsou veřejné resolvery které podporují DoT a DoH (DNS over TLS / HTTPS). V případě DoH je i podpora pro použití přímo z prohlížečů, jak zmíněný Firefox, tak Chrome a snad i jeho klony.

Tu komunikaci k jinemu resolveru samozrejme muze spravce infrastruktury, kde chteji DNS odpovedi modifikovat celkem snadno zablokovat, zvlast pokud je rec o tech verejne znamych resolverech (jejichz seznamy se vali vsudemozne).

DoT, DoH ci nejnoveji DoQ z klienta na resolver resi jen zabezpeceni transportu, ale porad tu samotnou duveru porad presouvame nekam jinam - a tam jinde samozrejme k nejaky modifikacim dojit muze. Samo o sobe je to porad stejny "ohejbak" jako duvera v AD flag... neboli podminka nutna, ale nikoliv dostacujici. A konec tunelu a svetlo je stale daleko.

Milovnici "starych poradku" se musi (a zatim moc nechteji) mimo jine smirit treba i s tim, ze cely proces DNSSEC validace musi probehnout az na strane klienta a ne nekde po ceste. Klient musi byt co nejvice autonomni a nemuze spolehat na to, ze za nej neco vyresi nekde jinde neco jineho. A zabezpecit se samozrejme musi cely retezec - nejen komunikace mezi klientem a prvnim resolverem. Dokud se budou hledat vymluvy proc to nejde a vymejslet vselijake ty polovicate ohejbaky (ktere ponechavaji jista zadni vratka na modifikaci DNS odpovedi smerem ke klientovi), DNS bude stale zranitelne.

A ze se v tom stale placame dokazuje i ta naprosto epicka roztristenost kolem zabezpecenych DNS transportu - zaclo se s DoT (RFC 7858 z roku 2016), pak se prislo s DoH (RFC 8484 z roku 2018)... a nejnoveji tu mame zminene DoQ aka RFC 9250 z roku 2022... :-) A samozrejme ne vsechny implementace implementuji vse z vyse zmineneho, krasne se to tristi - takze takovy Knot DNS (autoritativni) sice uz umi nejnovejsi DoQ, ale s DoT tam ma clovek smulu... zatimco u Binda ci NSD implementaci DoT mame.