dns

Cloudflare анонсировал с публичный DNS-сервер 1.1.1.1. Он в два раза быстрее гугловского 8.8.8.8 и поддерживает DoH (об этом ниже).

DNS — это адресная книга интернета. Каждый раз, когда вы открываете сайт или приложение — телефон или компьютер сначала узнают цифровой адрес сервера через DNS.

По-умолчанию мы пользуемся DNS-сервером провайдера. Если настроить себе в компьютере и телефоне этот новый DNS 1.1.1.1 — страницы начнут открываться быстрее, а блокировки некоторых провайдеров — отключатся. На сайте есть инструкция, это просто и делается обычным человеком за 2 минуты.

Второй важный аспект — поддержка DNS over HTTPS. Это протокол, позволяющий шифровать DNS-запросы. Если его начнет поддерживать крупный сайт (гугл или яндекс, например) — провайдер не сможет блокировать ваши DNS запросы и даже подсматривать за ними. Пока что операционные системы и браузеры не умеют DoH из коробки, да и крупных серверов нет. Этот запуск — серьезный шаг к более безопасному и приватному DNS.

P.S. А ещё, это просто красиво. 1.1.1.1 — первый IP-адрес в интернете. Номерок подогнал APNIC — некоммерческое образование, регулирующее выдачу IP-адресов американского региона. Если хотите технических подробностей, как это всё работает под капотом — вот хороший пост.

UPD. Друзья поправляют, что в России у гугла присутствие гораздо лучше (чуть ли в каждом провайдере), чем у cloudflare, у которого одна точка в Москве. Так что в России (особенно в регионах) лучше использовать гугловский 8.8.8.8. Приношу извинения.

Сервис общего редактирования документов и командной работы Notion упал из-за DNS. Что происходит пока не понятно, но 3 минуты назад они попросили у себя в твиттере «у кого есть контакты name.com». 😲

Текущая оценка Notion — 2 миллиарда долларов.

Upd: починили, ждем постмортем 🍿

ФБ рассказал, почему они упали в понедельник.

Началось все с человеческой ошибки. В ходе обычной работы, кто-то дал системе команду, которая отключила все дата-центры Фейсбука от ее скоростной внутренней сети, которая связывает дата-центры Фейсбук друг-с-другом и со внешним интернетом.

Вообще-то, у них есть программа, которая проверяет команды и отменяет потенциально опасные — вроде той, которую написали в понедельник. Из-за ошибки в этой программе защиты, команда прошла автоматический контроль.

В этот момент все сервера Фейсбука пропали с радаров интернета, Фейсбук для внешнего мира сломался.

Все было бы ничего, инженеры могли бы быстро включить все обратно, но у фейсбука есть специальная автоматизированная система, которая проверяет связность DNS серверов с дата-центрами компании и в случае проблем — отключает эти серверы от интернета. В понедельник, эта система отключила все DNS-серверы компании от интернета.

DNS — адресная книга интернета. Эта система переводит человеческий адрес Facebook.com в машинный айпи-адрес 157.240.224.35. Формально, интернет может работать и без DNS, в реальности на работе DNS завязано почти ВСЁ. Например, внутренние сервисы — инструменты, которыми пользуются инженеры фейсбука для решения проблем. Да что там сервисы, сотрудники фб в офисы не могли попасть, потому что автоматической системе контроля дверей тоже нужна DNS.

Дополнительная вишенка на торте — сломалась не только основная сеть фейсбука, но и запасная, которая построена специально для доступа к управлению сетевым железом в случае аварии основной сети. В общем, инженерам пришлось ножками топать в дата-центр и подключаться к сетевому оборудованию напрямую, буквально проводочком. Это непросто, потому что современные дата-центры — это крепости, попасть в них кому-то сверх обычного персонала — то ещё приключение. А теперь попробуйте это сделать, когда все корпоративные IT-системы недоступны. Подозреваю, что высшему руководству буквально по телефону приходилось подтверждать личность инженеров. Да и современное железо в ДЦ построено так, чтобы даже наличие физического доступа не дает контроля над ним — придется доказать, что ты не верблюд.

