dxdt.blog: занимательный интернет-журнал

На dxdt.blog продолжают сыпаться десятки тысяч HTTP-хитов в сутки от ИИ-ботов, в том числе, повторные GET-запросы в течение одних суток на одни и те же URL.

Для особо надоедливых ботов я сделал отдельный HTTP-редирект (302), ведущий на специальную страницу, где с кодом статуса 503 возвращается краткая HTML-заглушка. В некоторых случаях это помогает – бот, во-первых, не идёт по редиректу (ну, это предположительно, судя, так сказать, по косвенным признакам), во-вторых – на какое-то время бот, наткнувшийся на редирект в сторону 503, перестаёт сканировать сайт. Но это именно что в некоторых случаях: многие боты так и продолжают тупо прыгать по редиректам, причём, при каждом соседнем запросе – превращая десятки тысяч GET-запросов в десятки тысяч последовательных редиректов. А если такого бота забанить уже на уровне сетевого стека, то он всё равно продолжает лить сетевые запросы. В целом, очень хорошо заметно, как распространение подобных ботов заливает веб – на dxdt.blog трафик ИИ-ботов, по HTTP-хитам с кодом 200, в десятки раз превысил всё остальное.

Ещё наблюдение по этой же теме: я некоторое время назад сделал на сайте специальную ссылку, которая, как я думаю, не должна использоваться при корректной работе с веб-сайтом, но если пройти по URL из неё, то это моментально приводит к блокированию IP-источника уже на уровне сетевого стека (netfilter в ОС, под которой крутится веб-сервер). Ссылку, по понятным причинам, здесь не указываю, но она есть в robots.txt – объявлена, как закрытая (Disallow), что, конечно, может и привлекать запросы. Однако по этой ссылке – совсем мало кто из ботов попадается: видимо, прямое указание в robots.txt – пока работает в сторону “отключения”.

На днях я писал о том, что сейчас нетрудно сделать веб-сайт без доменного имени, а прямо под IP-адресом (v4), но с доверенным HTTPS для коробочного браузера. В качестве примера – сделал точно такой веб-сайт, с сертификатом от Let’s Encrypt: https://185.39.19.199/ – можно зайти браузером и убедиться, что всё работает. Надо заметить, что TLS-сертификаты для IP-адресов можно было получать в доверенных, хорошо известных УЦ и раньше, это, конечно, не в Let’s Encrypt придумали – но вот только раньше выпуск такого сертификата был сопряжён с существенными дополнительными административными трудностями, а Let’s Encrypt позволяет этих трудностей избежать совсем.

Посмотрим подробнее на сам TLS-сертификат, который сейчас установлен на сервере под указанным выше IP-адресом. Исходный файл сертификата можно получить с сервера – он и так передаётся при каждом TLS-соединении, а здесь – будет текстовая распечатка, полученная при помощи OpenSSL. Так как полная распечатка довольно длинная, а разделю её на части, которые подробно прокомментирую, попутно рассказав, на что это всё влияет.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            06:7e:8d:e7:b0:8a:13:8c:23:da:d4:f1:43:e6:de:24:02:f6
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = YE1
        Validity
            Not Before: Apr 26 13:18:14 2026 GMT
            Not After : May  3 05:18:13 2026 GMT
        Subject: 

Здесь указаны самые, наверное, очевидные поля: версия формата (3 – сейчас это типовой вариант); серийный номер; алгоритм подписи – ECDSA, см. ниже; название подписавшего сертификат УЦ (Issuer); период валидности.

Обратите внимание – в сертификате отсутствует поле Subject. Это весьма важный момент, довольно свежий. Сейчас в TLS-сертификатах (для веба) в качестве носителя имён и адресов TLS-узла выступает другое поле – SAN (Subject Alternative Name). Поле Subject может присутствовать в сертификате, но, например, браузеры имена из этого поля игнорируют, если нет соотвествующего имени в SAN. В случае же этого сертификата от Let’s Encrypt, как мы видим, нет самого содержимого поля Subject. Это, в частности, означает, что если в каких-то скриптах (скажем, для мониторинга) это поле используется для определения принадлежности сертификата, то с современными TLS-сертификатами (для веба) скрипт правильно работать не будет. Такие скрипты нужно обновлять – см. ниже.

Вот типичный пример вызова OpenSSL в shell-скрипте, который пытается проверить имя в сертификате по Subject:

openssl x509 -in 185-39-19-199.pem -subject -noout -nameopt multiline \
| awk -F' = ' '/commonName/ {print $2}'

