Сетевик Джонни // Network Admin

رفتن به کانال در Telegram

Я Сетевик Джонни, моя цель в телеграме рассказать все о сетях в доступной форме! Сотрудничество: @stein_media

نمایش بیشتر

شبکه:Белый хакер روسيا98 433 فناوری و برنامه‌ها16 702

5 810

مشترکین

-124 ساعت

-67 روز

-2030 روز

1 157

نمایش های پست

~ 42424 ساعت

~ 47248 ساعت

19.91%

نرخ مشارکت

اطلاعاتی وجود ندارد

پست های در روز

Ads index

beta

آرشیو پست ها

5 810

А тебе скучно в понедельник?)

5 810

🥷 Джонни вещает: 8 популярных сетевых протоколов с наглядным объяснением Сетевые протоколы работают на разных уровнях модели OSI, это важно знать. 🌜 Эта многоуровневая архитектура обеспечивает стандартизированное взаимодействие между различными программными и аппаратными компонентами в сети. 1. 𝗧𝗖𝗣/𝗜𝗣 — базовый метод передачи информации между устройствами в Интернете. В то время как IP отвечает за адресацию и маршрутизацию пакетов данных, TCP заботится о сборке данных в пакеты, а также о надежной доставке. 2. 𝗛𝗧𝗧𝗣 — играет решающую роль при доступе к веб-сайтам. Он отвечает за получение и доставку веб-контента с серверов конечным пользователям. 3. 𝗛𝗧𝗧𝗣𝗦 — усовершенствованная версия HTTP, HTTPS объединяет протоколы безопасности (а именно TLS) для шифрования данных, обеспечивая безопасный и конфиденциальный обмен между браузерами и веб-сайтами. 4. 𝗙𝗧𝗣 — Как следует из названия, FTP используется для передачи файлов (загрузки и скачивания) между компьютерами в сети. 5. 𝗨𝗗𝗣 — более оптимизированный аналог TCP, UDP передает данные без накладных расходов на установление соединения, что приводит к более быстрой передаче, но без гарантии, что данные будут доставлены или будут в порядке. 6. 𝗦𝗠𝗧𝗣 — движущая сила обмена электронной почтой, которая управляет форматированием, маршрутизацией и доставкой писем между почтовыми серверами. 7. 𝗦𝗦𝗛 — криптографический сетевой протокол, который обеспечивает безопасную передачу данных по незащищенной сети. - Он обеспечивает безопасный канал, гарантируя, что хакеры не смогут интерпретировать информацию путем подслушивания 📠 #Protocol #cheatsheet | 😊 @iscode

5 810

Repost from STEIN: ИБ, OSINT

🥸 Личный VPN: юзер ликует, VLESS смеётся, а РКН плачет. v.2 Представьте: ваш VPN становится невидимкой для РКН, маскируясь под обычный трафик от народного мессенджера Max. Никаких блокировок, никаких подозрений. — В этой статье вы узнаете, как настроить такой «стелс» за 10 минут через удобный 3x-UI интерфейс с учётом последних потуг от регулятора (лазейка есть, и способ в разы дешевле чем Double VPN + gRPC + SelfSNI + бубны + домены с закосом под трафик от сайта и прочая х) ⤷ teletype.in/@secur_researcher/vpn_tutorial #VPN #xHTTP #VLESS | 😈 @secur_researcher

5 810

⚡ Как данные передаются через Интернет? Какое это имеет отношение к модели OSI? Как TCP/IP вписывается в это? 🚠 Семь уровней модели OSI: 1. Физический уровень 2. Канальный уровень 3. Сетевой уровень 4. Транспортный уровень 5. Сеансовый уровень 6. Уровень представления 7. Прикладной уровень #Network #OSI

5 810

