От редактора блога Google: Интересовались ли вы когда-нибудь тем, как инженеры Google Cloud Technical Solutions (TSE) занимаются вашими обращениями в техподдержку? В сфере ответственности инженеров технической поддержки TSE лежит обнаружение и устранение указанных пользователями источников проблем. Некоторые из этих проблем довольно просты, но иногда попадается обращение, требующее внимания сразу нескольких инженеров. В этой статье один из сотрудников TSE расскажет нам про одну очень заковыристую проблему из своей недавней практики — случай с пропадающими пакетами DNS. В ходе этого рассказа мы увидим, каким образом инженерам удалось разрешить ситуацию, и что нового они узнали в ходе устранения ошибки. Мы надеемся, что эта история не только расскажет вам о глубоко укоренившемся баге, но и даст понимание процессов, проходящих при подаче обращения в поддержку Google Cloud.



Устранение неполадок это одновременно и наука, и искусство. Все начинается с построения гипотезы о причине нестандартного поведения системы, после чего она проверяется на прочность. Однако, прежде чем сформулировать гипотезу, мы должны четко определить и точно сформулировать проблему. Если вопрос звучит слишком расплывчато то вам придется как следует все проанализировать; в этом и заключается «искусство» устранения неполадок.

Прим. перев.: это перевод публичного постмортема из инженерного блога компании Preply. В нем описывается проблема с conntrack в Kubernetes-кластере, которая привела к частичному простою некоторых сервисов продакшна.

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


Это не DNS
Не может быть что это DNS
Это был DNS

Данная статься не является ни рекламой ни антирекламой как сервиса REG.RU, так и упомянутых ниже других компаний. Я не являюсь сотрудником REG.RU или заинтересованной стороной, суть написанного несет исключительно развлекательно-ознакомительный характер.

Итак, поехали!

Продолжаем говорить об истории DNS. Обсуждаем точку зрения экспертов и компаний, выступающих за и против внедрения протоколов DNS over HTTPS и DNS over TLS, а также спецификации EDNS.

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

Предисловие

Решил как то написать снифер DNS, так сказать just for fun. Просто посмотреть какие адреса в моей системе резолвятся. Протокол старый, документации должно быть много. Много. Но все статьи очень не полные и заканчиваются, на самом интересном моменте. Да, есть rfc1035, но хотелось бы на русском и с пояснениями. Собственно по накоплению опыта и разбора пакета и созрела данная статья. Она рассчитана на тех, кто понимает, что такое DNS и понимает, что бывают запросы и ответы. Для тех, кто хочет немного разобраться в структуре данного протокола.

Статья предполагает теорию, а потом немного практики.

Группа инженеров предложила заменить корневые DNS-серверы peer-to-peer сетью на базе блокчейна. Рассказываем, что об этой инициативе думает ИТ-сообщество.

Система доменных имен (DNS) является подобием телефонной книги, которая переводит удобные для пользователя имена, такие как «ussc.ru», в IP-адреса. Так как активность DNS присутствует практически во всех сеансах связи, независимо от протокола. Таким образом DNS логирование является ценным источником данных для специалиста по информационной безопасности, позволяющее им обнаруживать аномалии или получать дополнительные данные об исследуемой системе.

В 2004 году Флорианом Ваймером был предложен такой метод логирования, как Passive DNS, позволяющий восстанавливать историю изменений DNS данных с возможностью индексации и поиска, которые могут предоставлять доступ к следующим данным:

• Доменное имя
• IP-адрес запрошенного доменного имени
• Дату и время ответа
• Тип ответа
• и т.д.

Данные для Passive DNS собираются с рекурсивных DNS-серверов встроенными модулями или с помощью перехвата ответов от DNS-серверов, ответственных за зону.

Рисунок 1. Passive DNS (взят с сайта Ctovision.com)

Тема довольно изъезжена, знаю. К примеру, есть отличная статья, но там рассматривается только IP-часть блоклиста. Мы же добавим еще и домены.

В связи с тем, что суды и РКН блокируют всё направо и налево, а провайдеры усиленно пытаются не попасть под штрафы, выписанные "Ревизорро" — сопутствующие потери от блокировок довольно велики. Да и среди "правомерно" заблокированных сайтов много полезных (привет, rutracker)

Я живу вне юрисдикции РКН, но на родине остались родители, родственники и друзья. Так что было решено придумать легкий для далеких от ИТ личностей способ обхода блокировок, желательно вовсе без их участия.

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