Для старого формата сертификатов (например, как сейчас установлен на dxdt.blog) – этот вызов выведет имя из поля “commonName” в Subject, то есть, для dxdt.blog – напечатает dxdt.blog. Однако в случае с новыми сертификатами – фрагмент не напечатает ничего, но, при этом, обработанный сертификат будет валидным и вполне себе корректным. То есть, полагаться на Subject больше нельзя – нужно заменять вызовы утилит на обработку поля SAN. Это несколько сложнее, но вполне реализуемо.

Для извлечения имён из SAN при помощи OpenSSL (утилита x509) нужно указать опцию -ext subjectAltName. Выдача openssl x509 в этом случае состоит из списка, где тип элемента обозначен префиксом. DNS-имена OpenSSL выводит с префиксом “DNS”, а IP-адреса – “IP address” (это будет полезно для нашего сертификата). Пример:

openssl x509 -in 185-39-19-199.pem -noout -ext subjectAltName

Результат:

X509v3 Subject Alternative Name: critical
    DNS:185.39.19.199.zone, IP Address:185.39.19.199

Скрипт, понятно, усложняется – нужно парсить префиксы полей. Пример скриптового вызова с awk, для извлечения DNS-имени:

openssl x509 -in 185-39-19-199.pem -noout -ext subjectAltName \
| awk 'NR>1{split($0,A,",");for(k in A){split(A[k],B,":"); \
if(B[1]~/DNS/){print B[2]}}}'

Результат:

185.39.19.199.zone

Обратите внимание: 185.39.19.199.zone – это хостнейм, доменное имя, пусть оно и похоже на IP-адрес. Да, в данном сертификате присутствует и DNS-имя, и IP-адрес – это делает сертификат хорошим примером. В принципе, сервер доступен и под доменным адресом 185.39.19.199.zone, но основным мы тут считаем IP-адрес. Для выпуска сертификата на IP-адрес не требуется указание доменного имени. Но если имя нужно включить в сертификат, то это нетрдуно сделать при помощи того же certbot – просто указываем при вызове и доменное имя, и IP-адрес:

certbot certonly --preferred-profile shortlived \
-d 185.39.19.199.zone \
--ip-address 185.39.19.199 \
--webroot --webroot-path /var/www/html/

Вернёмся к распечатке исходного сертификата. Предыдущий блок закончился на пустом Subject. Смотрим дальше:

        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:ea:98:84:aa:0e:d5:2b:0f:5a:00:6b:bc:17:df:
                    33:91:86:e5:f8:b6:cb:e8:f0:7b:48:f0:5f:bf:8c:
                    04:57:9e:7f:ee:66:a8:09:7a:31:f3:11:d5:2f:90:
                    67:01:af:04:cc:45:52:56:5d:18:73:bf:1c:d5:6d:
                    f9:f7:44:6e:5d
                ASN1 OID: prime256v1
                NIST CURVE: P-256

Это открытый ключ. В сертификате указан открытый ключ для ECDSA на кривой P-256. Это, опять же, типовой сейчас вариант, ничего необычного.

        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                BB:20:CA:47:0B:FE:D7:E5:9C:F9:8F:09:2A:A3:8C:37:45:B1:BC:D8
            Authority Information Access: 
                CA Issuers - URI:http://ye1.i.lencr.org/

Далее идут так называемые “расширения” (extensions). Key Usage и Extended Key Usage – обозначают допустимое использование открытого ключа из сертификата. Сейчас, в случае TLS-сертификатов для веба, перечень флагов, указываемых в этих полях Удостоверяющим Центром (УЦ), сильно сократили: здесь есть только Digital Signature (цифровая подпись) в основном поле Key Usage и TLS Web Server Authentication (аутентификация TLS-сервера для веба) – в дополнительном Extended Key Usage. И всё – это, опять же, нововведение: тут нт ни клиентской аутентификации, ни “шифрования ключа” или “ключевого обмена”, ни чего-то ещё подобного.

CA:FALSE в Basic Constraints – ключ из сертификата не может быть использован в качестве доверенного для проверки подписи на других сертификатах (это если строго; простыми словами говорят, что “это не сертификат ключа УЦ”).

Authority Key Identifier – идентификатор ключа для проверки подписи; это, вообще говоря, историческое поле, которое предназначено для “быстрого поиска” ключа проверки подписи на сертификате, но, понятно, без самого ключа не имеет смысла.

Authority Information Access – указание на точки раздачи файлов с информацией об удостоверяющем центре. В данном случае, указана только точка раздачи по HTTP сертификата ключа УЦ – CA Issuers.

