Бесплатные поддомены nip.io и sslip.io - 2026

Published: 2026-09-18

Введение

Каждый разработчик хотя бы раз сталкивался с классической проблемой: машина, на которой работает веб-сервер, имеет только IP-адрес, но не имеет доменного имени. Это может быть ноутбук с веб-приложением для локальной отладки, тестовый сервер за обычным IPv4-адресом, или виртуальная машина в облаке без выделенного хоста. Без доменного имени невозможно получить валидный TLS-сертификат, невозможно красиво обращаться к сервису по имени, и сплошь и рядом возникают проблемы с куками, смешанным контентом и настройками окружения.

Идея nip.io и её наследника sslip.io предельно проста и одновременно гениальна: вместо того чтобы поднимать полноценную DNS-зону под каждый IP-адрес, сервис предлагает встраивать IP-адрес прямо в DNS-имя. Например, запрос к хосту 64.176.22.9.nip.io возвращает в DNS-ответе ровно адрес 64.176.22.9. Никакой регистрации, никаких панелей управления, никаких лимитов на количество хостов — сервис работает по принципу wildcard DNS и обслуживает любые имена, содержащие корректный IP-адрес.

Этот подход оказался настолько удобным, что за более чем десять лет существования nip.io и sslip.io превратились в фактический стандарт индустрии для разработки и тестирования. На них ссылаются официальные документации Google Cloud Platform (Knative Serving), Amazon Web Services (EKS и Teleport), Microsoft Azure (Autoscaling AKS microservices), IBM Redbooks и AMD Enterprise AI. По данным самого сервиса, публичные DNS-серверы nip.io и sslip.io в 2026 году обрабатывают около двадцати девяти тысяч DNS-запросов в секунду, а суммарное число ответов, выданных за время работы, исчисляется десятками миллиардов.

В этой статье мы подробно разберём, что такое nip.io и sslip.io, как они устроены внутри, какие форматы записи IP-адресов поддерживают, как ими пользоваться в реальных проектах, как получить бесплатные TLS-сертификаты Let's Encrypt, как подключить собственный домен (white-label), как поднять собственный DNS-сервер на основе открытого исходного кода и как они соотносятся с альтернативными сервисами вроде traefik.me, backname.io и xip.io.

Этимология названий

Пара слов о происхождении имён, потому что история названий сама по себе любопытна. Домен xip — это IP наоборот, нехитрый, но запоминающийся палиндром-инверсию. Именно такой подход придумал Сэм Стивенсон для первого сервиса этого класса. Название nip — тоже игра слов вокруг IP: одна буква заменена, и получилось слово, которое на одном из диалектов английского обозначает лёгкий укус или отщипывание. А sslip.io выглядит как удвоенная буква s перед IP — читается как "эс-эс-лип". По стечению обстоятельств аббревиатура SSL (Secure Sockets Layer) очень похожа на S-S-L, поэтому домен sslip.io интуитивно ассоциируется у веб-разработчиков с TLS/HTTPS, хотя на самом деле никакого отношения к SSL-протоколу не имеет — совпадение, которое лишь усилило запоминаемость сервиса.

Название sslip.io, как уже упоминалось, предложил Сэм Стивенсон, когда Брайан Канни и его команда искали имя на хакерском дне Pivotal. Это своего рода передача эстафеты от одного поколения сервисов встроенных IP-адресов к другому.

История: от xip.io до единого сервиса

xip.io — прародитель идеи

Первым сервисом, встроившим IP-адрес в DNS-имя, был xip.io, созданный Сэмом Стивенсоном (Sam Stephenson) — известным разработчиком, автором утилит для сборки Rails-приложений и активным участником open-source-сообщества. Бэкенд xip.io был написан настолько компактно, что, по воспоминаниям Брайана Канни, представлял собой "самый плотный bash-код", который он когда-либо видел. Несмотря на гениальность идеи и лаконичность реализации, xip.io со временем прекратил работу и на текущий момент не функционирует. Тем не менее именно он вдохновил все последующие реализации, включая nip.io и sslip.io.

С технической точки зрения xip.io был устроен так же, как и современные сервисы: авторитативный nameserver получал запрос о имени вида 10.0.0.1.xip.io, извлекал из имени IP-адрес и возвращал его в ответе. Никакой базы данных, никаких зон — вся логика выполнялась "на лету".

nip.io: рождение в 2012 году

Домен nip.io был зарегистрирован 8 июня 2012 года разработчиком Роопиндером Сингхом (Roopinder Singh), известным в сообществе под ником exentrique. Он же создал первый рабочий бэкенд сервиса (коммит 58ac8fe в репозитории exentriquesolutions/nip.io). Технически это была связка авторитативного DNS-сервера PowerDNS и так называемого PipeBackend — специального интерфейса PowerDNS, через который DNS-сервер передаёт входящий запрос внешней программе через стандартный ввод (stdin) и получает ответ через стандартный вывод (stdout). Бэкенд был написан на Python. Такая архитектура позволяла писать практически любую DNS-логику на обычном языке программирования, не трогая сам DNS-сервер.

Конфигурация оригинального бэкенда была гибкой и управлялась через файл backend.conf либо через переменные окружения. Среди них: NIPIO_DOMAIN (зона), NIPIO_TTL (время жизни записей), NIPIO_NONWILD_DEFAULT_IP (адрес по умолчанию для не-wildcard имён), параметры SOA, список nameserver'ов, а главное — NIPIO_WHITELIST и NIPIO_BLACKLIST для CIDR-фильтрации адресов и NIPIO_CAA для выдачи CAA-записей с указанием Let's Encrypt как разрешённого центра сертификации. Обратите внимание: whitelist и blacklist существовали в оригинальном nip.io ещё в начале 2010-х годов — в современном sslip.io аналогичные возможности реализованы флагом -public и блоклистом.

Сервис быстро стал популярным: разработчики могли писать в hostname свой IP-адрес и получать работающий домен без каких-либо регистраций. На базе исходного бэкенда Роопиндера впоследствии был сделан отдельный сервис traefik.me, который работает и сегодня.

sslip.io: хакерский день Pivotal

Второй независимый сервис — sslip.io — был создан 11 августа 2015 года командой Брайана Канни, Тайлера Шульца (Tyler Schultz) и Альваро Переса-Ширли (Alvaro Perez-Shirley) во время хакерского дня (Hack Day), спонсируемого компанией Pivotal Software. В отличие от Python-бэкенда nip.io, sslip.io изначально писался на Go как автономный DNS-сервер без зависимости от PowerDNS. Годом позже, в 2016-м, Брайан Канни добавил поддержку IPv6 — в те времена это было заметным отличием от конкурентов.

На протяжении нескольких лет sslip.io и nip.io существовали как два параллельных сервиса с одинаковой функциональностью и разными доменами. Пользователи могли выбирать любой из них. При этом исходный репозиторий nip.io в своём README прямо называл sslip.io "духовным наследником" проекта.

Инцидент 2015 года с wildcard-сертификатом

