Очень популярное заблуждение: DNS использует только UDP. Это заблуждение постоянно мешает на практике. Конечно, протокол UDP является основным протоколом обмена данными между клиентами и серверами в DNS. Это так. Однако UDP используется при наличии возможности, а DNS, как система, строго требует доступности серверов и по TCP. Причём, TCP является ничуть не менее “стандартным” протоколом для DNS. То есть, необходима поддержка и UDP, и TCP.
Хрестоматийный исторический пример использования TCP вместо UDP в DNS, это превышение максимального объёма данных, которые удаётся передать по UDP. Здесь часто упоминают 512 байтов, как предельное количество. Но, опять же, то и дело упускают контекст, к которому лимит в 512 байтов относится. Эти знаменитые 512 байтов, во-первых, происходят из принципов фрагментации пакетов в IP-сетях, – так-то в UDP можно передать гораздо больше, – да ещё и относятся, как ограничение, конкретно к классическому DNS: то есть, из-за 512 байтов в Интернете 13 логических корневых серверов DNS, например. Сетевые детали оставим для другой записки, а в этой важно отметить, что и лимит давно не 512 байтов, потому что есть расширение под общим названием EDNS, позволяющее задать другие границы данных ответа сервера, и возможность увеличения размера UDP-ответов пакета никак не отменяет требований по TCP.
Это всё весьма упрощенное описание. За DNS скрывается очень сложная технология, непосредственно использующая множество весьма и весьма нетривиальных особенностей в своих протоколах. Очень большой ошибкой будет посчитать, что DNS – это “запрос-ответ” про “IP-адрес”. Это только “понятийное ядро” DNS на самом базовом уровне возможно описать как элементарный протокол “запрос-ответ”. При изучении же деталей придётся быстро столкнуться с неожиданными артефактами. Например, с тем, что в DNS есть сжатие строк в DNS-сообщениях, куча хитрых статусов и флагов. Реально работающая система изобилует неожиданными “краевыми случаями”. Вот, кстати, один из примеров: рандомизация регистра символов в DNS. И это, заметьте, тут ещё ничего не сказано про DNSSEC.
В общем, вернёмся к TCP/UDP. Верная интерпретация такая: если DNS-ответ имеется, но не получается доставить его полностью по UDP, то система должна использовать TCP. Следовательно, должен быть TCP-доступ. И вовсе не только между авторитативными серверами для трансфера зоны.
К сожалению, сплошь и рядом продолжают фильтровать и отключать TCP-доступ даже к авторитативным серверам DNS, мотивируя это тем, что, мол, “DNS работает по UDP”, а поэтому прочий доступ нужно закрыть “для безопасности” (хотя, казалось бы, при чём здесь метод “порты закрыл – сервер в безопасности”?). Это неправильно и плохо: резолверы могут штатно подключаться к DNS-серверам по TCP, если им не удаётся работать по UDP, а в DNS описан типовой механизм (Truncated bit), позволяющий сообщить клиенту (резолверу), что нужно переключиться на TCP. Но этот только возможный способ. Резолвер, вполне штатно, может самостоятельно перейти на TCP, если этого требует контекст запроса и сетевая конфигурация. Так что DNS работает и по TCP тоже.
Комментировать »
Добавил на страницу “Избранное” очередную порцию избранных записок:
Комментировать »
Интернет не только работает по IP, но этот протокол и определяет Интернет. Часть IP – это IP-адреса: номера, используемые для синтеза самого протокола. Интересно, что практическому восприятию IP-адресов в Интернете (не в локальной сети) соответствует несколько уровней.
Уровень первый: IP-сеть. То есть, IP-адреса позволяют проиндексировать узлы “одноранговой сети”, сопоставив каждому узлу номер, служащий адресом, по которому отправляются “пакеты данных”. Это самый простой уровень, он не так близок к логике IP, как можно подумать, но именно этот уровень используется в совсем популярных статьях для объяснения понятия “IP-адрес”: здесь IP-адрес виден как номер сетевого узла.
Уровень второй: межсетевой обмен данными. Оказывается, в Интернете существуют автономные системы. Более того, Интернет (с прописной буквы), как глобальную сеть, невозможно определить без использования хотя бы двух автономных систем. На этом уровне, – то есть, с точки зрения межсетевой маршрутизации, – IP-адреса видны как некие “точки” на сетевой границе автономной системы. Собственно, IP-адреса просто возникают на границе автономной системы. Как там устроено внутри, какой именно узел адресуется данным номером во внутренней логике автономной системы – не ясно: IP-адрес лишь задаёт точку входа (и выхода, если это транзитная автономная система).
Уровень третий: произвольные идентификаторы. IP-адрес является лишь произвольным идентификатором, по которому через сетевой порт может отвечать не менее произвольное устройство, в том числе, совсем не тот узел, как можно было бы подумать. Здесь уже граница проводится по сетевому интерфейсу. И действительно, технически, пакеты, адресованные какому-нибудь IP-адресу в Интернете, могут быть перехвачены произвольным промежуточным узлом. Это, понятно, не относится к IP, как к протоколу. Однако, если ваш компьютер отправляет пакет по адресу A.B.C.D, полагая, что это адрес “сервера Google”, то из этого вовсе и не следует, что в конкретном сетевом сегменте по данному адресу отвечает действительно “сервер Google”. Конечно, у данного подхода есть и продолжение: почему бы не вспомнить, что IP-адрес можно заменять на уровне сокета, в операционной системе? Но тут уже понятие вычислительной сети совсем “виртуализируется”, поскольку физический уровень полностью замыкается внутри одного устройства.
Комментировать »
В новостях попался забавный фрагмент, речь идёт про обучение студентов инженерных специальностей:
Или одно из семи новых направлений, где умение профессионально писать код не обязательно — кибербезопасность, Data Science, системный и бизнес-анализ, DevOps, SRE, а также тестирование ПО (QA).
“Умение профессионально писать код не обязательно”. Наверное, в направлении “бизнес-анализ”, действительно, не требуется умение писать код, тем более “профессионально”. Но во всех остальных перечисленных направлениях – писать код просто необходимо. Хотя, конечно, написание кода там совсем не является самоцелью, так что, возможно, это имелось в виду под “профессионально писать”. Но и для программиста написание кода не является самоцелью. Кстати, “писать код” и “быть программистом” – вовсе не эквивалентные понятия, хоть первое и является необходимым условием для второго. Впрочем, времена сейчас меняются: скажут, что LLM ИИ и так напишет триллионы строк кода.
Комментировать »
Кстати, в рамках свежего обновления, на сервис ТЦИ audit.statdom.ru, кроме прочего, добавлен вывод HTTPS-записи (при наличии, см. скриншот) и определение поддержки MLKEM+X25519 для TLS-узлов (см. второй скриншот).
На скриншоте – HTTPS-запись DNS-зоны, размещённой на сервисе Cloudflare. Можно видеть сведения об IP-адресах, указание на то, что присутствует ECH-конфигурация (сама конфигурация пока что не выводится).
Обнаружение поддержки постквантовой гибридной криптосистемы MLKEM+X25519 выполяется TLS-сканером отдельно (естественно, это, пока что, редкая криптосистема, если распространённость определять по количеству TLS-узлов).
Комментировать »
Немного занятной и техничной практики DNS. Если взять зону kommersant.ru, то нетрудно выяснить, что с этой зоной что-то сильно не так. Вот “покрасневший” скриншот из отчёта открытого сервиса audit.statdom.ru:
Почему тут указаны только “адреса”, которые отмечены как недоступные? Во-первых, это не адреса, а имена хостов (хостнеймы), которые выглядят похожими на IP-адреса, но намётанный глаз сразу обнаружит подвох: всё выдаёт крайняя справа точка, отделяющая корневой домен; это так называемый FQDN – Fully Qualified Domain Name (“полное имя домена”). Во-вторых, серверы имён, обозначенные таким образом, доступны быть не могут, поскольку в глобальной DNS нет имени первого уровня “20.” (две цифры – 2 и 0).
Между тем, если попробовать зайти на соответствующий апексу зоны веб-сайт kommersant.ru браузером, то, скорее всего, сайт откроется. Получается, что всё работает? Нет, далеко не всё. Но это лишь очередное подтверждение того, что DNS, как сервис и совокупность технологий, в сочетании с вебом, обладает очень высокой степенью устойчивости к ошибкам настройки (кроме, конечно, DNSSEC).
Посмотрим, как же настроена зона kommersant.ru на момент написания данной записки. В домене верхнего уровня RU зона делегрована на два сервера имён (NS) с именами ns.kommersant.ru. и ns5.kommersant.ru., что, скажем, подтверждается следующим фрагментом скриншота того же отчёта:
Поскольку это так называемые “субординатные” имена NS, – то есть, находящиеся в той же зоне, которая делегируется, – серверы зоны RU возвращают соответствующие glue-записи (в отчёте они не показаны). Glue-записи содержат IP-адреса для имён делегирования (ns.kommersant.ru. и ns5.kommersant.ru.). В DNS, glue-записи необходимы для того, чтобы исключить возможность бесконечной рекурсии. Представьте, что зона test.ru делегирована на ns.test.ru. Как же определить IP-адрес ns.test.ru? Ведь для его определения нужно знать адреса NS-ов зоны test.ru, а чтобы их знать, нужно опросить зону test.ru. Как найти адреса? Верный ответ – никак не найти, если бы только не было glue-записей, которые-то и приносят нужные адреса сразу.
Почему здесь вообще возникает такая проблема с аресами/именами? Потому, что в качестве значения DNS-записи NS могут быть указаны только имена хостов. Но соединение и обмен данными в глобальном Интернете происходят по IP. То есть, для отправки запросов и получения ответов нужны именно IP-адреса. Можно ли всё же указать IP-адреса в NS-записях? Нет, нельзя. Причина в том, что значения записей в DNS не могут подразумевать какой бы то ни было протокол обмена данными. Это очень важный и логичный момент: DNS превратилась бы в непонятную путаницу, если бы какие-то дополнительные сведения об установлении соединения “подразумевались” бы: в той же NS-записи – получаем то адрес, то хостнейм, то “какие-то минусы”, то “здесь админы рыбу заворачивали”. Заметьте, сюда ещё накладывается и тот занимательный факт, что вообще невозможно вне контекста отличить запись IPv4-адреса от хостнейма. В практике DNS есть много случаев, когда тот или иной протокол доступа, да ещё и с параметрами, прямо указывается, но корректно это делается только при помощи префиксов в самом имени, например: _443._tcp.name.test.ru. (обратите внимание: предыдущая DNS-строка – не хостнейм!).
Итак, NS-запись должна содержать имя хоста, соответствующее серверу имён. Для разрешения возможных циклов – предусмотрены glue-записи.
Однако доверенным источником полного списка серверов имён для зоны является не делегирующий сервер, не glue-записи, а ответ авторитативного сервера зоны на запрос NS. По этой причине сервис тестирования DNS-узлов получает список этих узлов с авторитативного сервера. Ну, или пытается получить. Серверы, указанные для kommersant.ru в списке делегирования, на запрос NS возвращают те самые “подложные” хостнеймы, сформированные из IP-адресов четвёртой версии. То есть, так указано в файле зоны. Указано неверно. Распространённая ошибка. Видимо, ничего не поделать. Отличить тут адрес от хостнейма программное обеспечение не может, поэтому DNS-сервер будет отвечать тем, что ему написано. А написаны, как уже указано выше, заведомо “неразрешимые” имена (нет, это не IP-адреса; IP-адреса нельзя указывать в NS-записях, поэтому резолвер никак и не может понять, что это, якобы, “IP-адреса”, потому что это хостнеймы).
Почему же работает веб-сайт? Вот почему. Для большинства сценариев доступа к вебу нужен IP-адрес, который передаётся в A-записи DNS. По IP-адресам из glue-записей для обсуждающейся зоны kommersant.ru отвечают серверы имён, которые возвращают A-записи, содержащие корректный и доступный IP-адрес, который указывает на веб-узел. И тут многое зависит от рекурсивного резолвера. Если этот резолвер использует непосредственно адреса из glue-записей для того, чтобы запросить A-записи, то всё сработает. Но glue-записи небезопасно кэшировать – кэшировать следовало бы хотя бы минимально проверенные значения NS, которые требуется достать с авторитативных серверов. Если резолвер попробует получить список NS корректным способом, то он обнаружит дефектные записи, после чего попробует отправить ещё несколько запросов и, скорее всего, всё же найдёт A-запись, чтобы вернуть её клиенту. То есть, резолвер, обычно, настроен так, чтобы хоть что-то достать из DNS (не всегда это правильный выбор, поскольку регулярно служит фундаментом для целевых атак). Так что, спрашивая и переспрашивая, игнорируя и как-то исправляя ошибки в зоне, но резолвер, в большинстве случаев, сможет найти IP-адрес, чтобы потом по этому адресу попробовал подключиться браузер, если только способ достать данный IP-адрес существует. Что же касается других функций DNS – ну, они в данной зоне просто недоступны (тем более, что упомянутые серверы имён не поддерживают современный EDNS-доступ вообще).
Вот. У подобной некорректной настройки DNS есть ещё много неприятных побочных эффектов, связанных с надёжностью и безопасностью. А ведь существует ещё и QNAME Minimization.
(Недавно я описывал другую занятную ошибку настройки DNS, из “дикой природы”, наблюдающуюся в куда более популярной зоне vk.com. Представьте, кстати, куда все эти интернеты прикатятся, если DNSSEC, – несравнимо более требовательная к уровню аккуратности технология, – вдруг получит максимальное распространение.)
Комментировать »
Google, периодически, даже для веб-интерфейса электронной почты, поддерживаемой в рамках GoogleApps, начинает спрашивать телефонный номер, который, якобы, нужен “для повышения безопасности”. Повышение безопасности планируется проводить отправкой кода на указанный телефонный номер (SMS, звонком, может, ещё как-то). В некоторых случаях без указания телефонного номера при создании Google-аккаунта вообще не обойтись, это понятно. Но отдельно печалит то, что даже при подключении с правильными реквизитами аккаунта к веб-интерфейсу почты “из других сетей”, кроме привычной “авторизатору” Google, в почту эта система больше через веб не пускает, а настойчиво требует указать телефонный номер. Конечно, там есть другие варианты (дополнительный email-адрес, ещё что-то), но почему-то эти методы не срабатывают и всё опять возвращается к телефонному номеру (возможно, кроме вмешательства технической поддержки, если она там есть – этот путь я не проверял).
Печально это вот почему: уж сколько лет говорится, что телефонный номер – это ресурс оператора связи, который никак не может принадлежать пользователю-абоненту; оператор связи совсем не обязан как-то дополнительно “защищать” конкретный абонентский телефонный номер и телефонный трафик (хоть и может, конечно). Более того, само наличие схем с отправкой простых кодов на телефонные номера нередко приводит к возникновению уязвимостей, вообще не имеющих отношения к телефонии.
Но ничего на этом направлении не меняется: понятно, что Google тоже нужно собирать телефонные номера.
Комментировать »
Иногда можно прочитать, что радар работает “со скоростью света”, поэтому очень быстрый и, таким образом, любая РЛС будет всякую созданную руками современного человека “кинетическую” цель точно обнаруживать заранее и определять траекторию с большим запасом по времени, даже если скорость этой самой цели очень большая (ну, конечно, если та цель отражает радиоволны подходящим способом, но сейчас не об этом). Действительно, если рассматривать “сферический” “радар в вакууме”, то покажется, что зондирующий импульс преодолевает, скажем, 30 километров за, примерно, 0.1 мс (за десятую долю миллисекунды); чтобы сбегать в обе стороны – требуется 0.2 мс. Вроде бы, да, очень быстро.
Но представьте, что вы конструируете практический радар. В ходе конструирования довольно быстро выясняются всякие дополнительные особенности. Например, чтобы отличать собственные зондирующие импульсы среди принимаемого шума, извлекать информацию, нужно эти зондирующие импульсы особым образом модулировать. Модулирование – не только размывает импульсы “по частоте”, но и растягивает по времени. Для защиты от помех, для оптимизации рабочих параметров, требуется использовать довольно сложные схемы модуляции.
С одной стороны, для импульсного радара не очень хорошо, если уже нужно принимать сигнал, а у вас всё ещё передатчики работают, так что сильно “тянуть” зондирующий сигнал не всегда полезно (у радаров с непрерывным излучением – свои преимущества, но и свои особенности: там как раз различные утечки самым прямым образом мешают уменьшению задержек по времени). С другой стороны, оказывается, что для повышения чувствительности и разрешающей способности, для достижения устойчивой селекции сигналов – на приёме требуется некоторый дополнительный интервал времени для работы, условно говоря, разных корреляторов и схем преобразования (Фурье и др.), то есть принимаемый сигнал должен накапливаться, а неудачная обработка приводит к тому, что результат накопления отбрасывается – это потеря времени.
В общем, в процессе конструирования выясняется, что отражение одного обобщённого “сферического” импульса не даёт никакой практически полезной информации в реальном устройстве: из-за потерь в приёмном тракте и общей инертности аппаратуры, принятой энергии недостаточно даже для определения направления, что уж там говорить про измерение, хотя бы, относительной скалярной скорости по доплеровскому сдвигу. А нужно измерять траекторию, что требует некоторого заметного интервала времени даже в идеальных условиях.
И при этом все устройства, входящие в состав радара, обладают задержкой. А в некоторых случаях, это прямо механическая задержка (поворот физической антенны, например, необходимый для определения направления на цель; да, есть чисто электронные способы, но они не всегда доступны, если наблюдать требуется широкий сектор – поэтому-то, между прочим, ставят наборы антенн, направленных в разные стороны).
В общем, даже формирование луча, которому соответствует серия зондирующих импульсов, потребует заметного времени. Если радар стоит на земле, а цель летит со скоростью “всего-то” 3000 м/с, то каждые десять миллисекунд задержки размазывают изображение этой цели на 30 (тридцать) метров. Это, конечно, не так много, если радар наблюдает космический спутник, пролетающий в тысяче километров. Но те же тридцать метров оказываются весьма существенной погрешностью, если вернуться к дистанции в 30 километров, упомянутой в начале записки: пока радар десять секунд “синтезирует и измеряет” траекторию, собирая размытые сигналы, цель уже прибыла в точку назначения.
Пусть скорость света и велика, но приравнивать к ней скорость работы радаров – неверно: особенности аппаратуры создают большие сложности при наведении на быстрые цели, даже если эти цели в сотни тысяч раз медленнее, чем зондирующий импульс. (Это, впрочем, не делает наведение невозможным.)
Комментировать »
RU-CENTER не только увеличил цены, но и радикально переделал панель управления. Недавно некоторое сходство современного RU-CENTER с GoDaddy весьма верно подметили в комментариях. Удивительно, но теперь RU-CENTER даже и панелью сильно напоминает GoDaddy. Надо сказать, я довольно долго пользовался услугами GoDaddy, хоть и в небольших, всё время уменьшающихся, объёмах: так исторически сложилось, ещё с тех давнишних времён, когда тот GoDaddy был сильно другим, но всё равно странным. А потом в GoDaddy мой аккаунт забанили по традиционной теперь причине нахождения в России. Соответственно, оставшиеся ресурсы – отобрали.
Комментировать »
Вот одна из интересных концепций, позволяющих оптимизировать взаимодействие интернет-узлов по разным сессионным протоколам: “при повторном подключении – сразу отправляем полезные данные для приложения”; это вместо сложного этапа установления соединения, требующего отправки и приёма нескольких сообщений, до того, как полезные данные станут доступны приложению.
То есть, если при первом соединении два узла должны выполнить некоторый обмен пакетами по схеме “запрос-ответ-подтверждение”, чтобы на обоих концах “сокета” сформировался синхронный контекст, то почему бы не запомнить контекст на стороне клиента и при повторных соединениях обойтись без дополнительных шагов для формирования нового контекста, а просто отправить вместе с начальным сообщением немедленно и полезные данные?
Пример уровня сетевого транспорта – TCP Fast Open, который, почему-то, известен мало: здесь клиент в рамках первого TCP-соединения, выполняемого по обычной схеме с созданием сессии, получает специальный идентификатор (cookie), чтобы при последующих соединениях сразу начать передачу полезных данных.
В TCP штатно используется схема установления соединения с тремя этапами согласования (SYN, SYN-ACK, ACK), когда передача данных приложению начинается только после завершения всех трёх этапов. И тут уже есть интересный момент, про который, бывает, забывают даже специалисты: вообще-то, данные между узлами в TCP начинают передаваться сразу же, с первым пакетом (SYN), так же, как, скажем, в UDP; потому что если бы данные не передавались (как минимум, заголовки с идентификаторами и параметрами), то и установить соединение было бы невозможно – это очевидно. То есть, с точки зрения возможности “отправить пакет в одну сторону”, TCP не слишком-то отличается от UDP на уровне, так сказать, NOC. Другое дело, что начальная информация TCP, составляющая обмен для установления сессии, не должна быть штатно доступна на уровне абстракции “сокета”. И вот тут-то начинаются отличия от того же UDP. Но сами по себе пакеты TCP вполне могут служить транспортом для “безсессионной” доставки данных.
Вариант Fast Open, если оставить за скобками детали, лишь обобщает эту возможность (о чём прямо написано в RFC), выводя её на уровень того самого “сокета”. Это делается при помощи дополнительной информации (cookie), подтверждающей, что сессия уже была установлена с соответствующими параметрами. Это и есть пример внедрения метода “сразу отправляем полезные данные”. Для реализации аналогичных логических схем в других протоколах используется, конечно, и UDP – посмотрите на WireGuard через Wireshark.
На уровне выше – тоже есть примеры: в TLS 1.3 имеется достаточно продвинутая сокращённая схема установления соединения 0-RTT (Zero Round-Trip Time), где клиент сразу же начинает передачу полезных данных в защищённом виде, если известна дополнительная информация о TLS-сервере, которую можно было получить в предыдущих соединениях (или как-то ещё).
Так что использование одной и той же полезной логической схемы самого верхнего уровня позволяет оптимизировать разные протоколы. Если задуматься, то сюда даже попадает port knocking. Вообще, если клиент и сервер заранее договорились о некотором секрете, то и обмен данными можно свести к отправке “случайных” пакетов со “случайным шумом” по случайным адресам. Пропускная способность, впрочем, будет не велика. Это работает далеко не только для Интернета.
Комментировать »
Кратко этот сайт характеризуется так: здесь можно узнать про технологический прогресс, Интернет, математику, криптографию, авиацию, компьютеры, авиационные компьютеры, вооружения, роботов, вооружение роботов, армии мира, астрономию, космические исследования. И иногда о чём-то ещё (