Далее идёт поле SAN, с именами и адресами, которое мы упоминали выше:

            X509v3 Subject Alternative Name: critical
                DNS:185.39.19.199.zone, IP Address:185.39.19.199

Указано одно доменное имя (DNS) и один IP-адрес (IP Address). Ещё раз напомню, что могли быть и только IP-адреса, причём, разных версий – v4, v6. Современные барузеры в процессе валидации сопоставляют имена или адреса из поля SAN, не из Subject. Например, при подключении по IP-адресу 185.39.19.199, браузер проверит, что в TLS-сертификате указан именно этот адрес в поле SAN.

Интересен вопрос контекста: что использует браузер – IP-адрес или доменное имя? В сертификате могут быть указаны оба этих артефакта, но браузер при валидации использует тот, который пользователь ввёл при вызове. То есть, если обращение по имени хоста, то сранивается имя хоста, если по IP-адресу напрямую, то сравнивается IP-адрес. Понятно, что почти всякое HTTP-обращение, в стетевом смысле, производится по IP-адресу. Я как-то (https://dxdt.blog/2025/04/15/15391/) писал о том, что, в теории, для случая хостнейма, тоже можно использовать и IP-адреса из сертификата, в качестве дополнительного фактора – совпал и домен, и IP-адрес. Но в современной практике веба это, скорее, излишняя перестарховка, сопряжённая с техническими сложностями, к тому же.

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://ye1.c.lencr.org/119.crl

Политики (Policies) – тут просто указан идентификатор политики УЦ, в рамках которой проводилась проверка права управления ресурсом (адресом, именем) и выпускался сертификат. Политики – это больше административный момент. Но, например, именно идентификатором политики определяются так называемые EV-сертификаты (Extended Validation), которые сейчас почти что утратили актуальность.

X509v3 CRL Distribution Points – точка раздачи CRL – списка отозванных сертификатов. В данном сертификате есть механизм проверки отзыва – это CRL. В принципе, для короткоживущих сертификатов от механизма отзыва собираются вообще отказаться, но тут адрес CRL все же указан (отчасти, потому что это сертификат для IP-адреса).

Хвост сертификата, с сокращениями:

            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : E3:23:8D:F2:8D:A2:88:E0:AA:E0:AC:F0:FA:90:C9:85:
                                F0:B6:BF:F5:D2:A5:27:B0:01:FC:1C:44:58:C4:B6:E8
                    Timestamp : Apr 26 14:16:45.523 2026 GMT
                    Extensions: 00:00:05:00:36:66:ED:17
                    Signature : ecdsa-with-SHA256
[...]
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : D1:6E:A9:A5:68:07:7E:66:35:A0:3F:37:A5:DD:BC:03:
                                A5:3C:41:12:14:D4:88:18:F5:E9:31:B3:23:CB:95:04
                    Timestamp : Apr 26 14:16:45.489 2026 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
[...]
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
[...]

CT Precertificate SCTs – это подписанные метки времени, полученные для этого сертификата от операторов логов Certificate Transparency.

Далее – повторное указание на тип подписи в сертификате (ecdsa-with-SHA384). Это тип криптосистемы цифровой подписи, использованной УЦ. Тот же идентификатор уже встречался в начале сертификата – так сложилось исторически: идентификатор указывается в двух местах, хотя точно хватило бы и одного, в конце, где приводится сама подпись – Signature Value.

Кстати, в продолжение предыдущей записки: в какой последовательности нужно отключать DNSSEC-записи? Прежде всего – нужно удалять DS-записи из вышестоящей зоны. Дело в том, что именно DS-запись, которая содержит отпечаток ключа, говорит валидирующим резолверам о том, что данная зона “делегирована безопасно”.

Это самый важный момент: делегирующие ответы, с NS-записями, в DNSSEC не подписываются – в этом нет никакого смысла, потому что доверие в DNSSEC формируется по цепочке ключей, а не по адресам/именам серверов. (Собственно, как и во всякой подобной криптографической схеме.) Поэтому подписываются в DNSSEC записи, указывающие на ключи. В случае делегирующего ответа – это DS-запись. Более того, так как необходимо обеспечить криптографическое удостоверение факта отсутствия DS-записи для заданного имени, удостоверяется и то, что конкретной, по имени, DS-записи нет.

Теперь перейдём к процессу отключения DNSSEC. Речь, естественно, о полноценной поддержке, когда DS-записи присутствуют по всей цепочке до корня DNS. Так вот, самая распространённая ошибка – удаление DNSSEC-записей в самой, целевой зоне, без удаления DS-записей в делегирующей зоне. Так делать нельзя потому, что, с точки зрения валидирующего резолвера, тут же развалится доверенное делегирование. Возникает вот какая конфигурация: в ходе рекурсивного опроса резолвер получает DS-запись из делегирующей зоны, и параметры этой записи удостоверены DNSSEC-подписями из делегирующей зоны (по всей цепочке делегирования); однако из целевой зоны резолвер не может получить соответствующего ключа DNSSEC (в DNSKEY-записи), поэтому резолвер определяет, что DNSSEC-цепочка нарушена и возвращает ошибку валидации адресной информации – зона перестаёт работать. При этом, для невалидирующего резолвера, всё “работает” – ведь такой резолвер ничего не знает ни про DS-записи, ни про DNSKEY, ни про подписи (RRSIG). Поскольку сейчас распространённые сервисы DNS-резолвинга валидируют DNSSEC, – например, так делают 1.1.1.1 и Google Public DNS, – то и зона, для которой “повисла DS-запись”, отваливается для многих и многих пользователей.

Поэтому, прежде чем удалять поддержку DNSSEC непосредственно в зоне, нужно удалить DS-запись из делегирующей зоны. Например, в случае example.net – это будет DS-запись в зоне .net. После успешного удаления – нужно подождать какой-то разумно-максимальный срок TTL. Скажем, сутки.

Какая конфигурация получится после того, как делегирующая DS-запись удалена, а в целевой зоне осталась поддержка DNSSEC (ключи и подписи)? После того, как делегирующая зона обновится, в ней появится набор записей, подтверждающих, что DS-запись отсутствует. Вообще, подтверждение отсутствия записи представляет собой в DNSSEC отдельную задачу, которая решается разными способами, но сейчас это не важно – главное: способ подтверждения, при помощи подписи, есть. Теперь валидирующий резолвер может удостовериться, что DS-записи нет, и что зона делегирована “небезопасно”. Соответственно, можно не пытаться проверить DNSSEC-подписи для информации с авторитативных серверов этой зоны. И в такой конфигурации – уже можно без проблем удалить поддержку DNSSEC из целевой зоны: валидирующие резолверы не сломаются.

А при первоначальном запуске поддержки DNSSEC, для неподписанной зоны, необходимо действовать в обратном порядке: сперва разместить DNSSEC-записи, то есть, ключи и подписи; проверить, что всё сходится в целевой зоне – подписи соответствуют ключам, подписанные данные – размещаемым и пр.; и только после этого – разместить DS-запись (обычно – несколько DS-записей) в делегирующей зоне.

Продолжаю потихоньку закрывать то, что адресуется в .ru, .su: убрал A-запись из nox.su, планирую в ближайшие дни отключить там DNSSEC. (Под nox.su была страничка с описанием DNSSEC и примерами настройки.)

(Update, 24/04/2026: отключил для nox.su DNSSEC, удалил DS-запись из зоны .su.)

Раньше самолёты (и не только самолёты, конечно) ориентировались по звёздам. Для автоматизации процесса использовались аналоговые вычислители, которые и сейчас-то иногда превосходят цифровые на некоторых задачах, а уж в 60-х годах прошлого века – только такие и могли бы вычислять координаты в режиме онлайн. Подробное и с картинками описание такой аналоговой системы астронавигации, использовавшейся на борту самолёта B-52, – по ссылке (англ. много букв).

На этой иллюстрации из статьи – аналоговый вычислитель, выполнявший преобразование углов.

(via)

В продолжение предыдущей записки: можно ли вообще обойтись без доменного имени для веб-сайта? Можно, но это доставит некоторых дополнительных проблем, да и “игра” получается с другими правилами. В принципе, сейчас уже можно автоматом заказывать и выпускать TLS-сертификаты для IP-адресов от хорошо известного (доверенного в “коробочных” браузерах) УЦ – это сертификаты от Let’s Encrypt, на шесть дней валидности.

Наличие TLS-сертификата и выделенного IP-адреса позволяет поднять веб-сервер с доверенным TLS прямо по IP-адресу, без использования доменного имени. Вот, посмотрите, я сделал для примера – должно работать в любом распространённом веб-браузере:

185.39.19.199.

Этот URL – использует https, но указан просто IPv4-адрес, а не имя хоста/доменное имя. Сертификат я за несколько секунд выпустил при помощи утилиты certbot и профиля shortlived, всё при nginx в качестве веб-сервера, вот так:

certbot certonly \
--preferred-profile shortlived \
--ip-address 185.39.19.199 \
--webroot --webroot-path /var/www/html/

Да, конечно, нужен выделенный IP-адрес. На одном адресе, в такой схеме, может отвечать только один веб-ресурс (ну, если не использовать хитростей, напоминающих ECH). IP-адрес принадлежит тому или иному оператору, и оператор может его забрать, поменять, перенаправить трафик. Всё то же самое верно и при использовании доменного имени: с той лишь разницей, что, в случае доменного имени, поменять/забрать/перенаправить – касется и домена, и IP-адреса (адресов). Но при прямом использовании IP-адресации не нужна поддержка DNS для соединения с конкретным сайтом из браузера (тут речь именно про конкретный процесс из области веба, так-то, без DNS, не работает и IP тоже).

В принципе, не являясь оператором связи, блок IP-адресов можно приобрести в собственное управление, а потом разрешить анонсировать в Интернет тому или иному оператору, заведя нужные адреса на свой сервер, но вот только это сильно другая история, чем регистрация обычного доменного имени второго уровня; другая история – и технически, и административно, и финансово.

Понятно, что главная-то проблема с таким использованием IP-адресов – это то, что пользователю сложно запомнить обычный адрес. А адресов вида 1.1.1.1 или 8.8.8.8 – очень мало по определению. Кроме того, наверняка будут проблемы с ПО для веба, которое ПО может быть заточено под имена хостов. (Точно будут проблемы с почтовым ПО, но это не веб.)

И всё же, хотя бы возможность простого выпуска TLS-сертификатов для IP-адресов может тут оказаться полезной.

(Но я пока что не планирую переводить dxdt.blog на “чистую” IP-адресацию. Хотя, кто знает.)

Месяц с момента замены доменного имени сайта на dxdt.blog (вместо зоны .ru) – из зоны .ru я перенёс сайт 22 марта 2026 года. За прошедший месяц поисковые сервисы, в основном, обновили ссылки: я сужу по Google, DuckDuckGo и “Яндексу” (в последнем, как ни странно, ситуация со ссылками на dxdt.blog даже лучше, чем я ожидал – я допускал, что там только .ru так и останется, но – нет, поменялось достаточно быстро, это плюс). Старые URL, как я подозреваю, всё ещё попадаются в выдаче, особенно, в DuckDuckGo, поэтому пока что придётся сохранить редирект с dxdt.ru.

Хуже всего, конечно, ситуация со ссылками на различных сайтах в Интернете – там есть ссылки, которым пятнадцать-двадцать лет, и повлиять на эти сайты, чтобы они обновили URL, я не могу. Это вообще проблема с современным состоянием DNS – система предполагалась для установления общей иерархии имён, но сейчас её, как и прочие интернеты, “штормит” с административной точки зрения, что приводит к активному “нарезанию” того, что есть, но уже с совсем другими целями. Поэтому – ничего не поделать: каких-то особо строгих гарантий в DNS и не было, были соглашения и практика здравого смысла, но такое сейчас – роскошь.

Есть и очень много внутренних ссылок на самом сайте: исторически так сложилось, что эти ссылки внутренние только по их происхождению – сами URL там полные и “внешние”, содержат dxdt.ru. Я планирую эти ссылки поменять скриптом в БД, но пока что не дошли руки. После того, как поменяю эти URL, буду уже думать насчёт того, отключить ли редирект на старом имени, которое в .ru, если ещё останется смысл – может, проще будет убрать A-записи.

Кто-то опубликовал черновик (draft) с описанием IPv8, очевидно, сгенерированный при помощи LLM: там во первых же строках предлагается аутентификация узлов с OAuth2, JWT-токенами, “из локального кеша”, и валидация каждого интернет-пакета через специальный DNS8 – дальше же можно не читать черновик, не тратить время. Печально, но теперь пишут на профильных сайтах, что это “организация IETF” выставила “черновик новой версии протокола IP”. Однако на странице данного черновика прямо, на специальной плашке, написано, что IETF никак данный черновик не поддерживает: “This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process”. Что, конечно, не удивительно: потому что не требуется одобрение и поддержка IETF для публикации черновика – кто угодно может опубликовать черновик.

Благодаря влиянию ACME и Let’s Encrypt, сейчас стала очень популярной схема подтверждения права управления доменом (DCV) через DNS, но при помощи размещения CNAME-записей. Речь про запрос TLS-сертификатов средствами автоматизации – скриптами (acme.sh, certbot и др.). Напомню, что DCV здесь состоит в проверке размещения TXT-записи с кодом подтверждения под заданным именем в DNS-зоне (это метод DNS-01). ACME использует специальный префикс: _acme-challenge.

Однако CNAME – это не TXT-запись, а способ перераспределить проверку в другую DNS-зону (см. детали ниже). Вообще, протокол ACME в данном сценарии не требует ни использования, ни даже поддержки CNAME. Но такая поддержка массово используется, и её сейчас принято обосновывать тем, что можно, мол, “не предоставлять доступ к исходной зоне скриптам автоматизации”. Использование CNAME – вообще плохая практика, а особенно плохая практика – это использование CNAME в процессе DCV. Что, конечно, не мешает массовому распространению. Вообще, с подобным использованием CNAME, – то есть, в DCV, – связана пара занятных технических моментов, о которых забывают.

Момент первый: постоянно путают синоним (алиас) и основное имя в CNAME. Дело в том, что CNAME – это Canonical NAME (каноническое имя), и каноническим является именно значение записи, а не имя-носитель. Имя-носитель – это и есть алиас, что бы там ни писали в инструкциях к средствам автоматизации ACME. Если для example.com в CNAME-записи указано 1.2.3mega-blah-blah.example.net, то вот это вот 1.2.3mega-blah-blah.example.net и есть основное имя. При использовании в ACME предлагается настроить CNAME для префикса _acme-challenge. Например, _acme-challenge.example.com в 1.2.3mega-blah-blah.example.net. Но и тут алиасом, в терминах DNS, будет _acme-challenge.example.com, префикс не влияет на отношение значений записей. Такова семантика CNAME.

Соответственно, получается, что проверка проводится для другого имени, не для того, которое указано в ACME-аккаунте при запросе DCV. Сертификат, в итоге, выпускается для одного имени, а проверка – фактически пройдена для совсем другого: для той зоны, которая назначена канонической при помощи CNAME. Дело в том, что CNAME-запись, при интерпретации резолвером, должна приводить к перезапуску процесса рекурсивного опроса для канонического имени, то есть, для значения из CNAME. Да, может показаться, что это технические придирки: всё равно же CNAME-запись должна быть размещена в исходной зоне, совпадающей с именем из DCV. Но нет, не так тут всё просто: CNAME может показывать на совсем другую зону, контроль над которой позволяет проходить DCV и выпускать сертификаты для прочих имён, в том числе, алиасов может быть много – это каноническое имя, по определению, одно. Если домен канонического имени (того, куда указывает CNAME) будет утрачен, переделегирован-перехвачен, или ещё что-то, то это административное изменение прямо коснётся авторизации TLS-сертификата для исходной зоны-алиаса. Происходит подмена самой сути DCV.

Естественно, можно рассуждать иначе: если утрачено каноническое имя, то нужно удалить CNAME-запись в алиасе; тем более, что так как сертификаты сейчас “короткие”, утрата канонического имени обнаружится быстро. Это верно. Более того, имея контроль над исходной зоной (в которой CNAME) – можно будет попробовать отозвать сертификаты для этой зоны, если такие были выпущены при помощи подхвата CNAME. (Один из штатных способов отзыва сертификата в ACME – прохождение DCV для имён из сертификата; но нужно предъявить сам сертификат, и должно всё сойтись по составу имён – то есть, если в подставном сертификате указана ещё какая-то зона, то могут быть проблемы с отзывом.) Однако это всё только теоретические рассуждения, в стиле “как должно быть”, а на практике, как говорится: ну, на практике-то – и про CNAME-зоны забывают, и про обновление имён, и про отзыв.

Момент второй: реальный доступ к зоне. Из первого момента, с каноническим именем, легко выводится этот второй: да, использование CNAME предлагают в качестве решения проблемы “расползания реквизитов доступа”. Мол, не хочется давать скриптам ACME доступ к редактированию нашей важной доменной зоны, поэтому пропишем CNAME и дадим доступ в другую зону, не такую важную. Но, как бы, смысл DCV – проверка права управления доменной зоной, а тут – это право управления прямо предлагают не выдавать, а подменить саму зону средствами DNS. Опять же, такая трактовка – не “перегиб”: дело в том, что управление зоной должно, если по-хорошему, подтверждаться при каждом выпуске сертификата (ну, хорошо, с некоторым интервалом по времени действия успешной проверки), а CNAME, направленная на каноническое имя – это долгий и универсальный вариант, не привязанный к выпуску сертификата вовсе. Для чего, собственно, использование CNAME и затевается. Опять противоречие.

Кстати, тут полезно вспомнить, что есть и суперновая версия DNS-проверки в ACME – с “постоянной” привязкой ACME-аккаунта к имени: вот где совсем не место CNAME (но черновик RFC пока что их не запрещает явно).

CNAME-записи – одни из самых сложных по поведению в DNS, а их использование – источник неожиданных проблем. В случае DCV, семантика и принципы интерпретации CNAME вообще противоречат основной логике проверки права управления через DNS. Что касается других решений: во-первых, ACME-префикс можно делегировать на отдельные NS, без всяких CNAME; во-вторых, для размещения TXT-записей вовсе не обязательно передавать полные права управления DNS-зоной каким-то скриптам. Это всё решения на стороне, заказывающей DCV. Но самое правильное, конечно, это не следовать CNAME при проверке DCV на стороне систем УЦ.

О тонкостях литературного английского. В известном произведении The Hitchhiker’s Guide to the Galaxy (“Путеводитель хичхайкера по Галактике”/”Автостопом по Галактике”) Дуглас Адамс, описывая в одной из глав свершения смелых космических первопроходцев, использует следующую фразу (выделена пожирнением):

And all dared to brave unknown terrors, to do mighty deeds, to boldly split infinitives that no man had split before – and thus was the Empire forged.

Неплохой образец английского литературного юмора. Проблема, как обычно, в том, что перевести невозможно. Да, тут, на первый взгляд, представлены лишь самые доступные языковые конструкции и нет “сложных слов”. Однако перевести эту фразу на русский, даже с близким сохранением смысла, не получится. Объяснить – можно. Я попробую сделать это ниже. (Занятно, что даже и при чтении на языке оригинала нужны дополнительные данные для построения контекста, раскрывающего смысл.)

Причин этому две, и обе – чисто языковые: во-первых, во фразе заложена юмористическая аллюзия на литературный элемент поп-культуры, отсутствующий в русском языковом пространстве (см. ниже); во-вторых, фраза специально содержит спорную грамматическую конструкцию, которая возможна только в английском языке, и при этом прямо отсылает к самому предмету спора, возникающего вокруг этой грамматической конструкции. В общем, закручено и накручено.

Дословный перевод выделенного фрагмента, но с учётом общего контекста в оригинале: “смело разделять инфинитивы, которые никто не разделял прежде” – но эта фраза на русском выглядит странной и пустой. Так и должно быть, а детали придётся разбирать отдельно.

Прежде всего – “to boldly split”. Это явление, которое в английском языкознании называется split infinitive – “расщеплённый” инфинитив (можно обозначать и другими русскоязычными терминами, но здесь будет “расщеплённый”). Инфинитив – infinitive – это неопределённая форма глагола: “знать”, “читать”, “писать”. В английском языке инфинитив записывается (но не образуется, заметьте) при помощи to – примеры: to know, to write, to read. Расщепление – это практика внедрения между to и “глаголом инфинитива” одного или нескольких дополнительных слов; обычно, внедряется наречие, как и в нашем случае: to boldly split. И этот грамматический процесс относится к одному из самых спорных моментов. Причём споры, с викторианских времён, идут среди образованных носителей английского. Многие и сейчас считают такое расщепление недопустимым нарушением грамматического строя, речевой ошибкой. Но это, ещё раз, мнение спорное.

To boldly split – нетрудно перевести как “смело (или отважно) разделять”. Проблема в слове boldly. Строгие варианты такие: “boldly to split” или “to split boldly”. Но ни один, ни другой – не выглядят смешно. Прежде всего потому, что сама эта фраза – прямая отсылка к оригинальному сериалу Star Trek. Фраза-заставка к эпизодам этого классического сериала известна как “Where no man has gone before”, и используется постоянно. Этим словам, в оригинальном тексте вступления, предшествует не менее знаменитое (но уже в узких кругах) “To boldly go”.

Расщепление полностью, в версии Star Trek, будет таким: “To boldly go where no man has gone before!” – “Смело идти туда, где не ступала нога человека!”. Заметили тот самый расщеплённый инфинитив? To boldly go. Это и есть предмет аллюзии: грамматически спорная конструкция о том же boldly, расщепляющем инфинитив (многие литераторы и филологи, – особенно, в 60-х годах 20 века, – скажут, что это не “спорная”, а точно грамматически неверная конструкция).

“Путеводитель” – комическая космическая повесть. Star Trek – космический сериал, с понятной каждому английскому грамматическому пуристу речевой ошибкой в тексте вступления, зачитываемого в начале каждой серии. Думаю, теперь первый юмористический момент, – про “расщепление инфнитивов” в Star Trek, – понятен. Передать его на русском не получится, ввиду отсутствия соответствующего культурного феномена – вступления к сериям Star Trek 60-х годов.

Сама же идея о недопустимости “расщепления инфинитива” в английском, похоже, идёт из попытки насаждения языковых реалий из латыни – это было довольно популярным действием среди пуристов в викторианский период (вторая половина 19 века, в основном). Но, в латыни, понятно, расщеплять инфинитив невозможно (как и в русском) – просто потому, что в латыни для этого нет подходящего “to” (его и в английском, на самом деле, нет, но это другая история). В начале 21 века расщепление инфинитива в английском начали, под давлением языковых реалий, официально признавать допустимым.

В оксфордском словаре Фаулера (H. W. Fowler, A Dictionary of Modern English Usage, изд. 1965) есть замечательный пример фразы, в которой попытка избежать расщепления инфинитива приводит к плачевным последствиям:

The greatest difficulty about assessing the economic achievements of the Soviet Union is that its spokesmen try absurdly to exaggerate them; in consequence the visitor may tend badly to underrate them.

То есть, экономические достижения Советского Союза – “его представители абсурдно пытаются преувеличивать”, а посещающие СССР, в результате, “сильно/грубо недооценивают их”. Здесь наречия (“абсурдно”, “сильно” или “грубо”) оказываются прицеплены не к тем глаголам, что звучит несколько странно. И странность звучания помогает понять второй аспект юмора “расщепляющихся инфинитивов” в первоначальной цитате из The Hitchhiker’s Guide to the Galaxy, который в русском переводе тоже передать невозможно, по причине отсутствия в русских инфинитивах расщепимости.

(На День Космонавтики эту записку выпустить не успел – что-то завозился, – но, думаю, ещё не поздно: да и не откладывать же на следующий год, верно? С прошедшим Днём Космонавтики!)

В рамках “ренейминга”, связанного с миграцией сайта с доменов .ru, сделал субординатные имена авторитатвиных серверов DNS для dxdt.blog. “Субординатные” – означает, что имена авторитативных серверов (NS) находятся в той же зоне, которая делегирована на эти серверы: например, ns1.example.com, ns2.example.com для example.com. Такую схему именования ещё иногда называют “красивые NSы”. В случае dxdt.blog, имена NS-ов – в зоне dxdt.blog.

Соответственно, делегирующий ответ с такими именами обязательно содержит так называемые glue-записи – то есть, записи с информацией об IP-адресах NSов. Иначе рекурсивный опрос не будет работать, так как зациклится. Я об этом писал неоднократно, в том числе, про сложную рекурсию, связанную с перекрёстными зависимостями.

Например, сама зона .blog размещена на NS-ах с субординатными именами:

alex@garlic-crusher:~$ dig blog. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
blog.			172800	IN	NS	a.ns.nic.blog.
blog.			172800	IN	NS	d.ns.nic.blog.
blog.			172800	IN	NS	c.ns.nic.blog.
blog.			172800	IN	NS	b.ns.nic.blog.

;; ADDITIONAL SECTION:
[...]

– здесь имена авторитативных серверов в ns.nic.blog., пусть для корневой зоны это и не имееет большого значения (см. ниже). Да, субординатные имена популярны, однако мне подобная схема именования не очень нравится. Другой вариант, из зон верхнего уровня, можно наблюдать в .ru:

alex@garlic-crusher:~$ dig ru. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
ru.			172800	IN	NS	a.dns.ripn.net.
ru.			172800	IN	NS	d.dns.ripn.net.
ru.			172800	IN	NS	f.dns.ripn.net.
ru.			172800	IN	NS	b.dns.ripn.net.
ru.			172800	IN	NS	e.dns.ripn.net.

;; ADDITIONAL SECTION:
[...]

Однако, если говорить строго, то окажется, что любое имя в глобальной DNS Интернета так или иначе связано с “субординатными” NS-ами: потому что в делегирующих ответах, в качестве основного состава, могут быть только хостнеймы – имена серверов, и в какой-то момент рекурсивного опроса DNS обязательно возникнет проблема “курицы и яйца”. Более того, в DNS наступление такой проблемы можно откладывать до уровня корневой зоны, но вот IP-адреса серверов корневой зоны – распространяются по рекурсивным резолверам тем или иным способом, отличным от DNS (исторически – это всем известный hints-файл), именно для того, чтобы система заработала при первоначальном запуске.