В истории sslip.io есть поучительный эпизод. Однажды, в течение примерно недели в 2015 году, sslip.io публиковал приватный ключ своего wildcard-сертификата. Сертификат был быстро отозван, но упоминания об этом инциденте до сих пор встречаются в поисковых подсказках Brave и Google, причём зачастую в искажённом виде. Авторы сервиса вынуждены регулярно опровергать эти "городские легенды": сейчас у sslip.io нет и никогда не будет wildcard-сертификата, а все сертификаты, выдаваемые через Let's Encrypt и ZeroSSL для отдельных hostnames nip.io/sslip.io, являются валидными, приватными и безопасными. Любые предупреждения о "небезопасности wildcard-сертификата" на текущий момент бессмысленны.

Утрата основателя и смена владельца

3 мая 2024 года Роопиндер Сингх скончался. Это стало трагическим событием не только для его близких, но и для сообщества разработчиков, поскольку судьба домена nip.io и одноимённого сервиса оказалась под вопросом. В исходном репозитории появилась запись о том, что мейнтейнер Роопиндер Сингх (1981–2024) ушёл из жизни, а sslip.io может считаться его духовным наследником.

Судьбу проекта решила семья Сингха. 6 июля 2025 года сестра Роопиндера Раман (Raman) передала домен nip.io Брайану Канни, который продолжил эксплуатацию сервиса вместе с соавтором Кеннетом Лейкиным (Kenneth Lakin). С этого момента оба домена — nip.io и sslip.io — обслуживаются единым кодом на Go, а веб-сайт сервиса стал частью репозитория sslip.io. Современная версия программного обеспечения, обслуживающая оба домена, носит номер 5.1.5.

nip.io и sslip.io сегодня

На начало 2026 года положение дел следующее:

Домены nip.io и sslip.io полностью взаимозаменяемы — сервис отвечает одинаково на hostname, оканчивающиеся на любой из них.
Публичную инфраструктуру обслуживают три авторитативных nameserver'а, разнесённых по трём континентам: Сингапур (DigitalOcean), США (Hetzner) и Польша (OVH).
Суммарная нагрузка превышает 29 000 DNS-запросов в секунду.
Операторами сервиса являются Брайан Канни и Кеннет Лейкин.
Проект полностью открыт: исходный код распространяется по лицензии Apache 2.0 в репозитории cunnie/sslip.io.
Сервис поддерживает жалобы на злоупотребления: на сообщения, отправленные на адрес abuse@nip.io, операторы отвечают в течение 24 часов.

Инфраструктура при этом настолько продумана, что обслуживание обходится операторам в копейки: например, сервер, раздающий страницу-предупреждение о заблокированных сайтах, после переноса из AWS на Vultr стал стоить всего 10 долларов в месяц вместо прежних 139 долларов, и при этом получил более широкий канал и больше дискового пространства.

Принцип работы: как DNS-сервер возвращает IP из hostname

DNS простыми словами

Domain Name System (DNS) — это распределённая система, которая переводит человекочитаемые имена, например google.com, в машинные IP-адреса. Когда браузеру нужно открыть сайт, он сначала опрашивает рекурсивный резолвер (чаще всего — DNS-сервер интернет-провайдера или публичный резолвер вроде 8.8.8.8), а тот, в свою очередь, обращается к авторитативным nameserver'ам, обслуживающим нужную зону. Авторитативные серверы являются "источником истины" для своего домена: именно они отвечают на запросы A (IPv4), AAAA (IPv6), NS, SOA, MX, TXT, CNAME и другие.

Сервис nip.io выступает ровно таким авторитативным nameserver'ом для зон nip.io и sslip.io. Он не является рекурсивным резолвером и не отвечает на запросы о посторонних доменах. Его единственная задача — принять DNS-запрос о хосте с IP-адресом, извлечь этот адрес из имени и вернуть его в ответе.

Ключевая хитрость: встроенный IP

Вся магия заключается в том, что IP-адрес встроен прямо в hostname. DNS-имя по своей природе может содержать любые буквы, цифры, дефисы и точки. Разделителем октетов IPv4-адреса в обычном виде служат точки — но точки являются одновременно и разделителями меток DNS. Именно поэтому дефисный формат оказывается более предпочтительным. Запрос 192-168-0-1.nip.io выглядит как обычное имя, но сервер понимает, что последовательность 192-168-0-1 — это закодированный IP-адрес 192.168.0.1.

Для IPv6 запись выполняется аналогично: двоеточия, используемые в обычном представлении IPv6, в DNS-именах использовать нельзя, поэтому они заменяются дефисами, а группа нулей :: превращается в двойной дефис --. Например, ::1 (loopback IPv6) записывается как --1, а адрес 2001:4860:4860::8888 (публичный DNS Google) — как 2001-4860-4860--8888.

Внутреннее устройство: Go-сервер

Современный сервер sslip.io написан на Go (модуль xip, Go 1.25) и устроен удивительно компактно. Основная логика сосредоточена в двух файлах:

main.go — сетевой уровень: приём UDP и TCP-пакетов на порту 53, чтение запросов, запись ответов, интеграция с dnstap.
xip/xip.go — вся DNS-логика: разбор имени, извлечение IP-адреса, блоклист, построение ответа, кастомизации и метрики.

При этом у сервера ровно одна внешняя библиотека времени выполнения — golang.org/x/net, из которой используется пакет dns/dnsmessage для разбора и сборки DNS-пакетов в wire-формате. Всё остальное — стандартная библиотека Go. Даже поддержка протокола dnstap (потоковая телеметрия DNS, основанная на кодировании protobuf) реализована вручную, без внешней protobuf-библиотеки, с собственными функциями varint-кодирования.

Архитектура обработки запроса выглядит так:

UDP/TCP пакет → парсер dnsmessage → processQuestion()
  ├── A      → String2IPv4() + блоклист + A-запись
  ├── AAAA   → NameToAAAA()  + блоклист + AAAA-запись
  ├── NS     → ротация имён серверов + glue-записи
  ├── SOA    → MNAME = имя из запроса
  ├── TXT    → только из кастомизаций (SPF, DMARC, version, metrics)
  ├── PTR    → разбор in-addr.arpa / ip6.arpa
  ├── MX     → ProtonMail (для nip.io/sslip.io) или само имя
  ├── CNAME  → только статические (DKIM)
  └── ANY    → ответ NOTIMP (RFC 8482)
→ сборка ответа через dnsmessage.Builder → отправка клиенту

Алгоритм извлечения IPv4

Функция String2IPv4 последовательно пробует три регулярных выражения:

Дефисный формат: шаблон ищет четыре десятичных октета, разделённых дефисами, например 192-168-1-1. После нахождения дефисы заменяются точками и получается корректный IPv4-адрес.
Точечный формат: шаблон ищет классическую запись вида 127.0.0.1, уже разделённую точками. Этот формат считается менее предпочтительным, но полностью поддерживается.
Шестнадцатеричный формат: шаблон ищет ровно восемь шестнадцатеричных цифр (например, 7f000001), которые затем декодируются в четыре байта IP-адреса. Так, 7f000001.nip.io соответствует 127.0.0.1, а 40B01609.nip.io — адресу 64.176.22.9. Шестнадцатеричная запись регистронезависима: ffffFFFF.nip.io даст адрес 255.255.255.255.

