Является ли _ (подчеркивание) незаконным в записи CNAME?

Да, DNS-имена (включая A/AAAA) могут содержать только [0-9], [a-z], -, поэтому подчеркивание недействительно. Обратите внимание, что запись TXT не является именем хоста, и это ограничение не распространяется на нее. И последнее изменение: - не может быть использован в качестве первого символа, так mail.-domainkey.our.dom не будет действительным

https://en.wikipedia.org/wiki/Hostname

Окончательное редактирование: я был частично неправ. Когда в качестве имени хоста используется CNAME, применяются вышеуказанные ограничения. Похоже, что CNAME не считается именем хоста в контексте DKIM, и в этом случае _ должна быть действительной частью записи CNAME. См. https://stackoverflow.com/questions/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491

@ Ответ Свена, с правкой, уже правильный, но только для того, чтобы прямо сформулировать.

TL; DR да подчеркивание действительно в CNAME запись с обеих сторон, читайте ниже, почему.

RFC 1034 и другие определяют записи на основе "доменных имен", которые представляют собой метки с любым символом, включая _,

Но некоторые записи имеют более строгие правила для имени владельца и / или данных ресурса (RDATA). Там будет принято только имя хоста, и теперь действительно действуют правила (они были смягчены в прошлом, когда имя хоста не могло начинаться с цифры), что вы можете использовать любую букву ASCII (без учета регистра), любые цифры ASCII и дефисы плюс некоторые дополнительные правила позиции: без дефиса в начале или в конце и без двойных дефисов в позициях 3 и 4 (из-за "резервирования" для ИДИ, имеющих форму xn-- что допускается только в случае).

Например, имя владельца A или же AAAA запись - это имя хоста, а не имя домена. Такtest.example.com A 192.0.2.1 действительно, почему все это не так:

_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1

Это легко проверить с помощью named-checkzone программа (часть bind Программное обеспечение сервера имен, но может использоваться и устанавливаться отдельно, а другие серверы имен могут иметь аналогичные инструменты проверки, и в любом случае, вероятно, для этого тоже есть онлайн-интерфейсы), просто поместите записи в файл и запустите его:

$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)

(число перед IN это TTL, это не имеет отношения к нашей проблеме, но необходимо только для проверки синтаксиса записи).

Для других записей это наоборот: для NS нет никаких ограничений на владельца, но есть ограничения на "цель", то есть данные. Данные могут быть только именем хоста, но не именем домена, потому что вам нужно указать на авторитетные серверы имен, которые являются физическими хостами, которые отвечают на запросы DNS.

Теперь о CNAMEВот соответствующие цитаты из RFC 1034 в разделе 3.6:

msgstr "владелец: это доменное имя, в котором находится RR." что означает по умолчанию любое имя, а не просто имя хоста (как источник записи CNAME)

"RDATA: это тип, а иногда и классозависимые данные, которые описывают ресурс:"

"CNAME доменное имя."

Так что оба владельца CNAME (то, что слева от него), и данные ресурса, прикрепленные к нему, его назначение / назначение (то, что справа от него) являются доменными именами, а не только именами хостов. В основном любой персонаж, так в том числе _ разрешено с обеих сторон.

Опять же, легко проверить с named-checkzone:

$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.

Никаких ошибок в CNAME (другие ошибки ожидаются, так как в моей поддельной зоне я не ставил никаких SOA или же NS записи вроде бы в настоящей зоне есть)

В DNS разрешены любые допустимые символы. См. https://tools.ietf.org/html/rfc2181.

"DNS сам накладывает только одно ограничение на конкретные метки, которые можно использовать для идентификации записей ресурсов. Это ограничение касается длины метки и полного имени. Длина любой одной метки ограничена от 1 до 63 октетов. "

Клиент должен проверить значения имени. Например, запись MX может содержать значение "Алиса", но после поиска это значение следует отклонить, поскольку "Алиса" не является действительным адресом электронной почты.

В этом случае похоже, что ваш хостер "проверяет" ваш ввод, и они должны иметь возможность ввести его вручную для вас.

RFC 1034: метки должны соответствовать правилам для имен хостов ARPANET. Они должны начинаться с буквы, заканчиваться буквой или цифрой и содержать в качестве внутренних символов только буквы, цифры и дефис. Есть также некоторые ограничения по длине. Метки должны быть не более 63 символов.