Безкоштовні піддомени nip.io та sslip.io - 2026 - UA

Материал из Wiki - Iphoster - the best ever hosting and support. 2005 - 2026
Перейти к:навигация, поиск

Published: 2026-09-18


Про що ця стаття

У кожного розробника рано чи пізно виникає одна й та сама проблема: є машина з IP-адресою, але без доменного імені. Це може бути ноутбук із вебзастосунком, який треба налагодити локально, тестовий сервер за звичайним IPv4, чи віртуальна машина в хмарі, що так і не отримала «людського» імені. Без доменного імені не можна отримати дійсний TLS-сертифікат, не можна звертатися до сервісу по памʼятному адресу, і до всього додаються проблеми з cookie, змішаним контентом та налаштуваннями середовища.

Сервіси nip.io та її спадкоємець sslip.io вирішують це завдання напрочуд просто: IP-адреса вбудовується прямо в імʼя хоста. Запишіть у браузері 64.176.22.9.nip.io — і DNS-відповідь міститиме саме 64.176.22.9. Жодної реєстрації, жодної панелі керування, жодних обмежень на кількість хостів. Сервіс працює за принципом wildcard DNS і відповідає на будь-яке імʼя, у якому є коректна IP-адреса.

За понад десять років цей прийом став фактичним стандартом індустрії для розробки та тестування. На nip.io посилаються офіційні документації Google Cloud Platform (Knative Serving), Amazon Web Services (EKS і Teleport), Microsoft Azure (автомасштабування AKS), IBM Redbooks та AMD Enterprise AI. У 2026 році три публічні nameserver'и обслуговують приблизно 29 000 DNS-запитів на секунду, а загальна кількість відповідей вимірюється десятками мільярдів.

Ця стаття — покроковий розбір: як усе працює всередині, які формати hostname підтримуються, як користуватися сервісом у реальних проєктах, як отримувати безкоштовні сертифікати, як перенести таку саму логіку на власний домен (white-label), як підняти власний DNS-сервер і чим сервіс відрізняється від аналогів на кшталт traefik.me, backname.io та xip.io.

Як це працює

Трішки про DNS

Domain Name System перекладає зрозумілі людині імена на кшталт 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. Він не є рекурсивним резолвером: не відповідає на запити про сторонні домени і не зможе розвʼязати для вас google.com. Його єдине завдання — прийняти запит про імʼя з вбудованою IP-адресою, витягти цю адресу з імені та повернути її у відповіді.

Головний трюк: IP усередині hostname

DNS-імена можуть містити літери, цифри, дефіси та крапки. Крапка — це розділювач міток, і саме тому «класична» форма 127.0.0.1 незручна: крапкові імена породжують зайві суфіксні запити. Натомість дефісна форма 192-168-0-1.nip.io читається як звичайне імʼя, проте сервер розуміє, що 192-168-0-1 — це закодована адреса 192.168.0.1.

З IPv6 той самий підхід: двокрапки в DNS-мітках заборонені, тож їх замінюють дефісами, а групу нулів :: записують подвійним дефісом --. Loopback ::1 перетворюється на --1, а публічний DNS Google 2001:4860:4860::8888 — на 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) реалізовано вручну, з власним varint-кодуванням і без зовнішніх protobuf-бібліотек.

Шлях обробки запиту виглядає так: 

UDP/TCP пакет → парсер dnsmessage → processQuestion()
  ├── A      → String2IPv4() + перевірка блоклиста + запис A
  ├── AAAA   → NameToAAAA()  + перевірка блоклиста + запис AAAA
  ├── NS     → ротація списку nameserver'ів + 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 → відправка клієнту

Як сервер розпізнає IP-адресу

Витяг IPv4

Функція String2IPv4 послідовно пробує три регулярні вирази в строгому порядку пріоритету:

  • Дефісна форма: чотири десяткові октети, розділені дефісами, наприклад 192-168-1-1. Дефіси замінюються крапками, і виходить коректна IPv4-адреса.
  • Крапкова форма: класичний запис 127.0.0.1. Повністю підтримується, але вважається менш бажаним кодуванням.
  • Hex-форма: рівно вісім шістнадцяткових цифр, як-от 7f000001, які декодуються в чотири байти. Так, 7f000001.nip.io відповідає 127.0.0.1, а 40B01609.nip.io — адресі 64.176.22.9. Hex-запис не чутливий до регістру: ffffFFFF.nip.io дасть 255.255.255.255.

