IPFS: DNSLink и домен библиотеки

Редакция хочет использовать понятное доменное имя для текущего выпуска. DNSLink задаёт указатель через DNS TXT-запись. В уроке разберём, какие полномочия управляют этим указателем, как он сочетается с неизменным CID и почему изменение DNS не создаёт хранение материалов.

Пример использует домен library.example, который не является действительным адресом проекта. DNS-записи не создаются и не меняются. Мы готовим документ конфигурации и ожидаемые последствия, сохраняя основной ProfessorWeb без новых внешних действий.

Запись назначения

DNSLink использует TXT-запись с предусмотренным именем _dnslink. Для текущего учебного выпуска схема выглядит так:

_dnslink.library.example TXT "dnslink=/ipfs/ROOT_CID"

ROOT_CID должен стать действительным вычисленным корнем только после будущей подготовки. Сам текст dnslink= сообщает клиенту назначение, а DNS-имя даёт человеку постоянный адрес. Другие DNS-записи домена решают отдельные задачи.

DNSLink может указывать на IPFS-путь или на поддерживаемый изменяемый маршрут. Цепочка ссылок требует правил разрешения и ограничения рекурсии. Нельзя бесконечно следовать двум именам, которые направляют друг на друга. Совместимый шлюз обязан обработать такой случай как ошибку.

Источник доверия

Контроль DNS-записи даёт право менять рекомендацию содержимого. Это не то же полномочие, что приватный ключ IPNS, хотя пользователь может увидеть похожую форму /ipns/library.example. Досье должно точно назвать фактический механизм.

Если аккаунт DNS скомпрометирован, атакующий может указать другой корень. Сам новый объект может иметь абсолютно правильный CID. Клиентская проверка блоков подтвердит его внутреннюю целостность, но не подлинность редакционного выбора. Для библиотеки дополнительное обязательство из известного CourseCatalog помогает обнаружить расхождение.

Транспорт и проверка DNS также имеют собственные предпосылки. DNSSEC, если используется и правильно проверяется, относится к защите DNS-данных, но не делает исходный HTML безопасным и не гарантирует доступность хранителей. Каждая защита отвечает на свой вопрос.

Указатель и HTTPS

Чтобы открыть привычный HTTPS-домен как сайт IPFS, нужна поддерживаемая конфигурация шлюза и сертификатов. Одна TXT-запись не устанавливает HTTP-сервер, не выпускает сертификат и не гарантирует, что выбранный оператор разрешает обслуживать этот hostname.

В документации DNSLink-шлюза описана обработка заголовка Host и разрешение содержимого. Оператор должен принимать только согласованные имена. Если он использует reverse proxy, заголовки и доверие к ним настраиваются отдельно. Здесь мы не предлагаем менять хостинг ради одного урока.

Для учебной библиотеки разумно сначала иметь отдельный архивный домен или поддомен с понятным договором. Основные старые URL продолжают выполнять свои функции. DNSLink становится дополнительным способом найти текущий выпуск, а не обязательной заменой всего сайта.

Переключение редакции

Когда второй выпуск готов и имеет подтверждённые копии, редакция меняет указатель на новый корень. Кэши DNS и шлюзов могут некоторое время видеть прежнее значение. Поэтому нельзя обещать мгновенное одновременное переключение всех читателей.

до обновления: имя → ROOT_EDITION_1
после решения: имя → ROOT_EDITION_2
старая точная ссылка → ROOT_EDITION_1

Старая точная ссылка сохраняет смысл. Если нужно предупредить о новом выпуске, интерфейс делает это отдельно, не выдавая другой файл под прежним обязательством. Пользователь может сознательно выбрать исторический материал.

Откат DNS к первой редакции также является новым административным действием. В журнале сохраняются причина, прежний корень, новый корень и время решения. Удаление записи из панели DNS не стирает уже распространённые материалы.

Делегирование узкого полномочия

Автоматизация выпуска может иметь ограниченное право обновить конкретную запись, если поставщик позволяет такой профиль. Нет необходимости давать сборочному процессу полный контроль всех доменов организации. Секрет такого доступа хранится вне публичного клиента и репозитория.

Если платформа не поддерживает нужную границу, досье отражает более широкое полномочие. Нельзя назвать его узким только потому, что наш скрипт обычно меняет одно поле. Реальные права определяются аккаунтом и API, а не намерением кода.

Ручное согласование также может быть достаточным для первой версии. В этой работе никаких записей не меняем. Подготовленный листинг остаётся предметом последующего решения, когда возникнет запрос на развёртывание.

DNS уже изменён, читатель ещё видит старое

Оператор обновил TXT-запись на корень второй редакции, но один читатель продолжает открывать первую. Между зоной DNS и браузером есть разрешающие и кэширующие участники, а у шлюза может быть собственное состояние. Сам факт сохранения записи в панели управления не доказывает, что каждый маршрут уже использует новое значение. В журнале обновления поэтому разделяем редакционное решение, изменение зоны и наблюдение конкретной выдачи.

TTL помогает управлять временем кэширования, но не является командой мгновенно заменить все существующие ответы. Перед важным переходом учитывают выбранные сроки и процедуру, предусмотренную оператором DNS и шлюза. Не обещаем универсальное число секунд: оно зависит от фактической конфигурации. Если новая редакция исправляет опасный активный пример, одной надежды на быстрый DNS-переход недостаточно для всей политики отзыва.

Доменный указатель также не заменяет настройку HTTP и TLS. TXT сообщает content-addressed-назначение, а браузер должен ещё попасть на подходящий обслуживающий маршрут с допустимым сертификатом. Успешное чтение DNSLink не делает любой сервер владельцем нашей веб-сессии. Для библиотеки административные полномочия домена, выдача учебных файлов и личный кабинет остаются описанными отдельно.

При откате оператор снова выбирает прежний неизменный корень и фиксирует причину. Читатели по конкретным CID продолжают иметь доступ к своим редакциям независимо от текущей рекомендации, если сохранены копии. Для предметного досье полезны прежнее и новое значения, время редакционного решения, применённый TTL, ответственный владелец зоны и способы наблюдения. Пока это будущие записи без реальных значений. Такая опись помогает расследовать задержку переключения и показывает, почему открытая первая редакция не обязательно свидетельствует о неверных байтах или утрате второй.

Проверка получателем

Клиент разрешает имя в конкретный корень, сохраняет результат и свежесть, затем получает манифест. Если CourseCatalog объявляет SHA-256 другой текущей редакции, интерфейс сообщает расхождение. Это может быть задержка обновления, неверная конфигурация или подмена; без дальнейших данных не выбираем причину автоматически.

При недоступности DNS можно открыть сохранённый явный CID. Это продолжение чтения известного выпуска, а не успешное получение последней рекомендации. В статусе различаем обе цели.

Результат урока — досье имени: владелец полномочия, запись, профиль шлюза, кэширование и процедура обновления. Правила доступны в документации DNSLink и DNSLink Gateway Specification. Теперь постоянное имя имеет понятный источник доверия, а неизменный выпуск сохраняет собственную идентичность.

Оглавление серии