Поисковые системы давно научились вычислять частные сети (PBN) по техническим следам и повторяющимся паттернам. Подробный контекст и риски работы с такими схемами см. по ссылке, а ниже – разбор ключевых технических ошибок, из‑за которых сеть становится заметной: от инфраструктуры до метаданных.
Критичные признаки: общие IP/ASN и однотипные PTR (rDNS), совпадающие NS/MX, повторяющиеся SSL‑сертификаты и SNI, одинаковые серверные заголовки и версии ПО, единый favicon‑хеш, шаблонные темы/плагины CMS, общие счетчики (UA/GA4/Pixel/Я.Метрика), идентичные robots.txt и sitemap.xml, синхронные расписания публикаций, однообразные анкоры и циклы перелинковки.
Цель – показать, как эти ошибки формируют устойчивый «отпечаток» для алгоритмов и ручных команд, и дать ориентиры для аудита, раздельной инфраструктуры и снижения риска деиндексации частных сетей.
NS и SOA: одинаковые rname, единый serial-формат, повторяющиеся NS-домены – как палятся частные сети
Если вы строите сетку сайтов, нельзя смотреть только на контент и анкоры: DNS-метаданные светят инфраструктуру сильнее, чем кажется. Две записи – NS и SOA – зачастую дают поисковикам тот самый ‘ключ к квартире’: одинаковые rname, единый формат serial, повторяющиеся NS-домены и даже мелкие тайминги в SOA образуют устойчивые слепки. Алгоритмы это ловят на раз-два, особенно когда сочетается сразу несколько признаков.
Разберём спокойно и без истерик, что именно палит частные сети, как это считывают антиспам-модули, почему маскировка через NS и SOA – не формальность, и какие практики помогут не попасть в одну большую кластеризацию. Будет без ‘рваных’ тезисов: по порядку, глубоко и по делу, как будто объясняю другу за кофе.
NS и SOA как телеметрия инфраструктуры
NS-записи объявляют, какие серверы авторитетно отвечают за зону, а SOA фиксирует ‘точку правды’ зоны: primary name server (MNAME), rname владельца зоны, serial и тайминги (refresh, retry, expire, minimum/negative TTL). Эта связка – как паспорт домена. Поисковые и антиспам‑системы вытаскивают её в обход контента: запросили через публичные резолверы, собрали пассивный DNS, сверили с графом ссылок – и сразу видно, кто с кем ходит в одну столовую.
В реальности PBN часто разворачивают шаблоном: один провайдер DNS, дефолтный SOA, одинаковые NS‑хостнеймы, копипастный rname, серийник в стиле YYYYMMDDnn. Впечатляет аккуратностью, но именно эта ‘аккуратность’ и превращается в footprint. Добавьте идентичные TTL и порядок NS – и все домены ложатся в один кластер сильнее, чем по хостингу.
Одинаковые rname в SOA: микро‑поле, макро‑проблема
Поле rname в SOA – это е‑мейл ответственного, записанный через точку вместо @. Примеры выглядят так: hostmaster.example.com или dns-admin.mailhost.tld. В PBN часто забывают поменять rname или, наоборот, задают один ‘корпоративный’ адрес на все зоны. Итог очевиден: десятки доменов с rname типа hostmaster@same‑corp.tld, и антиспам‑вектор получает железный сигнал для кластеризации.
Почему это так больно бьёт:
- rname редко трогают после развёртки: алгоритм воспринимает его как ‘горячий’ признак общего администрирования.
- Даже если вы скрываете WHOIS и разносим хостинг, rname остаётся видимым через dig, API провайдеров и пассивный DNS.
- У провайдеров DNS дефолтные rname однотипные: когда вся сетка оставлена ‘как есть’, сеть кластерится не хуже, чем по одному ASN.
Что делать правильно: задавайте уникальный rname для каждой зоны, не привязанный к одному базовому домену. Рабочая практика – выделить домены‑ретрансляторы под почту и генерировать адреса вида a9.dns‑desk.tld, g4.ops‑mail.tld, причём для каждой доменной группы – свой набор. Поддерживайте catch‑all и фильтры, но не используйте один и тот же rname во всех SOA. И ещё нюанс: не оставляйте артефакты вида devops@, noc@, pbn@ – они тоже шарят сеть сильнее, чем думаете.
Единый serial‑формат в SOA: незаметная математика, которая выдает шаблон
Serial – то самое число, по которому вторичные NS понимают, что зона обновилась. В BIND/классике часто используют дату: YYYYMMDDnn. Для автоматизации это супер‑удобно, но когда 100 зон обновляются одинаковым форматом и тем же шагом – возникает общий рисунок. Даже если даты разные, распределение и форма числа типична: один кластер, один деплой, одна сеть.
Какие сигналы считывают машины:
- устойчивый формат serial (только дата‑шаблон, одинаковая длина, одинаковые префиксы);
- синхронные инкременты в один день по десяткам зон;
- равные тайминги refresh/retry/expire/minimum у всех доменов до секунды;
- редкое изменение serial при частых контент‑апдейтах (несоответствие жизненному циклу сайта).
Как разорвать шаблон и не сломать зону: используйте разные генераторы serial по группам. Часть доменов – монотоник (простое увеличение на 1), часть – epoch‑based (UNIX‑время, приведённое к 10‑значному), часть – смешанный формат с ‘шумом’ в младших разрядах. Важно: serial должен монотонно расти для каждого домена, не играйтесь с уменьшением – сломаете репликацию. Добавьте джиттер к таймингам SOA: разные refresh (например 7200/7800/8400), retry и expire для разных групп, чтобы не светить дефолты одного софта.
Повторяющиеся NS‑домены: громкая вывеска вашей сетки
Один из самых очевидных следов – те же NS у десятков доменов. Даже если IP NS разные, сами хостнеймы вида ns1.my‑vanity‑dns.com и ns2.my‑vanity‑dns.com тянут кластер как магнит. Часто добавляется однотипный порядок NS, совпадающие TTL на NS, одинаковые A‑записи у glue, один и тот же ASN под NS – и картинка становится слишком ровной.
Что усугубляет след:
- vanity‑nameserver под одним базовым доменом на всю сетку;
- NS от одного провайдера без микса, особенно с уникальными хостнеймами;
- идентичный порядок NS во всех зонах и одинаковые TTL;
- одинаковые PTR у IP NS (rDNS с одним шаблоном).
Как разнести сигнал: используйте несколько провайдеров DNS, причём с разными доменными зонами для NS. Для части доменов – публичные NS провайдера (Cloudflare, Route 53, G‑Core, Hetzner DNS, Bunny и т.д.), для части – собственные vanity, но с разными базовыми доменами и разными ASN/сетями под glue. Перемешивайте порядок NS в зонах, варьируйте TTL, не оставляйте полностью одинаковую пару ns1/ns2 на весь пул. И да, отключите AXFR всем подряд: открытая зона – это подарок любому аудитору.
Маскировка сети: не хаос, а продуманная неоднородность
Хорошая маскировка – это не мешанина, а гибкая архитектура, где каждая доменная группа имеет правдоподобную историю и инфраструктуру. Несколько рабочих слоёв:
- hidden master: внутренний первичный DNS выдаёт зоны вторичным у разных провайдеров, серийники и тайминги генерируются разными профилями;
- уникальные rname и MNAME на группу: не используйте один primary‑хостнейм везде;
- джиттер SOA‑таймингов и TTL: миксуйте значения в реальных диапазонах провайдеров (не 3600 везде, а 1800/3000/3600/4500 и т.д.);
- разные NS‑домены и разные ASNs: часть на публичном провайдере, часть на собственных NS в других сетях;
- DNSSEC по ситуации: если включаете – ключи, алгоритмы и RRSIG‑тайминги не должны идти ровным строем по всей сетке;
- закрытый AXFR с белыми списками, отказ от идентичных HINFO/TXT‑меток, никаких общих service‑тегов.
Важно соблюдать ‘правдоподобность’: если зона ‘региональная’, логично видеть NS в близких локациях и умеренные TTL; если трафик через CDN, логичны NS провайдера CDN. Картинка должна собираться у алгоритмов без ощущения конвейера.
Хостинг и сетевые слепки: DNS – лишь половина истории
Даже идеальный DNS не спасёт, если фронты торчат из одного кармана. Алгоритмы параллельно анализируют IP‑пулы, ASN, PTR‑шаблоны, TLS‑выдачу, цепочки сертификатов, серверные заголовки, одинаковые