Существует строгий приоритет форматов: сначала проверяются дефисы, затем точки, и только в конце — шестнадцатеричная запись. Если в имени встречается несколько IP-адресов, побеждает выбранный по этому правилу приоритета (юнит-тесты специально проверяют, что "дефисы побеждают точки", "дефисы побеждают hex" и "точки побеждают hex").

Есть и тонкие правила форматирования. Например, блокируются невалидные октеты: адрес с октетами больше 255 не распознаётся, а октет с ведущим нулём (например, 09) не допускается. Имена вида ns-01.nip.io, содержащие дефис, но не четыре октета, не распознаются как IP — сервер корректно отличает служебные имена от IP-встроенных.

Алгоритм извлечения IPv6

Для IPv6 применяются два подхода:

Дефисная нотация: одно большое регулярное выражение, покрывающее все девять возможных вариантов сжатия ::, а также IPv4-mapped адреса (вида ::ffff:1.2.3.4) и link-local адреса с zone ID (например, fe80--...%en0). Дефисы заменяются двоеточиями, после чего адрес нормализуется через net.ParseIP.
Шестнадцатеричная нотация: ровно 32 шестнадцатеричных цифры, разделённые точками, например 2001.0db8.0000.0000.0000.0000.0000.0001. Ограничение: для hex-записи IPv6 допускаются только точечные разделители, дефисные границы не поддерживаются.

Наконец, сервер умеет обратный DNS (PTR). Для запроса вида 1.0.0.127.in-addr.arpa он вернёт имя 127-0-0-1.nip.io (или другой домен, заданный флагом -ptr-domain), а для IPv6-запроса в зоне ip6.arpa — соответствующий hostname в дефисном представлении.

Особенности обработки DNS-запросов

Разработчики уделили внимание и поведению сервера в пограничных случаях:

На пакет с несколькими вопросами сервер отвечает только по первому вопросу — это де-факто стандарт, полностью совместимый с поведением большинства DNS-клиентов.
Ответы всегда содержат флаг RecursionAvailable = false. Сервер принципиально не работает как открытый резолвер.
Авторитативные ответы помечаются флагом Authoritative. Исключение — случаи делегирования (DNS-01 challenge), где ответ формируется в разделе AUTHORITY.
NS-записи вращаются каждую секунду: порядок имён серверов в ответе меняется, что распределяет нагрузку между тремя узлами без сложных балансировщиков.
Для каждого nameserver'а сервер автоматически добавляет glue-записи A и AAAA в дополнительную секцию ответа, чтобы клиент мог немедленно установить соединение.

Поддерживаемые типы DNS-записей

Поведение сервера для разных типов запросов строго определено и покрыто тестами. Сведём всё в таблицу.

Тип записи	Поддержка	Поведение
A	Да	Извлечение IPv4 из имени: дефисы, точки или hex; проверка блоклиста; TTL 3600 для динамических имён
AAAA	Да	Извлечение IPv6 из имени в дефисной или hex-нотации; проверка блоклиста; TTL 3600
NS	Да	Возвращает три nameserver'а, вращая порядок каждую секунду для балансировки; в ADDITIONAL добавляются glue-записи A/AAAA
SOA	Да	MNAME равен имени из запроса, serial 20260704; используется и как прямой ответ, и как негативный ответ в AUTHORITY
TXT	Частично	Только из кастомизаций: SPF, DMARC, версия сервера, метрики, определение IP клиента; TTL 180
PTR	Да	Обратный DNS для IPv4 (in-addr.arpa) и IPv6 (ip6.arpa) — возвращает дефисное имя под доменом PTR
MX	Да	Для nip.io и sslip.io — записи ProtonMail (10 mail.protonmail.ch, 20 mailsec.protonmail.ch); для остальных — ссылка на само имя с приоритетом 0
CNAME	Частично	Только статические кастомизации (DKIM-записи protonmail._domainkey для ProtonMail)
ANY	Нет	Ответ NOTIMP (not implemented) в соответствии с RFC 8482 — так же, как у Cloudflare
SRV	Нет	Отсутствует; на неизвестные типы — пустой ответ с SOA в AUTHORITY

Важная деталь — стратегия TTL (время жизни записи в кэше резолверов):

Динамические записи A/AAAA для имён со встроенным IP — короткий TTL 3600 секунд (1 час). Это сделано специально: если адрес потребуется внести в блоклист, старые записи быстро истекут из кэшей.
Статические и кастомизированные записи (NS, SOA, MX, CNAME) — длинный TTL 604800 секунд (1 неделя).
TXT-записи — короткий TTL 180 секунд, чтобы изменения SPF, DKIM и DMARC быстро распространялись.
Заблокированные ответы (sinkhole) — длинный TTL 604800 секунд: попавший в блоклист адрес должен надолго остаться недоступным.

Сервер всегда помечает ответы как нерекурсивные (RecursionAvailable: false) и не работает как обычный резолвер: он не умеет и не должен отвечать на запросы о посторонних доменах. Это принципиальная особенность, которая предотвращает использование сервиса в качестве открытого резолвера для DNS-амплификационных атак.

Служебные кастомизации

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

Собственные домены nip.io и sslip.io имеют MX-записи ProtonMail (mail.protonmail.ch и mailsec.protonmail.ch), поэтому почта на адреса никто не может направить мимо.
Для SPF используется запись v=spf1 include:_spf.protonmail.ch mx -all.
Для DMARC — политика v=DMARC1; p=reject, то есть вся почта, не прошедшая проверку SPF, отклоняется.
DKIM-записи protonmail._domainkey реализованы через CNAME на ProtonMail.
Служебные TXT-записи version.status и metrics.status отдают телеметрию сервера.
Запись ip.nip.io (или ip.sslip.io) возвращает IP-адрес того, кто задал вопрос.
Адресу blocked.nip.io соответствуют специальные A- и AAAA-записи — это так называемый sinkhole (адрес-ловушка) для заблокированных имён.

Форматы записи IP-адресов: полная таблица

Официальный сайт сервиса приводит следующие примеры. Домены nip.io и sslip.io полностью взаимозаменяемы.

Hostname	Возвращаемый адрес	Примечание
https://64.176.22.9.nip.io	64.176.22.9	Точечный формат, IPv4
https://64-176-22-9.nip.io	64.176.22.9	Дефисный формат, IPv4
www.192.168.0.1.nip.io	192.168.0.1	Поддомен перед IP
www.192-168-0-1.nip.io	192.168.0.1	Поддомен + дефисы
https://www-78-46-204-247.nip.io	78.46.204.247	Дефисный префикс перед адресом
--1.nip.io	::1	IPv6 — только дефисы, никогда точки
https://2a01-4f8-c17-b8f--2.nip.io	2a01:4f8:c17:b8f::2	IPv6 с группой нулей
https://40B01609.nip.io	64.176.22.9	Шестнадцатеричный формат IPv4
7f000001.nip.io	127.0.0.1	Hex-запись loopback
2001-0db8-0000-0000-0000-0000-0000-0001.nip.io	2001:db8::1	Полная дефисная запись IPv6
fe80--...%zone.nip.io	link-local с zone ID	Специальный случай IPv6

