Desenvolupadors de Firefox
Després d'activar DoH, es mostra a l'usuari un avís que permet, si ho desitja, negar-se a contactar amb servidors DNS DoH centralitzats i tornar a l'esquema tradicional d'enviament de consultes sense xifrar al servidor DNS del proveïdor. En lloc d'una infraestructura distribuïda de resolutors DNS, DoH utilitza una vinculació a un servei DoH específic, que es pot considerar un únic punt de fallada. Actualment, el treball s'ofereix a través de dos proveïdors de DNS: CloudFlare (per defecte) i
Canvia de proveïdor o desactiva DoH
Recordem que DoH pot ser útil per prevenir filtracions d'informació sobre els noms d'amfitrió sol·licitats a través dels servidors DNS dels proveïdors, combatre els atacs MITM i la falsificació del trànsit DNS (per exemple, quan es connecta a una xarxa Wi-Fi pública), contrarestar el bloqueig al DNS. nivell (DoH no pot substituir una VPN a l'àrea d'obviació del bloqueig implementat a nivell de DPI) o per organitzar el treball si és impossible accedir directament als servidors DNS (per exemple, quan es treballa a través d'un proxy). Si en una situació normal les sol·licituds DNS s'envien directament als servidors DNS definits a la configuració del sistema, aleshores, en el cas de DoH, la sol·licitud per determinar l'adreça IP de l'amfitrió s'encapsula en el trànsit HTTPS i s'envia al servidor HTTP, on el resolutor processa sol·licituds mitjançant l'API web. L'estàndard DNSSEC existent només utilitza el xifratge per autenticar el client i el servidor, però no protegeix el trànsit de la intercepció i no garanteix la confidencialitat de les sol·licituds.
Per seleccionar els proveïdors de DoH que s'ofereixen a Firefox,
DoH s'ha d'utilitzar amb precaució. Per exemple, a la Federació Russa, les adreces IP 104.16.248.249 i 104.16.249.249 associades amb el servidor DoH predeterminat mozilla.cloudflare-dns.com que s'ofereix a Firefox,
El DoH també pot causar problemes en àrees com els sistemes de control parental, l'accés a espais de noms interns en sistemes corporatius, la selecció de rutes en sistemes d'optimització de lliurament de continguts i el compliment de les ordres judicials en l'àmbit de la lluita contra la distribució de contingut il·legal i l'explotació de continguts. menors d'edat. Per evitar aquests problemes, s'ha implementat i provat un sistema de verificació que desactiva automàticament DoH en determinades condicions.
Per identificar els solucionadors empresarials, es comproven els dominis de primer nivell (TLD) atípics i el resolutor del sistema retorna adreces d'intranet. Per determinar si els controls parentals estan activats, s'intenta resoldre el nom exampleadultsite.com i si el resultat no coincideix amb la IP real, es considera que el bloqueig de contingut per a adults està actiu a nivell de DNS. Les adreces IP de Google i YouTube també es comproven com a senyals per veure si han estat substituïdes per restrict.youtube.com, forcesafesearch.google.com i restrictmoderate.youtube.com. Aquestes comprovacions permeten als atacants que controlen el funcionament del resolutor o que són capaços d'interferir amb el trànsit simular aquest comportament per desactivar l'encriptació del trànsit DNS.
Treballar a través d'un únic servei DoH també pot provocar problemes amb l'optimització del trànsit a les xarxes de lliurament de contingut que fan un equilibri de trànsit mitjançant DNS (el servidor DNS de la xarxa CDN genera una resposta, tenint en compte l'adreça del resolutor i emet l'amfitrió més proper). rebre contingut). L'enviament d'una consulta DNS des del solucionador més proper a l'usuari en aquests CDN retorna l'adreça de l'amfitrió més propera a l'usuari, però l'enviament d'una consulta DNS des del resolutor centralitzat retornarà l'adreça de l'amfitrió més propera al servidor DNS-over-HTTPS. Les proves a la pràctica van demostrar que l'ús de DNS-over-HTTP quan s'utilitzava un CDN pràcticament no va provocar retards abans de l'inici de la transferència de contingut (per a connexions ràpides, els retards no van superar els 10 mil·lisegons i fins i tot es va observar una acceleració en canals de comunicació lents). ). També vam considerar utilitzar l'extensió de subxarxa de client EDNS per passar la informació d'ubicació del client al solucionador de CDN.
Font: opennet.ru