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. Картинка для привлечения внимания с балкона, где написан этот пост.