Проверить работу сервиса проще всего утилитой dig (входит в пакеты dnsutils / bind-utils):

# Прямой запрос к публичному nameserver'у
dig @ns.nip.io 192-168-0-1.nip.io +short
# → 192.168.0.1

# Точечный формат тоже работает
dig @ns.nip.io 192.168.0.1.nip.io +short
# → 192.168.0.1

# IPv6-адрес (двойной дефис = ::)
dig @ns.nip.io --1.nip.io aaaa +short
# → ::1

# Обратный DNS
dig @ns.nip.io -x 127.0.0.1
# → 127-0-0-1.nip.io

# Проверка обеих зон сразу
for ip in 10 192-168-0-1; do
  echo "$ip.nip.io  = $(dig +short $ip.nip.io @ns.nip.io)"
  echo "$ip.sslip.io = $(dig +short $ip.sslip.io @ns.nip.io)"
done

Стоит обратить внимание на замечание из документации сайта: hostname с ведущими дефисами, например --1.nip.io, может смущать утилиту dig, которая воспринимает дефис как начало флага. Для обхода нужно использовать ключ -q:

dig +noidnout +noidnin -q --1.nip.io aaaa

Ещё один практический совет, упомянутый разработчиками: для IPv4 лучше использовать дефисный формат (10-9-9-30.nip.io) вместо точечного (10.9.9.30.nip.io). Дело в том, что точечная запись порождает в DNS цепочку дополнительных запросов: резолвер, прежде чем найти самую подходящую метку (например, 30.nip.io), будет последовательно опрашивать сервис по всем суффиксам (9.30.nip.io, 9.9.30.nip.io и так далее). В результате точечный формат генерирует примерно вдвое больше запросов к серверу, чем дефисный — в масштабах 29 000 запросов в секунду это существенная экономия трафика, и именно поэтому авторы сервиса прямо рекомендуют использовать дефисы.

Сценарии использования

Локальная разработка и localhost

Самый частый сценарий — разработка веб-приложений на локальной машине. Классический пример: фронтенд, работающий на порту 8080, обращается к API на другом порту, и из-за политики смешанного контента (mixed content) браузер отказывается выполнять запросы к не-HTTPs ресурсам. Решения, основанные на localhost, имеют свои ограничения: заголовок Host всегда равен localhost, а некоторые фреймворки и браузеры не позволяют использовать "нестандартные" имена.

Вместо этого можно использовать nip.io: 127.0.0.1.nip.io мгновенно резолвится в 127.0.0.1, а самому web-серверу без проблем выдаётся TLS-сертификат от Let's Encrypt. Caddy решает задачу одной строкой конфигурации (пример ниже). При этом на одном компьютере можно поднять десятки виртуальных хостов с разными именами вида app1.127.0.0.1.nip.io, app2.127.0.0.1.nip.io и так далее — и каждый получит собственный сертификат.

Важно помнить про DNS-rebinding protection: некоторые браузеры и резолверы блокируют имена, резолвящиеся в приватные IP-адреса, из соображений безопасности. Для локальной разработки с приватными адресами (127.x.x.x, 10.x.x.x, 192.168.x.x) nip.io в большинстве окружений работает корректно, но если провайдер или корпоративный DNS блокирует такие ответы, решением будет поднять собственный экземпляр сервера (об этом ниже). Эта особенность — не баг сервиса, а защитный механизм DNS-эколсии, задокументированный ещё в репозитории оригинального nip.io.

Kubernetes, Knative и облака

Благодаря интеграции с ingress-контроллерами и сервисами типа Knative Serving, nip.io стал де-факто стандартом для создания динамических доменов в Kubernetes-кластерах. В официальной документации Google Cloud Platform для Knative Serving в качестве примера default-domain как раз используются поддомены вида 10-10-10-10.nip.io. Аналогичным образом сервис упоминается в материалах AWS (блог об аутентификации EKS с GitHub credentials через Teleport), Microsoft Azure (статья об автоскейлинге AKS-микросервисов), IBM Redbooks и AMD Enterprise AI. Каждый раз это одно и то же: кластеру, который создаёт сервисы динамически, нужен общий шаблон доменных имён, и встроить в него IP-адрес узла — самый дешёвый и универсальный способ.

Почему это так удобно в Kubernetes: service-to-service общение и доступ через ingress требуют, чтобы у каждого сервиса было стабильное имя. При динамическом создании окружений (review apps, feature branches, preview environments) имена генерируются автоматически, и формат [branch].127-0-0-1.nip.io идеально подходит: имя уникально, а IP-адрес пишется из фактического узла.

Стоит отметить, что для продакшена динамических окружений лучше использовать отдельный выделенный домен с делегированием зоны (white-label, смотрите ниже), а nip.io — для разработки, стейджинга и тестов.

Веб-серверы и reverse proxy

Локальный reverse proxy вроде Traefik или Caddy — это фактически второй родной сценарий сервиса. Рассмотрим пример с Traefik и Docker Compose. У вас есть два тестовых приложения, и вы хотите обращаться к ним по именам app1.traefik.me и app2.traefik.me, а с других устройств локальной сети — по app1.10.0.0.1.traefik.me:

version: '3'
services:
  traefik:
    restart: unless-stopped
    image: traefik:v2.0.2
    command: --providers.docker=true
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
  app1:
    image: containous/whoami
    labels:
      - "traefik.http.routers.app1.rule=Host(`app1.traefik.me`)"
  app2:
    image: containous/whoami
    labels:
      - "traefik.http.routers.app2.rule=Host(`app2.traefik.me`)"

Запустите docker-compose up, и браузер откроет app1.traefik.me и app2.traefik.me без каких-либо правок /etc/hosts. Чтобы дотянуться контейнерами с телефона или планшета в той же локальной сети, добавьте rule с HostRegexp и маской IP:

- "traefik.http.routers.app1.rule=HostRegexp(`app1.{ip:.*}.traefik.me`)"

После этого по адресу http://app1.10.0.0.1.traefik.me любое устройство в вашей LAN попадёт в контейнер app1. Та же логика работает и с nip.io доменом.

Получение бесплатного TLS-сертификата

Главная ценность сервиса для современного веба — возможность получить автоматический TLS-сертификат на hostname, соответствующий вашему IP-адресу. Сертификационные центры Let's Encrypt и ZeroSSL поддерживают HTTP-01 challenge: сервер, на котором запущено веб-приложение, публикует временный файл по адресу http://имя-хоста/.well-known/acme-challenge/..., после чего CA проверяет, что обращение к этому hostname действительно попадает на ваш сервер, и выдаёт сертификат. Поскольку hostname вида 64.176.22.9.nip.io резолвится ровно в ваш IP, всё работает без каких-либо ручных действий.

Наиболее популярный инструмент для этого — веб-сервер Caddy, который автоматически получает и продлевает сертификаты:

# Пример Caddyfile для хоста с IP 64.176.22.9
64.176.22.9.nip.io {
    reverse_proxy 127.0.0.1:8080
}