В общем, горячие были 6 часов у инженеров. Респект фб, что так быстро описали суть произошедшего и жаль, что подробный отчет, по которому, безусловно, можно снять боевик — мы вряд ли увидим.

Конкретно от этой проблемы фб вряд ли пострадает во второй раз — программу проверки команд теперь будут тестировать на порядок лучше, да и DNS в будущем, вряд ли будет отключаться так легко. При этом, мы говорим об очень сложных системах и в них рано или поздно что-то пойдет не так. Такие крупные аварии, «идеальные штормы» происходят каждые несколько лет. Этот — не последний.

Нам же, простым смертным, это очередное напоминание, что стоит подстелить соломки и сделать так, чтобы наши сервисы, наши бизнесы продолжали работать, не теряли клиентов, даже если сломался такой гранд, как вацап или фейсбук. Когда все твои конкуренты вне доступа из-за крупной аварии — это шанс получить много новых клиентов, если ты продолжаешь работать. Хоть и баян, но: кризис — время возможностей.

Подъехал пост-мортем от Амазона.

С одной стороны, хочется поржать над DNS Enactor, DropletWorkflow Manager (DWFM), Network Manager и прочими — это Galactic от Krazam, только в реальном мире и на очень серьезных щщах.

Если без шуток, то цепочка такая:

1. сначала сломался доступ к dynamodb из-за рейс-кондишена системы управления DNS — два таска начали писать в DNS одновременно, первый старую версию записей, второй — более новую новую, в результате часть записей в DNS оказалась новая, часть старая, второй процесс запустил cleanup, который удалил все старые записи и из такого разломанного состояния система сама восстановиться не могла. Сломалось в полночью, за 50 минут поняли в чем дело и ещё за 40 минут починили руками.

2. из-за сломанного dynamodb, система управления железом не могла обновить статус физических серверов и начала отмечать их как «недоступные», поэтому не могла запустить новые виртуальные машины; после восстановления dynamodb, по-идее всё должно было встать само, но из-за большого объема железа, стоящего в очереди, обновление статуса занимало дольше, чем таймаут — и очередь не разгребалась, а только росла. Коллапс. Стандартной процедуры восстановления для такого случая прописано не было, через 2 часа попыток что-то разрулить, инженеры ограничили число входящих запросов и начали перезапускать тачки с системой управления; это помогло, теперь можно было создать новые виртуальные машины;

3. но ещё какое-то время эти новые виртуалки не делали никакой полезной работы, потому что из-за взрывной нагрузки не справлялась система управления разлива конфигурации сети и сеть на новые тачки приходила с задержкой;

4. из-за этой задержки появления сети на машинах, моргали статусы серверов в лоад-балансерах, отмечая живые инстансы как мертвые и триггерились дополнительные переключения нагрузки (привет, DNS!) и перегрузилась система проверки здоровья серверов,
пришлось её на время выключить.

Ну а когда у вас не доступны базы данных и виртуальные машины, то все остальное уже валится по цепочке (и список десятков облачных сервисов, которые пострадали).

Раздел «что мы поменяем» удивительно короткий и очень технический: починят рейс кодишен в DNS, ограничат объем серверов, который может выключить лоад-балансер и т. д. Ну и заканчивают «извините, в будущем будем более лучше стараться».

Интересно, что они не делают никаких философских выводов из ситуации. Видимо, считают, что идейно всё верно. Я сам такими огромными системами (и командами) не управлял и поэтому осторожно предположу, что, наверное, технически, можно сделать систему проще, но учитывая, что над ней работают десятки независимых команд — это, наверное, минимальный доступный объем сложности и допустимый объем ошибок. Было бы интересно услышать мнение «настоящих сварщиков».