🥷 Как работает DNS в Linux. Часть 2: где именно кэшируется DNS в Linux Ядро Ядро Linux может опосредованно “кэшировать” DNS-трафик через подсистему netfilter/conntrack, если используется stateful-фильтрация. Несмотря на то, что UDP — протокол без установления соединения, ядро отслеживает состояние пакетов, относящихся к одному блоку запрос-ответ (например, запрос от [src_ip:src_port] к [8.8.8.8:53] и ожидаемый ответ от [8.8.8.8:53] к [src_ip:src_port]) и временно хранит информацию — по умолчанию около 30 секунд. Это необходимо для NAT и правил вроде iptables -m conntrack --ctstate ESTABLISHED,RELATED. Проверить текущие записи можно командой:

conntrack -L -p udp --dport 53

В списке отобразятся активные DNS-сессии, которые считаются допустимыми до истечения таймаута. Повторные DNS-запросы к тем же адресам в пределах срока жизни этих записей могут быть обработаны в рамках существующей записи состояния. Это не полноценное кэширование DNS-ответов, но conntrack может влиять на поведение сетевого уровня, особенно при диагностике проблем с NAT или firewall. Для удаления записей из таблицы отслеживания соединений можно воспользоваться командой: conntrack -D -p udp --dport 53 Системный уровень 1. systemd-resolved Современные дистрибутивы с systemd часто используют systemd-resolved в качестве основного DNS-клиента, который: - имеет собственный кэш DNS-запросов, включая положительные и (опционально) отрицательные ответы; - поддерживает split DNS (разные DNS-серверы для разных доменов), конфигурируется через systemd-networkd или NetworkManager; - поддерживает DNS-over-TLS (DoT), включая fallback-серверы и DNSSEC; - предоставляет API по D-Bus (org.freedesktop.resolve1), позволяет получать статус, менять настройки и управлять кэшем через resolvectl. 2. nscd (Name Service Cache Daemon) Если запущен nscd, он кэширует результаты NSS-вызовов, включая DNS. Его настройки находятся в /etc/nscd.conf

enable-cache hosts yes
positive-time-to-live hosts 600
negative-time-to-live hosts 20

‼️ Важный момент: nscd устарел и не рекомендуется к использованию в новых системах. В Debian-based дистрибутивах чаще всего его заменяет systemd-resolved, но в RHEL-based дистрибутивах он ещё встречается. 3. Популярные локальные кэширующие резолверы dnsmasq — популярный выбор для локального кэширования(настройка кэша):


cache-size=1000 (cache-size управляет размером кэша. По умолчанию он небольшой (150), и для заметного эффекта его увеличивают до 1000–5000)
neg-ttl=60

unbound — более мощный DNS-рекурсор. Управление кэшем гибкое: Размер кэша задаётся параметром msg-cache-size (отвечает за ответы) и rrset-cache-size (за записи ресурсов):

msg-cache-size: 50m
rrset-cache-size: 100m

TTL кэшированных ответов можно ограничить директивами cache-min-ttl и cache-max-ttl

cache-min-ttl: 30    # минимальный TTL для любых ответов
cache-max-ttl: 86400 # максимальный TTL (24 часа)

bind - распространенный DNS-сервер с поддержкой рекурсивного разрешения и кэширования. Управление кэшем и его мониторинг осуществляется через команду rndc (Remote Name Daemon Control). В конфигурационном файле named.conf можно задавать TTL для кэша и контролировать поведение:

options {
    max-cache-ttl 86400;     // максимальное время жизни кэша (в секундах)
    max-ncache-ttl 3600;     // максимальное время жизни негативных ответов (NXDOMAIN)
};

✋ В следующей части расскажу про уровни приложений и языков программирования, ставьте 👍 #DNS #Linux | 😏 @iscode

5 810

👀 Наглядно показываем принцип работы и область применения восьми самых популярных сетевых протоколов

5 810

5 810

5 810