Caddy сам сгенерирует валидный сертификат Let's Encrypt для имени 64.176.22.9.nip.io и будет автоматически его продлевать. Тот же принцип работает для www.64.176.22.9.nip.io, prod.www-64-176-22-9.nip.io и любых других комбинаций. Caddy поддерживает даже On-Demand TLS — получение сертификата "на лету" в момент TLS handshake, что отлично сочетается с wildcard-структурой nip.io.

Обратный DNS и отладка сети

PTR-записи (reverse DNS) бывают полезны при отладке сетевых проблем. Запрос к 1.0.168.192.in-addr.arpa через серверы nip.io возвращает имя 192-168-0-1.nip.io. Это позволяет тестировать конфигурации, где важна предсказуемая связка forward/reverse записей, например при проверке почтовых серверов или в тестовых лабораториях. Для IPv6 соответствующие PTR-запросы формируются в зоне ip6.arpa и тоже поддерживаются.

"Бесплатный динамический DNS"

Поскольку имя содержит IP-адрес буквально, nip.io не нужен механизм динамических DNS-обновлений. Есть адрес — есть имя. Как только IP-адрес изменился, перепишите hostname — и всё заработает с тем же самым резолвингом. Для сценариев, где поддомен нужно стабильно "привязывать" к меняющемуся адресу без правки имени, лучше подойдут сервисы вроде afraid.org или ipq.co (смотрите раздел "Аналоги").

Комбинация с SSH-туннелями и VPN

Ещё один неочевидный сценарий — доступ к внутренним сервисам через туннель. Предположим, у вас есть сервер в интернете с публичным адресом и тоннель до внутренней сети компании. Вы хотите, чтобы коллеги открывали внутренний веб-интерфейс по понятному имени с валидным HTTPS, но не имеете контроля над внутренней DNS-зоной. Тогда на шлюзе поднимается Caddy или nginx, который резолвит имя вида wiki.10-0-0-44.nip.io во внутренний адрес 10.0.0.44 и проксирует трафик. Внутренние клиенты попадают на ресурс по защищённому каналу, а сертификат получается тем же автоматическим способом.

Тестовые стенды и CI

В конвейерах непрерывной интеграции nip.io-домены часто используются для проверки TLS-конфигурации. Типичный сценарий: пайплайн поднимает окружение на временной машине, генерирует имя по IP этой машины и прогоняет нагрузочные или интеграционные тесты, ожидая валидный HTTPS. Благодаря автоматическим сертификатам и отсутствию регистрации такой стенд поднимается за минуты и так же быстро уничтожается, не оставляя мусора в DNS-зонах организации.

TLS-сертификаты и Let's Encrypt

Как уже говорилось, сертификат на hostname nip.io/sslip.io получается штатными средствами Let's Encrypt через HTTP-01 challenge. Единственный практический аспект, о котором предупреждают авторы сервиса, — это лимиты Let's Encrypt. История отношений nip.io и Let's Encrypt достаточно показательна: сертификационный центр многократно поднимал лимит для сервиса — сначала с 50 до 250 000 сертификатов, а запрос на 500 000 отклонил со словами "это слишком много для нас". Для обычных пользователей лимиты сертификатов на один домен и на одну неделю публично документированы и, как правило, не достигаются в процессе разработки.

Что делать, если запрос сертификата на nip.io упёрся в rate limit:

попробовать использовать сертификат на IP-адрес (начиная с 15 января 2026 года Let's Encrypt предоставляет общедоступные сертификаты для IP-адресов, а также упростил выдачу короткоживущих шестидневных сертификатов);
попробовать второй домен — если использовался nip.io, запросить сертификат для sslip.io;
использовать связанные сервисы (traefik.me, backname.io).

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

Важно: nip.io и sslip.io не поддерживают wildcard-сертификаты, то есть сертификат вида *.nip.io получить нельзя. Каждый hostname обслуживается индивидуальным сертификатом — это осознанное архитектурное решение, повышающее безопасность экосистемы.

White-label: собственный домен на nip.io-движке

Ключевая особенность sslip.io — возможность "одолжить" технологию для собственного домена. Вам не обязательно использовать зоны nip.io или sslip.io: можно сделать так, чтобы любой ваш поддомен, например xip.mydomain.com, обладал точно такими же возможностями.

Как это работает:

Вы выбираете поддомен, например nip.mydomain.com.
В DNS-панели вашего регистратора делегируете этот поддомен трём публичным nameserver'ам сервиса, указав их в NS-записях поддомена.
После этого запросы к 127-0-0-1.nip.mydomain.com автоматически попадают на серверы sslip.io, которые возвращают адрес 127.0.0.1.

Необходимые nameserver'ы (актуально с июня 2026 года; предыдущие адреса были изменены, и устаревшие NS-записи приводят к ошибкам SERVFAIL):

Hostname	IPv4	IPv6	Локация
ns-00.nip.io	167.172.4.236	2400:6180:0:d2:0:2:e3e7:0	Сингапур
ns-01.nip.io	5.78.28.211	2a01:4ff:1f2:10d::	США
ns-ovh.sslip.io	51.75.53.19	2001:41d0:602:2313::1	Польша

Пример проверки делегирования, приведённый на сайте, с явным указанием nameserver'а через знак собаки:

dig @ns-ovh.nip.io 169-254-169-254.nip.example.com +short
# → 169.254.169.254

Особое предупреждение от операторов (июнь 2026): пользователям white-label необходимо обновить свои nameserver'ы. Имена хостов и адреса двух nameserver'ов изменились, и те, кто не обновил NS-записи, получают ответы SERVFAIL.

Внимание: эти nameserver'ы не являются рекурсивными резолверами — их нельзя использовать в качестве DNS-серверов системы, они обслуживают только зоны со встроенными IP-адресами.

Для организаций, которые хотят полного контроля, рекомендуется запускать собственный экземпляр сервера с флагом -public=false — так можно исключить риск фишинга через публичные IP-адреса на собственном домене.

Установка собственного DNS-сервера

Открытая архитектура позволяет развернуть собственный экземпляр сервиса — это полезно для изолированных (air-gapped) сетей, для тестирования, а также для организаций, которые не хотят зависеть от внешнего сервиса. Решение полностью автономно: ему не нужен интернет, а его адреса, NS-записи и домен PTR задаются флагами.

Быстрый старт из исходников

git clone https://github.com/cunnie/sslip.io.git
cd sslip.io
go mod tidy
sudo go run .   # sudo требуется для порта 53

В другом терминале проверяем:

dig @localhost 192.168.0.1.sslip.io +short
# → 192.168.0.1

Установка через Docker

Официальный образ называется cunnie/sslip.io-dns-server и поддерживает архитектуры linux/amd64 и linux/arm64 (AWS Graviton, Apple M1/M2), размер — около 140 МБ. Для запуска без прав root удобно переназначить порт:

docker run -d --rm -p 3353:53/udp cunnie/sslip.io-dns-server
# проверить:
dig @localhost 127-0-0-1.sslip.io -p 3353 +short

Готовые бинарники

Проект публикует прекомпилированные бинарники для платформ darwin, linux и freebsd (amd64 и arm64), а также windows (amd64) на странице релизов. Раздача скомпилированных бинарников зашита даже в прод-инфраструктуру: облачные серверы скачивают бинарник версии 5.1.5 с GitHub Releases при развёртывании.

Ключевые команды и флаги

Полный список флагов документирован в README. Наиболее полезные:

Флаг	По умолчанию	Описание
-port	53	Порт для UDP/TCP. Низкие порты требуют root
-nameservers	ns-00.nip.io, ns-01.nip.io, ns-ovh.sslip.io	Список FQDN для NS-записей
-addresses	пусто	Пары "host=IP" для кастомных A/AAAA записей (несколько адресов на хост)
-blocklistURL	https://raw.githubusercontent.com/cunnie/sslip.io-blocklist/main/blocklist.txt	URL блоклиста, поддерживается протокол file://
-delegates	пусто	Делегирование поддоменов внешним nameserver'ам (например, для DNS-01 challenge)
-ptr-domain	nip.io.	Домен для PTR-ответов
-public	true	Разрешить разрешение публичных IP. При -public=false резолвятся только приватные адреса
-quiet	false	Отключить лог на каждый запрос (экономит деньги на Cloud Logging в GKE)
-dnstap	пусто	Адрес сокета (Unix или TCP) для стриминга телеметрии dnstap

Пример развёртывания собственного nameserver'а для поддомена xip.pivotal.io с собственными NS-записями и адресами:

go run main.go \
  -nameservers=ns-ip-0.pivotal.io,ns-ip-1.pivotal.io \
  -addresses ns-ip-0.pivotal.io=10.8.8.8,ns-ip-1.pivotal.io=fc88:: \
  -ptr-domain=xip.pivotal.io

После этого для зоны xip.pivotal.io нужен запрос вида dig ns 127.0.0.1.com @localhost -p 5553, который вернёт NS-записи ns-ip-0.pivotal.io и ns-ip-1.pivotal.io вместе с glue-записями.

Деплой через systemd

Для серверов с systemd в репозитории есть готовый unit-файл etc/sslip.io-dns.service. В прод-инфраструктуре каждая машина получает сервис с уникальными флагами -nameservers и -addresses, которые запекаются в cloud-init при развёртывании. Типовая конфигурация выглядит так:

[Unit]
Description=sslip.io DNS Server
After=network.target

[Service]
ExecStart=/usr/bin/sslip.io-dns-server \
  -nameservers=ns-00.nip.io.,ns-01.nip.io.,ns-ovh.sslip.io. \
  -addresses=nip.io=78.46.204.247,sslip.io=78.46.204.247,...
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Инфраструктура прод-сервиса

Пять провайдеров, три континента

Архитектура публичного сервиса по-своему уникальна: три авторитативных nameserver'а обслуживаются разными облачными провайдерами на разных континентах, что обеспечивает максимальную отказоустойчивость — даже при полном отказе одного из облаков остальные два продолжат обслуживать зону. Дополнительно существует отдельный сервер "blocked", обслуживающий страницу-заглушку для заблокированных доменов, и виртуальная машина с dnstap-телеметрией.

Сервер	Провайдер	Локация	Особенности
ns-00.nip.io	DigitalOcean	Сингапур	Droplet s-2vcpu-4gb, Fedora
ns-01.nip.io	Hetzner Cloud	Орегон, США	Сервер cpx31
ns-ovh.sslip.io	OVH	Варшава, Польша	Выделенный сервер
blocked.nip.io	Vultr	Сан-Паулу, Бразилия	Раздаёт страницу-заглушку заблокированных доменов
dnstap.nono.io	Proxmox (homelab)	США	Сборщик dnstap, ClickHouse-аналитика

Выбор провайдеров не случаен. DigitalOcean выбран за азиатскую точку присутствия, Hetzner за разумный тариф в США, OVH за дешёвую и мощную Европу, а Vultr — самый дешёвый вариант для "черновой" инфраструктуры. Каждая точка присутствия имеет IPv4 и IPv6.

Показательна история сервера blocked: изначально он размещался в AWS и обходился в 139.16 доллара в месяц, а после переноса на Vultr в июле 2026 года расходы упали до 10 долларов в месяц при росте ширины канала с 2 до 3 ТБ и диска с 55 до 150 ГБ.

Управление через IaC

Вся инфраструктура описана кодом через OpenTofu (open-source форк Terraform) и cloud-init. Для каждого провайдера существует отдельная директория terraform/ns-00, terraform/ns-01, terraform/ns-ovh, terraform/blocked и terraform/dnstap с собственным состоянием. Cloud-init выполняет установку пакетов (~30 пакетов: toolchain Go, dig, редакторы), создание пользователя, запись systemd-юнита службы и скачивание бинарника.

В README-файлах каждого провайдера разработчики честно документируют "грабли": например, у DigitalOcean Terraform "это бардак" (не создаётся образ Fedora 44, резервные IP надо назначать вручную), у Hetzner флоатінг-IP не удаляются при tofu destroy, а у OVH consumer-ключи живут всего 30 дней. Такая откровенная документация — редкость и большая ценность для тех, кто повторяет этот опыт.

Обновления без простоя

Релизный процесс полуавтоматический и продуманный. Сначала собираются бинарники для восьми платформ, затем проверяется полный набор регрессионных тестов на локальном сервере, после чего бинарник поочерёдно заливается на серверы с перезагрузкой каждого сервера по одному. После каждой перезагрузки выполняется проверка версии через DNS-запрос TXT к version.status.sslip.io. Такой rolling-деплой позволяет обновлять сервис без единой секунды простоя. Каждые шесть часов автоматизированный смоук-тест (GitHub Actions) проверяет живые nameserver'ы на соответствие RDAP-записям, доступность по IPv4/IPv6, работу по UDP/TCP и корректность ключевых ответов.

Контрольные цифры производительности

Из живых метрик, публикуемых через DNS, можно почерпнуть точные цифры нагрузки. Типичный срез одного из nodes сервиса:

Суммарно обработано 58 116 774 запросов с момента запуска, около 4169 запросов в секунду на этом узле.
По протоколу: 58 259 316 запросов через UDP и всего 457 через TCP — UDP доминирует.
Ответов, содержащих записи A/AAAA и другие данные — около 18,2 миллиона (~1308 в секунду), что составляет примерно четверть всех запросов.
Выдано 15,6 миллиона A-записей и 120 тысяч AAAA.
Ровно 13 421 ответ был заблокирован (sinkhole).
Блоклист последний раз обновлялся автоматически и содержал 3773 CIDR-диапазона, 2 одиночных IP и строковые маски.

Эти цифры наглядно показывают, что четверть трафика приходится на "пустые" ответы — как раз из-за дублирующих A/AAAA-запросов и цепочек точечных суффиксов, о которых говорилось выше.

Масштаб, производительность и метрики

Каков реальный масштаб

По состоянию на 2026 год публичный сервис обрабатывает около 29 000 запросов в секунду в сумме по трём узлам. Бейдж Queries/сек на главной странице обновляется автоматически каждые шесть часов по данным live-метрик. Распределение запросов почти полностью приходится на UDP, доля TCP — доли процента.

Метрики прямо через DNS

Уникальная особенность проекта — попытка обернуть собственную телеметрию в DNS (dogfooding). Сервер отдаёт служебные TXT-записи, доступные любому желающему:

версия сервера: version.status.nip.io — семантическая версия (например, 5.1.5), дата сборки и git-хэш;
определение IP клиента: ip.nip.io — возвращает IP-адрес того, кто задал вопрос;
метрики сервера: metrics.status.nip.io — uptime, время обновления и размер блоклиста, общее число запросов и скорость в QPS, разбивка UDP/TCP, число ответов с записями, счётчики по типам запросов, число заблокированных запросов и DNS-01 делегирований.

Пример запроса метрик:

dig @ns-ovh.nip.io metrics.status.nip.io txt +short

Чтобы предотвратить злоупотребление метриками как увеличителем DNS-амплификации (ответ с метриками в несколько раз больше запроса), сервер ограничивает выдачу метрик примерно четырьмя запросами в секунду.

Стратегия производительности

Один из самых интересных инженерных трюков в коде — оптимизация блоклиста. Из 746 исходных CIDR-записей 744 представляли собой одиночные адреса /32. Разработчики перевели их в обычную map-структуру с ключами-строками, что сократило время обработки запроса примерно на 11% (обработка вместо ~0.25 секунд стала пренебрежимо быстрой).

Экспериментальные функции

На странице https://nip.io/experimental.html документированы три экспериментальные функции. Авторы прямо предупреждают: "Экспериментальные функции могут измениться; не полагайтесь на них".

Определение внешнего IP через DNS

Сервис позволяет узнать свой внешний IP-адрес простым DNS-запросом. Функция создана по образцу Google-сервиса o-o.myaddr.l.google.com:

dig @ns.nip.io txt ip.nip.io +short      # вернёт ваш публичный IP
dig @ns.nip.io txt ip.nip.io +short -4    # принудительно IPv4
dig @ns.nip.io txt ip.nip.io +short -6    # принудительно IPv6

Ключевое предостережение: в запросе обязательно нужно указывать @ns.nip.io, иначе ответит ваш резолвер, и вы получите IP резолвера, а не собственный. Преимущество подхода перед HTTP-сервисами вроде icanhazip.com — радикально меньший объём трафика: DNS-запрос занимает примерно 594 байта в двух пакетах, тогда как HTTP-запрос к icanhazip.com — около 8692 байт в 34 пакетах (более чем в 14 раз больше). Для мобильных пользователей и скриптов, которые опрашивают IP-адрес регулярно, это ощутимая экономия.

Версия сервера

dig @ns-ovh.nip.io version.status.nip.io txt +short
# "5.1.5"
# "дата сборки"
# "git-хэш"

Интересная деталь: значения даты сборки и git-хэша могут отличаться между узлами — это нормальный артефакт rolling-деплоя, когда серверы обновляются не одновременно.

Метрики

dig @ns-ovh.nip.io metrics.status.nip.io txt +short

Возвращает список TXT-записей с uptime, состоянием блоклиста, суммарными счётчиками и скоростью обработки.

Тelemetry и dnstap

Помимо публичных TXT-метрик, сервер умеет стримить полную телеметрию DNS-трафика через протокол dnstap. Включается флагом -dnstap с адресом Unix-сокета или TCP-соединения. В прод-инфраструктуре для этого выделена отдельная виртуальная машина dnstap.nono.io на домашнем Proxmox-сервере, где развёрнуты:

DNS-collector (go-dnscollector v2.5.0) — принимает поток dnstap по TCP 6000;
ClickHouse — columnar БД, в которой накапливаются записи о каждом запросе (identity, queryip, qname, operation, family, protocol, qtype, rcode, timestamps);
ZFS-хранилище для данных анализа.

Это позволяет операторам отвечать на вопросы вида "какие домены запрашивают чаще всего", "кто спрашивает про ip.sslip.io" и "какие клиенты генерируют больше всего запросов". Команда ведёт даже публичные документы с методиками анализа журналов journald при помощи простых конвейеров из cut/awk.

Безопасность: блоклист, sinkhole и защита от амплификации

Многоуровневый блоклист

Для борьбы с фишинговыми сайтами, размещающимися на nip.io-доменах, сервис использует автоматически обновляемый блоклист, который скачивается с GitHub каждые 60 минут (при недоступности блоклиста сервер продолжает работать, просто логирует ошибку). Блоклист имеет три уровня:

CIDR-диапазоны: блокировка целых подсетей, в том числе провайдеров с плохо защищёнными серверами.
Отдельные IP-адреса: одиночные адреса, хранящиеся в быстрой map-структуре.
Строки-подустроки: блокировка по вхождению строки в hostname (например, имя банка "raiffeisen" в raiffeisen.94.228.116.140.nip.io).

Логика блокировки тонкая: блокируется только имя, содержащее валидный IP-адрес. Если адрес приватный (RFC 1918/4193) — он никогда не блокируется. Если запись попала в блоклист — в ответе вместо реального IP возвращается адрес "заглушки" blocked.nip.io (64.176.22.9), а само имя резолвится на специальную страницу-предупреждение о том, что сайт заблокирован за злоупотребление.

Страница-предупреждение blocked.nip.io и abuse

Пользователь, открывший заблокированный домен в браузере, попадает на web-страницу blocked.nip.io с предупреждением, что сайт отключён за фишинг или иное злоупотребление. Сервер, держащий страницу, расположен в Сан-Паулу и за 2026 год несколько раз масштабировался: расширен канал с 2 до 3 ТБ, диск вырос до 150 ГБ. Страница приведена в мобильно-дружелюбный вид.

Рядом с главной страницей сервиса размещён блок про abuse-репорты: операторы принимают жалобы на адрес abuse@nip.io и обязуются отвечать в течение 24 часов. Это важный элемент доверия: бесплатные wildcard-домены неизбежно привлекают злоумышленников, и прозрачный процесс репортинга позволяет сообществу самостоятельно чистить сервис.

Режим -public=false

Владельцам собственных зон рекомендовано запускать сервер с флагом -public=false. В этом режиме разрешаются только приватные адреса: 10/8, 172.16/12, 192.168/16, 127/8, 169.254/16, CGNAT 100.64/10, IPv6-адреса fd00::/8 (fc00::/7), loopback ::1, link-local fe80::/10 и некоторые другие служебные диапазоны. Публичные IP при этом не резолвятся вовсе. Зачем это нужно? Фишер может арендовать машину с публичным IP, получить через сервис hostname вида 52-0-56-137.ip.wellsfargo.com (если ваш поддомен называется ip.wellsfargo.com) и использовать его для фишинговой атаки на клиентов банка. При -public=false такой сценарий исключён полностью. Эта же функция сохраняет приватность в том смысле, что локальные адреса, в отличие от публичных, никогда не попадают в блоклист и всегда резолвятся.

Защита от DNS-амплификации

Сервер всегда отвечает с RecursionAvailable=false и не работает как открытый резолвер, поэтому его нельзя использовать как усилитель DDoS-атак. Дополнительно лимитируется выдача "тяжёлых" TXT-ответов (метрик): буферизованный канал на 200 токенов с паузой 250 миллисекунд ограничивает пропускную способность примерно четырьмя запросами в секунду.

Роль DNS-01 challenge и делегирования

Сервер умеет обрабатывать запросы вида _acme-challenge.имя.nip.io и отвечать NS-делегированием на встроенный IP. Это позволяет автоматическим инструментам получать сертификаты через DNS-01 challenge — правда, только если вы поднимаете собственный экземпляр сервера (соответствующий механизм включается флагом -delegates). Для зон nip.io/sslip.io wildcard поддомены не поддерживаются, но архитектурно такая возможность заложена.

Аналоги и альтернативы

Сравним nip.io/sslip.io с другими сервисами того же класса.

Сервис	Технология	Статус	Особенности
nip.io / sslip.io	Go, с 2012/2015	Работает	29 000 q/s, IPv4/IPv6/PTR, white-label, свой DNS-сервер
xip.io	bash	Прекращён	Исторический прародитель идеи
traefik.me	Python + PowerDNS	Работает	Прямой наследник оригинального бэкенда nip.io; работает только через IP-имя, дефисы тоже поддерживает
backname.io	Go (библиотека Miek Gieben)	Работает	Современная Go-реализация; поддерживает IPv6 с точками и дефисами
afraid.org	Собственный	Работает	Полноценный динамический DNS, хостинг субдоменов и доменов, без встраивания IP в имя
ipq.co	Собственный	Работает	"Tinyurl мира DNS" — короткие ссылки-перенаправления без встраивания IP

Выбор зависит от задачи:

Встроить IP в имя, получить TLS, локальная разработка — nip.io/sslip.io.
Хочется стабильный поддомен, который не меняется при смене IP — afraid.org или ipq.co.
Требуется свой сервер, полный контроль, air-gapped — собственный экземпляр sslip.io или traefik.me на своём железе.
Максимальная простота на Python-стеке — traefik.me, или развёртывание оригинального nip.io-бэкенда.

Отдельно стоит упомянуть Let's Encrypt как связанный сервис: именно он делает nip.io практически незаменимым без полноценного TLS. Поддержать проект можно пожертвованием на странице abetterinternet.org.

Частые вопросы

Можно ли использовать nip.io для продакшена?

Да, крупные компании вроде Google, AWS и Azure используют подобные домены в документации и инфраструктуре. Но если важна максимальная стабильность и вы хотите контролировать политику безопасности, лучше делегировать собственный поддомен (white-label) или поднять собственный экземпляр сервера.

Почему у меня не резолвится 192.168.0.1.nip.io?

Наиболее вероятная причина — DNS-rebinding protection у вашего резолвера или браузера, либо блокировка со стороны провайдера. Попробуйте запросить напрямую: dig @ns.nip.io 192-168-0-1.nip.io +short, и при необходимости поднимите локальный экземпляр сервера.

Какой формат лучше для IPv4 — точки или дефисы?

Дефисы. Точечный формат порождает вдвое больше DNS-запросов из-за суффиксных lookups и увеличивает нагрузку на сервис.

Можно ли получить wildcard-сертификат для *.nip.io?

Нет. И для nip.io, и для sslip.io wildcard-сертификаты не выдаются. Каждый hostname получает собственный валидный сертификат.

Как узнать свой внешний IP через DNS?

dig @ns.nip.io txt ip.nip.io +short — сервис вернёт ваш публичный IP. Обязательно указывайте @ns.nip.io.

Это бесплатно?

Да, сервис полностью бесплатен и финансируется из кармана операторов. Пожертвования в адрес Let's Encrypt, а также обратная связь в виде сообщений об злоупотреблениях — лучшая форма поддержки.

Чем nip.io отличается от traefik.me?

Функционально почти ничем — оба поддерживают встраивание IPv4 по точкам и дефисам и простыми DNS-записями. Различия в технологическом стеке (Go против Python/PowerDNS) и в том, что sslip.io дополнительно умеет PTR, white-label и имеет открытое Go-ядро для самостоятельного развёртывания.

Что такое DNS-rebinding protection и мешает ли она nip.io?

DNS rebinding protection — защитный механизм резолверов и браузеров, блокирующий имена, которые резолвятся в приватные адреса, чтобы атакующий не мог атаковать внутренние сервисы жертвы через общий DNS. Для приватных IP-адресов (127.x, 10.x, 192.168.x) он может мешать локальной разработке: часть провайдеров отвечает на такие запросы ошибкой. Решение — использовать собственный экземпляр сервера либо публичный резолвер без таких фильтров. Это ограничение задокументировано в репозиториях обоих проектов и не является ошибкой сервиса.

Откуда берутся цифры 29 000 запросов в секунду?

Из открытых метрик сервиса. Каждые шесть часов автоматизированный скрипт опрашивает metrics.status.sslip.io у всех трёх nameserver'ов, суммирует скорость ответов и обновляет бейдж на главной странице. Любой желающий может убедиться в цифрах самостоятельно с помощью описанной выше команды dig.

Резюме

nip.io и sslip.io за четырнадцать лет существования доказали, что простая идея может стать стандартом индустрии. Встроить IP-адрес в DNS-имя и вернуть его в ответе — казалось бы, ничего сложного, но именно эта механика лежит в основе тысяч Kubernetes-кластеров, локальных разработок и CI-конвейеров по всему миру. История проекта тоже поучительна: созданный в одиночку в 2012 году, пережив смерть основателя, домен nip.io перешёл в руки сообщества и сегодня вместе с sslip.io обслуживает более 29 000 запросов в секунду на трёх континентах.

Ключевые выводы из статьи:

Сервис бесплатен, не требует регистрации и поддерживает дефисный, точечный и шестнадцатеричный форматы IPv4, а также дефисный и hex-формат IPv6.
Идеальный сценарий — автоматическое получение TLS-сертификатов Let's Encrypt для hostname со встроенным IP-адресом (Caddy справляется с этим в одну строчку конфигурации).
Для собственного домена работает white-label: делегируйте поддомен трём публичным nameserver'ам — и получите nip.io-логику на своём домене.
Существует полностью открытая Go-реализация сервера (лицензия Apache 2.0), которую можно поднять локально, в Docker или в изолированной сети, с поддержкой PTR, блоклиста, режимов безопасности и dnstap-телеметрии.
Для IPv4 предпочтителен дефисный формат — точечный порождает вдвое больше запросов.
Wildcard-сертификаты не поддерживаются, но каждый отдельный hostname обеспечивается индивидуальным валидным сертификатом.
Экономика проекта впечатляет: сервис, обрабатывающий десятки тысяч запросов в секунду, обходится операторам в копейки благодаря грамотному выбору облачных провайдеров и IaC-подходу.

Если вы разработчик, использующий локальный стейджинг, Kubernetes или Caddy — nip.io/sslip.io, скорее всего, уже работает в вашей цепочке инструментов, возможно, даже незаметно для вас. Теперь вы знаете, как он устроен внутри, как его приручить под себя и как поднять собственный экземпляр.

Ссылки

×

← В главную