14 lipca wieczorem Internet na ca?ym ?wiecie na moment przesta? dzia?a? — winna by?a b??dna konfiguracja us?ug DNS w Cloudflare. Przez 62 minuty u?ytkownicy do?wiadczyli niedost?pno?ci tysi?cy stron i us?ug. Cho? awaria trwa?a krótko, jej zasi?g podkre?li? skal? zale?no?ci globalnych us?ug od pojedynczych punktów infrastruktury.
B??d powsta? na skutek niezamierzonej zmiany w konfiguracji nieprodukcyjnej jeszcze us?ugi Cloudflare, która zawiera?a prefiksy zwi?zane z popularnym resolverem 1.1.1.1. Druga zmiana — ju? w lipcu — sprawi?a, ?e te prefiksy zosta?y nie?wiadomie wycofane z centrów danych, co uczyni?o resolver niedost?pnym. Poniewa? wiele systemów opiera si? na zapytaniach DNS do Cloudflare, efekt by? natychmiastowy i dotkliwy.
Co ciekawe, ruch DNS przez HTTPS (DoH) by? w du?ej mierze odporny na awari?. To pokazuje, ?e alternatywne protoko?y, cho? wci?? niszowe, mog? dzia?a? jako bezpiecznik w krytycznych sytuacjach. Niemniej jednak, dla wi?kszo?ci u?ytkowników awaria oznacza?a przerw? w dost?pie do us?ug — od komunikatorów po systemy p?atno?ci.
Cloudflare oficjalnie przyzna?o si? do winy i zapowiedzia?o zmiany: odej?cie od przestarza?ych systemów i wi?ksz? ostro?no?? przy wdro?eniach. To klasyczny przyk?ad, ?e nawet giganci Internetu nie s? odporni na w?asne b??dy. Dla firm i dostawców us?ug IT to przypomnienie, ?e nadmiarowo?? i rozproszenie punktów krytycznych nie s? luksusem, a konieczno?ci?.