Пріоритет жорсткий: «дефіси виграють у крапок, крапки — у hex». Якщо в імені кілька IP-подібних фрагментів, перемагає той, що обирається за цим правилом — юніт-тести окремо перевіряють усі три пари.

Є й тонкі правила форматування. Октети понад 255 відхиляються. Октети з провідним нулем (як-от 09) теж відхиляються. А службові імена на зразок ns-01.nip.io, де дефіс є, але чотирьох октетів немає, коректно відрізняються від вбудованих IP-адрес.

Витяг IPv6

Для IPv6 підтримуються дві нотації:

  • Дефісна нотація: один великий регулярний вираз, що покриває всі девʼять варіантів стиснення ::, IPv4-mapped адреси (::ffff:1.2.3.4) та link-local адреси з zone ID (наприклад, fe80--...%en0). Дефіси стають двокрапками, після чого адреса нормалізується через net.ParseIP.
  • Hex-крапкова нотація: рівно 32 шістнадцяткові цифри, розділені крапками, наприклад 2001.0db8.0000.0000.0000.0000.0000.0001. Для hex-форми дозволені лише крапкові розділювачі.

Сервер також уміє зворотний DNS. Запит 1.0.0.127.in-addr.arpa повертає 127-0-0-1.nip.io (або домен, заданий флагом -ptr-domain), а зворотні запити IPv6 у зоні ip6.arpa підтримуються так само.

Поведінка в граничних випадках

Розробники подумали і про крайові ситуації:

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

Типи DNS-записів

Поведінка сервера для кожного типу запитів строго визначена та покрита тестами.

Тип запису Підтримка Поведінка
A Так Витяг IPv4 з імені: дефіси, крапки чи hex; перевірка блоклиста; TTL 3600 для динамічних імен
AAAA Так Витяг IPv6 у дефісній чи hex-крапковій формі; перевірка блоклиста; TTL 3600
NS Так Повертає три nameserver'и зі щосекундною ротацією; A/AAAA glue додається в ADDITIONAL
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)
ANY Ні Відповідь NOTIMP за RFC 8482 — так само, як у Cloudflare
SRV Ні Відсутній; для невідомих типів — порожня відповідь із SOA в AUTHORITY

Стратегія TTL продумана:

  • Динамічні записи A/AAAA для імен зі вбудованим IP — короткий TTL 3600 секунд (одна година). Якщо адресу треба внести в блоклист, старі кешовані записи швидко вичерпаються.
  • Статичні та кастомізовані записи (NS, SOA, MX, CNAME) — довгий TTL 604800 секунд (один тиждень).
  • TXT-записи — короткий TTL 180 секунд, щоб зміни SPF, DKIM і DMARC швидко поширювались.
  • Відповіді-пастки (sinkhole) для заблокованих імен — довгий TTL 604800 секунд: заблокована адреса має надовго лишатися недосяжною.

Вбудовані кастомізації

Частину відповідей задано явно — це важливо для поштової доставки та службових функцій:

  • Власні зони nip.io та sslip.io мають MX-записи ProtonMail, тож пошту на ці домени неможливо перенаправити повз.
  • 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) для заблокованих імен.

Таблиця форматів hostname

Офіційний сайт наводить такі приклади. Домени 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 Hex-форма, 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

Корисно знати одну хитрість: провідні дефіси плутають dig, який сприймає --1.nip.io як прапорець. Розвʼязання — ключ -q: 

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

Ще одна практична порада: для IPv4 краще обирати дефісну форму (10-9-9-30.nip.io), а не крапкову (10.9.9.30.nip.io). Крапкове імʼя змушує резолвер іти ланцюжком суфіксів (30.nip.io, 9.30.nip.io, 9.9.30.nip.io тощо), перш ніж він знайде найкращу мітку. У результаті крапкова форма генерує приблизно вдвічі більше запитів до сервера. За 29 000 запитів на секунду це реальний трафік, тому автори прямо радять дефіси.