Различные аспекты эксплуатации DNS уже неоднократно затрагивались автором в ряде статей опубликованных в рамках блога. При этом, основной акцент всегда делался на повышение безопасности этого ключевого для всего Интернет сервиса.

До последнего времени, несмотря на очевидность уязвимости DNS трафика, который, до сих пор, по большей части, передаётся в открытом виде, для злонамеренных действий со стороны провайдеров, стремящихся повысить своих доходы за счёт встраивания рекламы в контент, государственных силовых органов и цензуры, а также просто преступников, процесс усиления его защиты, несмотря на наличие различных технологий, таких как DNSSEC/DANE, DNScrypt, DNS-over-TLS и DNS-over-HTTPS, буксовал. И если серверные решения, а некоторые из них существуют уже довольно долгое время, широко известны и доступны, то поддержка их со стороны клиентского программного обеспечения оставляет желать много лучшего.

Домашний роутер (в данном случае FritzBox) умеет многое регистрировать: сколько трафика когда ходит, кто с какой скоростью подключён и т.п. Узнать, что скрывается под непонятными адресатами, мне помог сервер доменных имён (DNS) в локальной сети.

В целом, DNS оказал положительное влияние на домашнюю сеть: добавил скорость, устойчивость и управляемость.

Ниже приведена диаграмма, которая вызвала вопросы и необходимость разбираться в происходящем. В результатах уже отфильтрованы известные и рабочие запросы к серверам доменных имён.

По какой причине каждый день опрашиваются 60 непонятных доменов во время, когда все ещё спят?

Каждый день опрашиваются 440 неизвестных доменов в активное время. Кто это такие и что они делают?

Я не имею аккаунта в фейсбук и не пользуюсь твиттером. Несмотря на это, каждый день я читаю новости о принудительном удалении публикаций и блокировке аккаунтов в популярных социальных сетях.

Сознательно ли социальные сети берут на себя ответственность за мои публикации? Изменится ли это поведение в будущем? Может ли социальная сеть отдать нам наш контент, и какие для этого требуются изменения в социальных сетях? Как возможные изменения повлияют на рынок IT?

TL;DR: начиная с февраля 2020 года, DNS-серверы, не поддерживающие обработку DNS-запросов как по UDP, так и по TCP, могут перестать работать.

Это продолжение поста «Что-что случится 1 февраля?» от 24 января 2019 г. Читателю рекомендуется бегло ознакомиться с первой частью истории, дабы понимать контекст.

Бангкок, вообще, место на любителя. Конечно, там тепло, дёшево, и кухня интересная, и визы половине населения Земли туда не нужно получать заблаговременно, однако к запахам надо ещё привыкнуть, а городские улицы заставляют в лучшем случае вспомнить классику киберпанка.

В частности, пейзаж слева наблюдается недалеко от центра столицы Таиланда, через одну улицу от отеля Shangri-La, где 12-13 мая прошло 30-е собрание организации DNS-OARC, некоммерческой организации, занимающейся вопросами безопасности, стабильности и развития системы доменных имён DNS.

Слайды из программы DNS-OARC 30 в принципе рекомендуются к изучению всем, кого интересует работа DNS, однако самое, пожалуй, интересное — это то, чего в слайдах не было. А именно, 45-минутный круглый стол с обсуждением результатов DNS Flag Day, случившегося 1 февраля 2019 года.

А самое интересное в круглом столе — решение, что практика DNS Flag Day будет продолжена.

Встала однажды передо мной задача, отдать одному из клиентов право на редактирование PTR-записей отданной ему подсети /28. Автоматизации для редактирования настроек BIND извне у меня нет. Поэтому я решил пойти другим путем — делегировать клиенту кусок PTR-зоны подсети /24.

Казалось бы — что может быть проще? Просто нужным образом прописываем подсеть и направляем на нужный NS как это делается с поддоменом. Но нет. Не так все просто (хотя на деле вообще примитивно, но интуиция не поможет ), поэтому я и пишу эту статью.

Кто захочет сам разобраться, тот может почитать RFC
Кто хочет готового решения, добро пожаловать под кат.

Пост описывает шаги для автоматизации управления SSL сертификатами от Let's Encrypt CA используя DNS-01 challenge и AWS.

acme-dns-route53 — это инструмент, который позволит нам реализовать данную фичу. Он умеет работать с SSL сертификатами от Let's Encrypt, сохранять их в Amazon Certificate Manager, использовать Route53 API для реализации DNS-01 challenge, и, в конце, пушить уведомления в SNS. В acme-dns-route53 так же присутствует built-in функционал для использования внутри AWS Lambda, и это то, что нам нужно.