Коллеги советуют замечательную статью на тему безопасности сложных систем. Она не дает ответов, но предостерегает от попытки найти «root cause», «причину аварии» и предлагает посмотреть на безопасность систем по-новому, через другие линзы, чем я привык. Очень рекомендую.

ФБ начал возвращаться в строй. Сетевая связность восстановлена, заработал DNS. Приложения, скорее всего, тоже скоро очухаются.

Вот хороший обзор ситуации и объяснение механизма падения от Cloudflare https://blog.cloudflare.com/october-2021-facebook-outage/

Теперь ждём технического пост-мортема от фб.

Пойду спать, спокойной ночи, друзья.

Хорошая статья про будущее интернет-протоколов.

Рассматриваются:

- TLS 1.3 - крупный релиз новой версии протокола, который принято называть HTTPS. Во-первых, сейчас HTTPS можно сломать, установив на компьютер клиента корневой сертификат атакующего. После этого можно слушать и изменять вообще всю шифрованную переписку компьютера. Так делает антивирус Касперского, так хотело делать правительство Казахстана. Вообще, классный способ - «установи сертификат для получения доступа к сайту госуслуг», например, и все - контора довольна. Механизм эфемерных ключей делает такую атаку невозможной. Интересно, что некоторые организации негодуют, банки, например, которым нужно мониторить весь трафик. Во-вторых, HTTPS-сайты начнут открываться существенно быстрее. При не-шифрованной передаче сайт начинает загружаться сразу после запроса, при шифрованной - серверу и вашему компьютеру нужно сначала договориться о ключах шифрования. Новая версия TLS позволяет делать это всего раз в неделю, то есть вы почувствуете разницу на страницах, которые открываете часто;
- HTTP/2 - свежий протокол (2015), позволяет запросить несколько файлов параллельно, не создавая очередь, что сильно ускоряет загрузку. Не работает без шифрования;
- QUICK - протокол для ускорения загрузки страниц, не работает без шифрования;
- DNS over HTTP (DOH). Подмена DNS ответов - самый простой способ блокировки сайтов. Протокол DNS устроен так, что его тривиально заблокировать или подменить ответ сервера. В протоколе DOH это невозможно, а заблокировать сервер с DOH можно только заблокировав HTTPS сайт этого сервера. Представьте, если google.com начнёт предоставлять сервис DOH. Половина механизмов блокировки можно будет выкинуть на свалку. Дополнительный кайф - через DNS легко подсмотреть, на какие сайты вы заходите, DOH и от этого защищает тоже.

Как видите, все шифрованное. Ещё лет 5 и метод «сижу на трубе, все контролирую» перестанет работать.

Вообще, большая часть общения сейчас происходит в соцсетях - именно с ними нужно научиться договариваться Роскомнадзору, чтобы быть эффективным цензором. И быть готовым заблокировать соцсеть или поисковик целиком, если они не идут навстречу. Конференции вроде недавней китайской, где главы крупнейших IT-корпораций «целуют кольцо» - влажная мечта Жарова. Слава богу, для такого «сотрудничества» нужно быть одним из крупнейших рынков и быстрорастущей экономикой, имеющей крепкие «отечественные» аналоги всех западных сервисов. Тогда у цензора есть мощный рычаг. У российского правительства, насколько я понимаю, такого рычага нет, так что особо сильно прогибаться под хотелки русских цензоров западные компании не будут. Аминь.

30 января на несколько часов сломались сайты .ru

Это произошло из-за проблем с DNS — одним из старейших протоколов интернета, которым мы пользуемся до сих пор.

Обсудили с сотрудником ICANN Мишей Анисимовым, как он устроен и что пошло не так. Слушайте здесь: Apple, Google, Яндекс, Spotify, Castbox, Overcast, веб-версия.