🔹🔹🔹🔹🔹🔹🔹🔹🔹 Оказался(ась) на этом канале впервые и не знаешь с чего начать? — можешь звать меня Джонни, я буду твоим проводником Этот Telegram-канал — солянка для сетевых инженеров и сисадминов. Здесь мы не ищем тайны, а чиним сети, настраиваем серверы и пишем скрипты, чтобы работалось лучше. Мы соберём пазл из BGP, OSPF, Ansible и Kubernetes, чтобы ты видел картину целиком, а не только красные дашборды. 🕹 Хочешь, чтобы твои сети аптаймились, а скрипты работали с первого раза? Тогда проваливайся глубже в канал и начинай читать. Добро пожаловать! Статьи и методики по использованию: 1. Примеры атак XSS и способов их ослабления 2. Что такое триада КЦД: шпаргалка для начинающих специалистов в сфере кибербезопасности 3. Микросервисная архитектура на примере Python и gRPC 4. Компьютерные сети от А до Я: стек протоколов TCP/IP 5. Основы методологии DevOps 6. «Я тебя по IP вычислю»: как хакеры рассекречивают звенья цепи Tor 7. TCPDump — инструмент для анализа сетевого трафика 8. OSPF — протокол динамической маршрутизации 9. NDP — протокол управления сетевыми узлами IPv6 10. BGP — протокол маршрутизации 11. RIP — протокол маршрутизации 12. DNSSEC — набор расширений для обеспечения безопасности DNS 13. SONET — стандарт передачи данных по оптоволоконным сетям 14. FTP — протокол передачи файлов 15. RDP — протокол удаленного рабочего стола 16. RPC — протокол удаленного вызова процедур Публикации краткого формата: Подборки обучающих материалов: 1. Подборка обучающих материалов по компьютерных сетях 2. Cisco Systems — подборка обучающих материалов 3. 4. 5. 6. 7. 8.

5 810

🥷 Как работает DNS в Linux. Часть 2: все уровни DNS-кэширования В первых частях мы разобрали, как в Linux работает процесс разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Однако если бы каждый вызов требовал нового DNS-запроса, это было бы неэффективно и сильно нагружало как систему, так и сеть. Поэтому используется кэширование. Кэширование DNS может быть везде — в glibc, в systemd-resolved, в браузерах и даже в приложениях на Go. Кэш помогает увеличить скорость работы, но создает дополнительные сложности при отладке. Например: вы меняете DNS-запись, но сервер продолжает ходить по старому IP-адресу. Или, Dig показывает правильный адрес, а curl всё равно подключается к устаревшему. 🌟 В этой серии постов разберем различные уровни кэшей самой системы, приложений и языков программирования, контейнеров, прокси. А также их мониторинг и сброс. 1. Что такое DNS-кэш и зачем он нужен: DNS-кэш — это не единое хранилище, а многоуровневая система механизмов кэширования на разных уровнях системы. Каждый DNS-запрос — это долгий сетевой вызов, поэтому многие компоненты стараются сохранять результаты локально. TTL (Time To Live) — время жизни записи в кэше. Оно указывается в DNS-ответе и определяет, как долго можно использовать сохранённый IP-адрес. Задается обычно в секундах. После истечения TTL необходимо обновить данные. 🕹 Таким образом, кэширование позволяет: - повысить скорость обработки повторных DNS запросов - снизить нагрузку на серверную и сетевую инфраструктуру - обеспечить отказоустойчивость при временной потере соединения - уменьшить задержки в работе приложений — Но у кэширования есть и обратная сторона: устаревшие данные могут стать причиной недоступности сервисов при изменении инфраструктуры. ✋ В следующей части дополним картину темой в каких уровнях работы кэшируются DNS в Linux, ставьте 👍 #DNS #Linux | 😏 @iscode

5 810

