Комментарии 12
Куда только ни придумают подключить ИИ.
Ах вот, что оно было. Пропал интернет. Приложения не открываются. Потом заметил, что браузер ругается именно на dns. 8888 заработал. Но после усилий РНК, даже мысли не возникло, что это сам 1111 упал
В этом случае, для теста можно попробовать отрезолвить что-то у серверов НСДИ - 19520861, точки сами расставьте . . . .
А может не сам? Роспозор подослал агента, чтобы он физически уронил сервер?!
Он не совсем упал
Поскольку мы таки на техническом ресурсе, то не "интернет пропал", а "домены перестали резолвиться". Это разные вещи: например, приложения, не полагающиеся целиком на DNS (типа Telegram), никаких проблем не испытают.
Используйте нескольких поставщиков DNS, полагаться исключительно на одного - не очень надёжно.
Именно для этого в настройках и предусмотрен Secondary DNS.
В эту игру можно долго играть, поскольку мы не знаем несколько моментов:
как настроено приложение у @Lev3250 : какие используются библиотеки в операционной системе, как идет взаимодействие client-server relationship, есть эти где-нибудь hardcode constants (ip addresses, name space, etc)
как настроено интерконнект для выхода в дикий Интернет: настроено ли через IPSec Roadwarrior, есть ли socks5 proxy, настроено ли per link or per scope routing based VPN, etc :) Обычно привожу аналогию с матрёшкой, но есть также интересное сравнение с песочными часами Hourglass Narrow Twist. Идея данной концепции в том, что можно сколько угодно делать encapsulation/tunneling protocol data unit (PDU) path и эту дает стимул к многообразию разных технологий Интернета, подробнее https://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p206.pdf https://systemsapproach.org/2024/08/19/how-the-hourglass-won/ https://www.potaroo.net/presentations/2006-07-07-ipv6.pdf https://www.oilshell.org/blog/2022/02/diagrams.html
Благодаря замечаниям @Zipdots, как раз вносится некая ясность о происходящем. Справедливости ради, Cloudflare уже предоставила отчет о произошеднем инциденте от 2027-07-14 https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/ + также сторонний взгляд от Thousand Eyes https://www.thousandeyes.com/blog/cloudflare-outage-analysis-july-14-2025 + обсуждение на Hacker News https://news.ycombinator.com/item?id=44578490 (как всегда, есть среди множества комментарием некоторые занимательные на Hacker News)
Из него для меня были занимательные моменты:
внутри команды Cloudflare Infrastructure Tiger Team запускается раскатка проекта Data Localization Suite по сети
These services are part of our Data Localization Suite (DLS), which allows customers to configure Cloudflare in a variety of ways to meet their compliance needs across different countries and regions. One of the ways in which Cloudflare manages these different requirements is to make sure the right service's IP addresses are Internet‑reachable only where they need to be, so your traffic is handled correctly worldwide. A particular service has a matching “service topology” — that is, traffic for a service should be routed only to a particular set of locations.
....
On June 6, during a release to prepare a service topology for a future DLS service, a configuration error was introduced: the prefixes associated with the 1.1.1.1 Resolver service were inadvertently included alongside the prefixes that were intended for the new DLS service. This configuration error sat dormant in the production network as the new DLS service was not yet in use, but it set the stage for the outage on July 14. Since there was no immediate change to the production network there was no end-user impact, and because there was no impact, no alerts were fired.
Это удивляет по своей природе IP Anycast, что подразумевает что можно аннонсировать IP Address Block из любой ASN scope - являение еще называется Multiple Origin ASN (MOAS), один из премеров это IP Address 77.88.8.0/24 https://irrexplorer.nlnog.net/prefix/77.88.8.0/24
Теперь же последние несколько лет вижу, что надо наоборот ограничивать видимость связности узлов BGP Nodes
Также об этом пишет Bert Hubert (бывший участник команды Core Team of PowerDNS) https://berthub.eu/articles/posts/cloud-overview/
It’s worth noting that DoH (DNS-over-HTTPS) traffic remained relatively stable as most DoH users use the domain cloudflare-dns.com, configured manually or through their browser, to access the public DNS resolver, rather than by IP address. DoH remained available and traffic was mostly unaffected as cloudflare-dns.com uses a different set of IP addresses. Some DNS traffic over UDP that also used different IP addresses remained mostly unaffected as well.
...
Можно сделать выводы, что для DNS over TLS, DNS over TCP, DNS over UDP ( еще можно сократить как DNSo53 по терминолгии RFC9499 https://datatracker.ietf.org/doc/html/rfc9499) используется разная связка dns label <> IP annoncement
https://bgp.he.net/dns/one.one.one.one
https://irrexplorer.nlnog.net/prefix/1.1.1.0/24
https://irrexplorer.nlnog.net/prefix/1.0.0.0/24
https://irrexplorer.nlnog.net/prefix/2606:4700:4700::1111
https://irrexplorer.nlnog.net/prefix/2606:4700:4700::1001
Но при этом для DNS over HTTPS используется другое dns label <> IP Address Block annoncement
https://bgp.he.net/dns/cloudflare-dns.com
https://irrexplorer.nlnog.net/prefix/104.16.249.249
https://irrexplorer.nlnog.net/prefix/104.16.248.249
https://irrexplorer.nlnog.net/prefix/2606:4700::6810:F9F9
https://irrexplorer.nlnog.net/prefix/2606:4700::6810:F8F9
Поэтому у части пользователей сервиса public recursive nameserver by Cloudflare не было проблем при использовании DNS over HTTPS
К слову, добротный обзор от @vened есть даже на данном ресурсе про практическую реализацию DNS over HTTPS\DNS over TLS https://habr.com/articles/891374/ + https://habr.com/articles/898138/
Once our configuration error had been exposed and Cloudflare systems had withdrawn the routes from our routing table, all of the 1.1.1.1 routes should have disappeared entirely from the global Internet routing table. However, this isn’t what happened with the prefix 1.1.1.0/24. Instead, we got reports from Cloudflare Radar that Tata Communications India (AS4755) had started advertising 1.1.1.0/24: from the perspective of the routing system, this looked exactly like a prefix hijack. This was unexpected to see while we were troubleshooting the routing problem, but to be perfectly clear: this BGP hijack was not the cause of the outage. We are following up with Tata Communications.
Report incident https://radar.cloudflare.com/routing/anomalies/hijack-107469
Как верно заметил @Zipdots, то наблюдалась странная смесь событий: RPKI (Resource Public Key Infrastructure) Invalid событие прилетает на Reply Party Validation ROA - что по умолчанию должно отбрасывать в RIB BGP маршруты
Но также наблюдаем Internet Routing Registry - IRR Invalid - которое свидетельствует что при внесении изменений IRR со стороны Cloudflare один из Eyeball ISP из ASN4755 не проводил валидацию IRR record в данных базах. ASN4755 как помечает Ben Cox входит в ASN Globank Rank Position под номером 37 https://bgp.tools/as/4755
\\\
Вообще все труднее с годами дать однозначный ответ на вопрос: как происходит name resolution lookup за пределами твоей сети
Так сейчас, изучаю тему по Connect-Ethernet over HTTP Proxy\ Connect-IP over HTTP Proxy, где это смесь MASQUE (Multiplexed Application Substrate over QUIC Encryption) + ODOH (Oblivious DNS over HTTPS)
https://datatracker.ietf.org/doc/rfc9230/
https://datatracker.ietf.org/doc/rfc9484/
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ethernet
Так это начинает внедрять несколько компаний:
Apple посредством настройки Network Relay https://support.apple.com/en-gb/guide/deployment/dep91a6e427d/web, обзор Apnic https://blog.apnic.net/2023/01/25/an-investigation-into-apples-new-relay-network/, обзор Apple WWDC 2023 year https://developer.apple.com/videos/play/wwdc2023/10002/
так и об этом начали часто говорить на CiscoLive, к примеру одна из последних презентаций BRKSEC-3027 https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2025/pdf/BRKSEC-3027.pdf - у них как раз решения Cisco FTD модернизируются под этот момент https://secure.cisco.com/secure-firewall/docs/decryption-policy
Примеры обзора в одном из блоге https://jedda.me/beneath-the-masque-network-relay-on-apple-platforms/
Получается что все больше подходим к концепции Zero Trust Network Access, которую мне приходилось эксплуатировать в решениях от Fortinet Design Docs https://docs.fortinet.com/ztna
В Cloudflare произошёл глобальный сбой в работе публичного DNS-резолвера 1.1.1.1