Де це застосовують

Локальна розробка

Найчастіший сценарій — локальна розробка вебзастосунків. Класичний біль: фронтенд на порту 8080 звертається до API на іншому порту, а політика змішаного контенту змушує браузер відмовляти незахищеним ресурсам. Рішення на базі localhost мають обмеження: заголовок Host завжди дорівнює localhost, а деякі фреймворки не люблять «нестандартних» імен.

nip.io прибирає цей біль: 127.0.0.1.nip.io миттєво розвʼязується в 127.0.0.1, а вебсервер отримує справжній сертифікат Let's Encrypt. На одній машині можна підняти десятки віртуальних хостів — app1.127.0.0.1.nip.io, app2.127.0.0.1.nip.io тощо, і кожен отримає власний сертифікат.

Варто памʼятати про DNS-rebinding protection: деякі браузери та резолвери блокують імена, що розвʼязуються в приватні діапазони. У більшості середовищ nip.io із приватними адресами (127.x, 10.x, 192.168.x) працює коректно, але якщо провайдер чи корпоративний DNS блокує такі відповіді, вихід — власний екземпляр сервера. Це обмеження екосистеми, а не баг сервісу; про нього згадано навіть у репозиторії оригінального nip.io.

Kubernetes, Knative та хмари

Завдяки інтеграції з ingress-контролерами та сервісами типу Knative Serving nip.io став де-факто стандартом динамічних доменів у Kubernetes. Офіційна документація Google Cloud для Knative Serving використовує піддомени виду 10-10-10-10.nip.io як приклад default domain. Сервіс згадується і в матеріалах AWS (аутентифікація EKS через Teleport), Microsoft Azure (автомасштабування AKS-мікросервісів), IBM Redbooks та AMD Enterprise AI. Патерн завжди один: кластерові, що створює сервіси динамічно, потрібен універсальний шаблон доменних імен, і вбудувати в нього IP-адресу вузла — найдешевший і найуніверсальніший спосіб.

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

Для продакшн-динаміки краще делегувати окрему зону на власному домені (white-label), а nip.io лишити для розробки, стейджингу та тестів.

Зворотні проксі

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 без жодних правок /etc/hosts. Щоб дістатися до контейнера з телефона чи планшета в тій самій мережі, додайте правило 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. Центри сертифікації Let's Encrypt і ZeroSSL підтримують HTTP-01 challenge: вебсервер публікує тимчасовий файл за адресою http://імʼя-хоста/.well-known/acme-challenge/..., CA перевіряє, що 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-рукопотискання, що чудово поєднується з wildcard-структурою nip.io.

Зворотний DNS для налагодження

PTR-записи стають у пригоді під час діагностики мережі. Запит до 1.0.168.192.in-addr.arpa через nameserver'и nip.io повертає 192-168-0-1.nip.io. Це дозволяє тестувати конфігурації, де важлива передбачувана пара forward/reverse записів, наприклад поштові сервери чи тестові лабораторії. Зворотні запити IPv6 у зоні ip6.arpa працюють так само.

«Безкоштовний динамічний DNS»

Оскільки імʼя містить адресу буквально, nip.io не потребує механізму динамічних DNS-оновлень. Змінилась адреса? Перепишіть hostname. Це чудовий спосіб тестувати конфігурації зі змінними адресами без керування DNS-зонами. Якщо ж потрібен стабільний піддомен, що тримається за адресою, яка змінюється, без перейменування, — зверніться до 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 отримується штатно через HTTP-01 challenge. Єдине практичне застереження — ліміти 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 — white-label: ви можете «позичити» технологію для власного домену. Зони nip.io чи sslip.io зовсім не обовʼязкові — будь-який піддомен, наприклад xip.mydomain.com, може поводитися так само.

Процедура така:

  1. Оберіть піддомен, наприклад nip.mydomain.com.
  2. У DNS-панелі реєстратора делегуйте цей піддомен трьом публічним nameserver'ам сервісу, вказавши їх у NS-записах.
  3. Відтоді запити до 127-0-0-1.nip.mydomain.com автоматично потрапляють на сервери sslip.io, які відповідають 127.0.0.1.