🥷 Как работает DNS в Linux. Часть 1: краткое резюме и ключевые моменты DNS-запрос в Linux — это не обязательно запрос к DNS-серверу. Цепочка обращений может включать hosts, NSS, glibc и другие источники. NSS и nsswitch.conf определяют порядок и источники разрешения имён. glibc использует NSS и может кэшировать результаты; musl реализует DNS-резолвинг напрямую с ограниченной поддержкой опций resolv.conf. Resolv.conf управляет настройками резолвера, но может быть изменен динамически. Getaddrinfo() — основной интерфейс для разрешения имен, обрабатывает как DNS, так и другие источники. В разных языках программирования (Go, Java, Python с dns.resolver, Node.js) могут использоваться собственные механизмы DNS-запросов. ✋ В следующей части дополним картину общим представлением того, как устроено кэширование DNS записей — ключевой механизм, который напрямую влияет на производительность, надежность и поведение приложений при смене IP-адресов, ставьте 👍 #DNS #Linux | 😏 @iscode

5 810

114 - размер дополнительных данных, например CNAME, или авторитетные серверы в случае рекурсивного запроса. 5. TCP-соединение по IP

connect(5, ..., sin_addr=inet_addr("130.193.50.59"))

Здесь уже сам curl устанавливает TCP-соединение по IP-адресу, который ему вернула getaddrinfo(). ‼️ Таким образом, когда мы вызываем curl, мы не видим DNS-запросов напрямую — их делает библиотека glibc внутри вызова getaddrinfo(). Но strace позволяет увидеть косвенные признаки:

Среди вызовов будет попытка подключиться к nscd, вызов connect() к DNS-серверу, отправка UDP-пакета через sendmmsg(), а затем — стандартное TCP-соединение по IP:

connect(7, {AF_INET, 172.24.31.107:53}) = 0
sendmmsg(7, [{ "download.astralinux.ru" }]) = 2
recvfrom(7, ...) = ...
connect(5, {130.193.50.59:80}) = 0

Важно отметить, что поведение getaddrinfo() может зависеть от реализации libc. Например, в glibc результаты могут кэшироваться, что влияет на производительность и актуальность данных. #DNS #Linux | 😏 @iscode

5 810

🥷 Как работает DNS в Linux. Часть 1: порядок реализации запросов и приоритеты Важно: если имя найдено на одном из шагов, например, в hosts, последующие источники не используются. В минималистичных системах, таких как Alpine Linux с musl, порядок может отличаться, так как musl не использует NSS и реализует DNS-запросы напрямую, читая /etc/hosts и resolv.conf самостоятельно. Некоторые приложения и языки (например, Go, Java, Node.js) могут использовать собственные DNS-резолверы, полностью игнорируя системные настройки. Для примера проанализируем работу утилиты curl. Команда:

strace -f -e trace=network curl -s download.astralinux.ru > /dev/null
Вывод strace:
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
socketpair(AF_UNIX, SOCK_STREAM, 0, [5, 6]) = 0
strace: Process 283163 attached
[pid 283163] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7
[pid 283163] connect(7, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (Нет такого файла или каталога)
[pid 283163] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7
[pid 283163] connect(7, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (Нет такого файла или каталога)
[pid 283163] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 7
[pid 283163] connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.24.31.107")}, 16) = 0
[pid 283163] sendmmsg(7, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\250\207\1\0\0\1\0\0\0\0\0\0\10download\nastralinux"..., iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=40}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\240\215\1\0\0\1\0\0\0\0\0\0\10download\nastralinux"..., iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=40}], 2, MSG_NOSIGNAL) = 2
[pid 283163] recvfrom(7, "\250\207\201\200\0\1\0\1\0\0\0\0\10download\nastralinux"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.24.31.107")}, [28->16]) = 56
[pid 283163] recvfrom(7, "\240\215\201\200\0\1\0\0\0\1\0\0\10download\nastralinux"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.24.31.107")}, [28->16]) = 114
[pid 283163] sendto(6, "\1", 1, MSG_NOSIGNAL, NULL, 0) = 1
[pid 283163] +++ exited with 0 +++
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
setsockopt(5, SOL_TCP, TCP_KEEPIDLE, [60], 4) = 0
setsockopt(5, SOL_TCP, TCP_KEEPINTVL, [60], 4) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("130.193.50.59")}, 16) = -1 EINPROGRESS (Операция выполняется в данный момент)
getsockopt(5, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
getpeername(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("130.193.50.59")}, [128->16]) = 0
getsockname(5, {sa_family=AF_INET, sin_port=htons(48488), sin_addr=inet_addr("172.24.31.241")}, [128->16]) = 0
sendto(5, "GET / HTTP/1.1\r\nHost: download.a"..., 86, MSG_NOSIGNAL, NULL, 0) = 86
recvfrom(5, "HTTP/1.1 200 OK\r\nServer: nginx/1"..., 102400, 0, NULL, NULL) = 1617