10 апреля 2019 года GitHub без объявления войны удалил репозиторий популярной утилиты GoodByeDPI, предназначенной для обхода государственных блокировок (цензуры) сайтов в Интернете.


UPD от 13.04.2019
Сухие факты. Недоступен не только репозиторий, а весь аккаунт целиком. Хотя для любого постороннего пользователя всё выглядит, как удаление, на самом деле — это shadowban, о чем сообщил автор. Далее он признался, что намеренно сохранил магнет-ссылки на видео со сценами убийств в Новой Зеландии на публичной странице своего аккаунта. Позже экспериментально выяснили, что блокировку автору программы для борьбы с блокировками дали автоматические алгоритмы. Но было и предположение, что бан был за спам с диапазона IP, к которому принадлежит автор. ТЧК

UPD от 16.04.2019
Судя по всему, shadowban с аккаунта ValdikSS снят, все репозитории восстановлены. Причина была в ссылках на видео со стрельбой.

Что такое DPI, как связан с блокировками и зачем с ним бороться (по версии автора):

Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.

Вчера, полностью серьезно и без каких-либо шуток-прибауток, компания Cloudflare анонсировала свой новый продукт — VPN-сервис на базе DNS-приложения 1.1.1.1 для мобильных устройств с использованием собственной технологии шифрования Warp. Основной фишкой нового продукта Cloudflare является простота — целевой аудиторией нового сервиса являются условные «мамы» и «друзья», которые не способны самостоятельно купить и настроить классический VPN или не согласны устанавливать прожорливые в плане энергопотребления сторонние приложения от неизвестных команд.



Напомним, ровно год и один день назад — 1 апреля 2018 года — компания запустила свой публичный DNS 1.1.1.1, аудитория которого за прошедший период выросла на 700%. Сейчас 1.1.1.1 борется за внимание публики с уже ставшим классическим DNS от Google по адресу 8.8.8.8. Позже, 11 ноября 2018 года, CloudFlare запустили мобильное приложение 1.1.1.1 для iOS и Android и вот теперь, на его базе запускается и «VPN по кнопке».

Всем привет! Сегодня мы бы хотели рассказать об одной старой и почти всеми забытой атаке под названием DNS rebinding. Первые разговоры о ней начались еще в 2007 году, однако тогда эксперты из области практической информационной безопасности не уделяли ей должного внимания в связи с особенностями эксплуатации этой атаки, а также мало ощутимыми, как тогда казалось, последствиями. Сегодня мы попробуем убедить в обратном их и вас, в частности, продемонстрировав, что в современном мире эта атака обрела второе дыхание и более не кажется такой безобидной.

Понесло пакет по кочкам в дальний лес за DNS…
Л. Каганов "Гамлет на дне"

При разработке сетевого приложения иногда возникает необходимость запустить его локально, но обращаться к нему по реальному доменному имени. Стандартное проверенное решение — прописать домен в файле hosts. Минус подхода в том, что hosts требует чёткого соответствия доменных имён, т.е. не поддерживает звёздочки. Т.е. если есть домены вида:

dom1.example.com,
dom2.example.com,
dom3.example.com,
................
domN.example.com,

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

*.example.com

Решением проблемы может стать использование собственного DNS-сервера, который будет обрабатывать запросы в соответствии с заданной логикой. Такие сервера есть, и вполне бесплатные, и с удобным графическим интерфейсом, например CoreDNS. Так же, можно менять DNS-записи на роутере. Наконец, воспользоваться сервисом наподобие xip.io, это не совсем полноценный DNS-сервер, но для некоторых задач отлично подойдёт. Словом, готовые решения существуют, можно использовать и не заморачиваться.

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

Не то что бы, конечно, это было первое обсуждение вопроса на Хабре. Однако до сего момента в основном обсуждались последствия, в то время как, на наш взгляд, куда интереснее первопричины.

Итак, на 1 февраля запланирован DNS Flag Day. Эффекты этого события будут наступать постепенно, однако всё же быстрее, чем некоторые компании сумеют к нему адаптироваться.

Что это такое? Говоря простым языком, это манифест основных мировых разработчиков DNS-серверов: компаний CZ.NIC, ISC, NLnet Labs и PowerDNS.

Производители программного обеспечения DNS уже давно столкнулись с проблемой: развитие системы доменных имён, добавление в неё новых функций, требующихся клиентам, решение вопросов безопасности — все эти процессы радикально замедляются ввиду кооперативной структуры системы DNS и необходимости поддерживать архаичные серверы, реализующие устаревшие версии протоколов (и даже это зачастую делающие с ошибками).