Необхідні nameserver'и (актуально з червня 2026 року; адреси двох nameserver'ів змінилися, і застарілі 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 Польща

Перевірити делегування можна через dig, явно вказавши 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) і важить близько 141 МБ. Щоб запустити без прав 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 Розвʼязування публічних адрес. З -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

У репозиторії є готовий 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 ГБ.

Інфраструктура як код

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

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

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

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

Живі цифри продуктивності

Live-метрики, опубліковані через DNS, дають точні цифри навантаження. Типовий зріз одного вузла:

  • Всього оброблено 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

Унікальна особливість проєкту — dogfooding: телеметрія обгорнута в сам DNS. Сервер віддає службові TXT-записи, доступні будь-кому:

  • версія сервера: version.status.nip.io — семантична версія (наприклад, 5.1.5), дата збірки та git-хеш;
  • визначення IP клієнта: ip.nip.io — повертає адресу того, хто поставив запитання;
  • метрики сервера: 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, інакше відповість ваш резолвер, і ви отримаєте адресу резолвера, а не власну. Перевага перед 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, стан блоклиста, сумарні лічильники та швидкість обробки.

Телеметрія та dnstap

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

  • DNS-collector (go-dnscollector v2.5.0) — приймає потік dnstap по TCP 6000;
  • ClickHouse — колоночна БД, у якій накопичуються записи про кожен запит (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) не блокуються ніколи. Якщо запис потрапив у блоклист, сервер відповідає адресою «заглушки» blocked.nip.io (64.176.22.9), а імʼя розвʼязується на сторінку-попередження про те, що сайт заблоковано через зловживання.

blocked.nip.io та звітування про зловживання

Користувач, що відкрив заблокований домен у браузері, потрапляє на мобільно-зручну сторінку 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). Wildcard-піддомени на зонах nip.io/sslip.io не підтримуються, хоча архітектура лишає для них місце.

Альтернативи та порівняння

Розставимо 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 — крапки чи дефіси?

Дефіси. Крапкова форма генерує приблизно вдвічі більше запитів через суфіксні запити.

Чи можна отримати 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 із крапками та дефісами. Відмінності — у стеку (Go проти Python/PowerDNS) і в тому, що sslip.io додатково вміє PTR, white-label і має відкрите Go-ядро для самостійного розгортання.

Що таке DNS-rebinding protection і чи заважає вона nip.io?

Це захисний механізм резолверів і браузерів, що блокує імена, які розвʼязуються в приватні діапазони, щоб атакуючий не міг через спільний DNS атакувати внутрішні сервіси жертви. Для приватних адрес (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 запитів на секунду з трьох континентів.

Головне зі статті:

  • Сервіс безкоштовний, не потребує реєстрації та підтримує дефісну, крапкову та hex-форму IPv4, а також дефісну та hex-крапкову форму IPv6.
  • Найцінніший сценарій — автоматичний TLS від Let's Encrypt для hostname зі вбудованим IP (Caddy справляється за один рядок конфігурації).
  • White-label працює: заделегуйте піддомен трьом публічним nameserver'ам — і отримаєте логіку nip.io на власному домені.
  • Повністю відкрита Go-реалізація (Apache 2.0) піднімається локально, у Docker або в air-gapped мережі, з підтримкою PTR, блоклиста, режимів безпеки та телеметрії dnstap.
  • Для IPv4 кращі дефіси — крапкова форма коштує вдвічі більше запитів.
  • Wildcard-сертифікати не підтримуються, але кожен окремий hostname забезпечується валідним сертифікатом.
  • Економіка вражає: сервіс на десятки тисяч запитів на секунду коштує операторам копійки завдяки розумному вибору провайдерів та IaC-підходу.

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

Джерела

×
Реклама
← В главную
Источник — https://wiki.iphoster.net/index.php?title=Безкоштовні_піддомени_nip.io_та_sslip.io_-_2026_-_UA&oldid=17412
Powered by MediaWiki
ИКС 88x31 - Visitor counter