🔍 Что мы видим в этом strace? 1. Попытка использовать NSCD (Name Service Cache Daemon) connect(..., "/var/run/nscd/socket", ...) = -1 ENOENT - Это означает, что glibc сначала пытается использовать кеш имён из NSCD, если он запущен. В системе его нет, и запрос идёт дальше. 2. Вызов socket() и connect() к DNS-серверу

socket(AF_INET, SOCK_DGRAM|..., IPPROTO_IP) = 7
connect(7, ..., sin_addr=inet_addr("172.24.31.107")...)

- Здесь создаётся UDP-сокет для обращения к DNS-серверу, указанному в /etc/resolv.conf. 3. Вызов sendmmsg() — отправка DNS-запросов

sendmmsg(7, [ { "download.astralinux.ru" }, { "download.astralinux.ru" } ], ...)

Здесь отправляются запросы на резолв имени. 4. Ответ от DNS

recvfrom(...) = 56
recvfrom(...) = 114

Теперь IP-адрес известен. 56 - это размер DNS-ответа в байтах, содержащего А-запись (IPv4-адрес)

5 810

🎉 Результаты розыгрыша: 🏆 Победители: 1. Sergey 2. Idi (@kto_v_shkafu) ✔️Проверить результаты

5 810

⚡️ YADRO×SPRINT OFFER: оффер для Network Engineer in Test за 3 дня! Хотите работать в команде, которая создаёт инфраструктуру для дата-центров и обеспечивает надёжность сетевых систем мирового уровня? Мы в поиске специалистов в команду KORNFELD, которая занимается тестированием коммутаторов различных типов и сетевого оборудования YADRO. Инженеры анализируют поведение систем, актуализируют требования, создают сценарии и подходы к тестированию — от функционального до надёжности и отказоустойчивости, а также помогают совершенствовать архитектуру продуктов и пользовательский опыт. 💡 Как всё проходит: 1️⃣ Оставьте заявку до 30 ноября, пройдите HR-скрининг и технический скрининг. 2️⃣ Пройдите техническое и менеджерское интервью. 3️⃣ Получите оффер всего за 3 дня. 🚀 Основные задачи: • Анализ продуктовых требований и подготовка use cases. • Проведение E2E- и failover-тестирования. • Разработка тест-кейсов и тест-планов для нового и уже существующего функционала. • Участие в совместных испытаниях и взаимодействие с командами разработки, L3 и сервиса. 🔥 Для нас важны: • Опыт работы с сетевым оборудованием (Cisco, Huawei, Juniper и др). • Глубокие знания протоколов, применяемых в ЦОДах (BGP, OSPF, VxLAN, VRRP и др.). • Навыки тестирования и траблшутинга. • Внимательность, системность и интерес к сетевым технологиям. 💙 Оставляйте заявку до 30 ноября, присоединяйтесь к инженерному сообществу YADRO и вносите вклад в развитие сетевых технологий будущего!

5 810

🥷 Ищем InfoSec специалистов. Удалёнка, релокейт платим много! Специально для Вас, собираем лучшие вакансии по InfoSec с прямыми контактами в Telegram на канале @it_match_cybersec Подпишись чтобы не упустить свой шанс получить лучший оффер! ➡️ Посмотреть вакансии

5 810