Регистратор tierra.net без предупреждений выключил домен Zoho.com из-за 3 (трех) жалоб на спам и не выходил на связь. Эксперты утверждают, что спама с их адресов, на самом деле, в последнее время многовато, но это не повод выключать сервис, у которого, на минуточку, 40 миллионов пользователей.

Zoho.com — конкурент корпоративных пакетов Google и Microsoft; у них полный комплект всех приложений, от почты до документов. В Zoho можно, например, создавать приложения без кода. Zoho creator — старый и уродливый, но рабочий инструмент.

CEO Zoho смог быстро поднять волну хайпа и выйти на регистратора, так что те восстановили доступы в течении часа, но из-за кеширующей природы DNS (серверы экономят запросы и запоминают ответы надолго), у некоторых людей сайт не работает до сих пор.

Очередной урок нам всем — проверить, что домены у приличного регистратора. Я пользуюсь namecheap, а если нужен экзотический tld (типа .ke) — то gandi.net. Ах да, не держите ничего важного на .ru — только редиректы, только хардкор.

Разработчики обычно имеют запущенными у себя на компьютере локальные базы: elasticsearch, redis и многие другие. Частенько это может быть слепок с продакшен базы, с настоящими важными данными внутри. Так вот, придумали хитрый способ вытащить эти данные просто заманив разработчика на вредоносную web-страницу. Браузеры пытаются защитить пользователей с помощью множества механизмов, так что внутри атаки хитрый трюк с DNS. Понятно, что практически это очень маловероятный вектор атаки, но уж очень элегантно.

http://bouk.co/blog/hacking-developers

Хорошие новости: майкрософт планирует внести изменения в работу DNS в Windows, которые помогут бороться с цензурой и повысят нашу безопасность в сети.
Что такое DNS? Когда вы даете команду открыть ютуб, ваш компьютер или телефон сначала узнают числовой адрес ютуба (74.125.130.91, айпи) в «телефонной книге интернета» называемой DNS.

С DNS есть две проблемы:
1. Общение с DNS-серверами никак не защищено — значит хакер может подслушать, на какие сайты вы заходите и даже увести вас на поддельный сайт вместо настоящего.
2. DNS-серверы обычно предоставляются провайдерами. Владелец DNS-сервера видит, какие сайты вы посещаете и может выборочно блокировать к ним доступ, просто отдавая вместо настоящего числового адреса адрес сайта-заглушки. Это самый дешевый способ блокирования интернета, им пользуются многие русские провайдеры; именно так Турция блокировала твиттер во время массовых протестов.

Microsoft обещает решить обе проблемы. Сначала первую, путем поддержки шифрованного протокола DNS over HTTPS, а затем вторую — предлагая обычным пользователям выбрать, каким DNS-сервером они хотят пользоваться.

Объяснить простому человеку, зачем выбирать DNS-сервер и какие последствия имеет этот выбор — непростая UX-задача. В профессиональных кругах мы давно обсуждаем эти вопросы.

Не мы одни понимаем важность DNS. 🇺🇸 Недавно американские провайдеры были пойманы на том, что лоббировали конгрессменов США против шифрованного DNS (очень грязно, перетасовывая и перевирая факты) — они собирают и продают данные о том, какие сайты посещают их пользователи. 🇬🇧 Правительство Великобритании выступает против шифрования DNS — это помешает им блокировать сайты. На прошлой встрече IETF меня круто осадила девушка-представитель правительства Великобритании, красноречиво предъявив аргумент «а как же защита детей», на который я не нашелся как быстро ответить. 🇷🇺 Ну и конечно, «суверенная DNS-инфраструктура» есть в «законе об изоляции рунета».

Непривычно и очень круто, что Microsoft первыми из технических гигантов начали публично говорить об этом аспекте интернет-безопасности.

P.S. Привет из Сингапура, с очередной встречи инженерного совета интернета IETF. Картинка для привлечения внимания с балкона, где написан этот пост.