🥷 Кто идёт на Kuber Conf by AOT 4 декабря? Устраиваю розыгрыш 2 билетов на Kuber Conf by АОТ — первую коммьюнити конференцию по K8s в России, которая пройдет 4 декабря в Москве. В программе — только хардкор и реальные кейсы от команд Авито,Т-Банка, Vitastor, Beget, VK Cloud, Yandex Cloud, Selectel и других. 🟣 Изменения в Cluster API без пересоздания машин 🟣 Как строили платформу деплоя в Т-Банке 🟣 Практический deep-dive в CNI chaining 🟣 Безопасный Gatekeeper в архитектуре k8s-in-k8s 🟣 Поддержка Kubernetes в Vitastor 🟣 Karpenter-провайдер своими руками — что внутри 📅 20 ноября в 12:00 выберем 2 счастливчиков. Чтобы участвовать: Вам необходимо подписаться на канал, активировать бот снизу и ждать 20.11. В 12:00 по МСК с помощью бота-рандомайзера будет выбран победитель! Важно: Это именно коммьюнити-движуха, которую организовали VK Cloud, Флант и Yandex Cloud под эгидой будущей Ассоциации облачно-ориентированных технологий (АОТ). Так что скучно не будет. Программа и билеты

5 810

🥷 Как работает DNS в Linux. Часть 1: порядок реализации запросов и приоритеты Вот типичный порядок разрешения имени в Linux при использовании glibc и NSS: 1. Приложение вызывает getaddrinfo(); 2. getaddrinfo() обращается к системе NSS и следует заданному в nsswitch.conf порядку; 3. Если первым указан модуль files, имя ищется в файле /etc/hosts; 4. Если включён модуль dns, NSS вызывает libnss_dns.so, которая обращается к функциям из libresolv; 5. libresolv формирует DNS-запрос через res_query() и отправляет его с помощью res_send() на указанные в resolv.conf адреса DNS-серверов, затем получает и возвращает IP-адрес. #DNS #Linux | 😏 @iscode

5 810

🥷 Как работает DNS в Linux. Часть 1: обработка resolv.conf и что делает res_query() Файл /etc/resolv.conf содержит основные настройки клиента DNS, а именно: список серверов, параметры, search-домены. Например:

nameserver 192.168.1.1
search dev.local
options timeout:2 attempts:3

— Glibc и libresolv парсят его вручную при необходимости. Важные моменты и ограничения: - опции вроде rotate, ndots, timeout и attempts влияют на поведение запроса; - опция rotate используется для циклического выбора серверов из списка nameserver, но она не поддерживается в musl; - search используется для автодополнения, например, если имя db01 не является FQDN, к нему будут по очереди подставляться домены из директивы search.

Важно отметить, что файл resolv.conf может быть динамически изменён DHCP-клиентом, NetworkManager или утилитой resolvconf, что может вызывать путаницу при решении проблем с DNS. Об этом мы поговорим в одной из следующих частей.

Касательно res_query(), это функция из libresolv, вызываемая внутренне в процессе разрешения имени. Она формирует DNS-пакет вручную и отправляет его на указанные в resolv.conf DNS-серверы. Её используют утилиты вроде nslookup, а также некоторые программы, которые обходят getaddrinfo(). Функция отправляет DNS-запросы с помощью res_send() по UDP, а при необходимости, например, при получении ответов, превышающих 512 байт, переключается на TCP. 🕹 Важно: при использовании res_query() вы не получите информацию из /etc/hosts, NSS или других источников. Это DNS-запрос в чистом виде. Поэтому dig или nslookup могут получить один результат, а, например, ping или curl — совсем другой. 1. res_query() считается устаревшей функцией, использовать ее не рекомендуется. Для более удобной и безопасной работы с DNS лучше отдать предпочтение getaddrinfo() или таким библиотекам, как c-ares или libdns. 2. c-ares — легковесная библиотека для асинхронных DNS-запросов, часто используется в высоконагруженных приложениях (например, curl и Node.js) 3. libunbound (из проекта Unbound) — более мощная библиотека с поддержкой DNSSEC и гибкой настройкой запросов. В следующем посте расскажу о порядке реализации запросов и приоритетов, ожидайте, сегодня продолжение 🪳