У нас возникли проблемы с созданием длинной записи TXT для ключа DKIM в веб-интерфейсе нашего хостера.
Каждая строка может принимать только 256 символов.
Мы пробовали несколько строк, затем пытались добавить (" сначала и ") после последнего, как некоторые предполагают. Ни то, ни другое не работает.
Затем мы попытались сделать cname для записи на другом хостере, где мы жестяная банка сделать записи DKIM TXT.
Но теперь веб-интерфейс жалуется на незаконное имя в CNAME запись.
mail._domainkey.example.com TXT в порядке
mail._domainkey.example.com CNAME не в порядке
mail.domainkey.example.com CNAME это нормально, но не то, что мы хотим.
Веб-интерфейс просто настроен свести нас с ума, или действительно "незаконно" использовать подчеркивания в CNAME?
Да, DNS-имена (включая A / AAAA) могут содержать только [0-9], [a-z], -, поэтому подчеркивание недопустимо. Обратите внимание, что запись TXT не является именем хоста, и это ограничение на нее не распространяется. И последнее изменение: - также нельзя использовать в качестве первого символа, поэтому mail.-domainkey.our.dom не будет действительным.
https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames
Окончательное редактирование: я был частично неправ. Когда CNAME используется в качестве имени хоста, применяются вышеуказанные ограничения. Похоже, CNAME не считается именем хоста в контексте DKIM, и в этом случае _ должен быть допустимой частью записи CNAME. Видеть https://stackoverflow.com/questions/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491#26692491
В DNS разрешены любые допустимые символы. Видеть https://tools.ietf.org/html/rfc2181#section-11
«Сама DNS накладывает только одно ограничение на конкретные метки, которые могут использоваться для идентификации записей ресурсов. Это одно ограничение относится к длине метки и полного имени. Длина любой метки ограничена от 1 до 63 октетов. "
Клиент должен проверить значения имени. Например, запись MX может содержать значение «Алиса», но после поиска это значение должно быть отклонено, поскольку «Алиса» не является допустимым адресом электронной почты.
В этом случае похоже, что ваш хостер «проверяет» ваш ввод, и он сможет ввести его вручную для вас.
RFC 1034: метки должны соответствовать правилам для имен хостов ARPANET. Они должны начинаться с буквы, заканчиваться буквой или цифрой и иметь в качестве внутренних символов только буквы, цифры и дефис. Также есть некоторые ограничения по длине. Ярлыки должны содержать не более 63 символов.
Ответ @Sven с редактированием уже верен, но просто для прямой формулировки.
TL; DR да подчеркивание допустимо в CNAME записывайте с обеих сторон, прочтите ниже, почему.
RFC 1034 и другие определяют записи на основе "доменных имен", которые представляют собой метки с любым символом, включая _.
Но некоторые записи имеют более строгие правила для имени владельца и / или данных ресурса (RDATA). Будет принято только имя хоста, и действительно теперь правила (они были ослаблены в прошлом, когда имя хоста не могло начинаться с цифры), что вы можете использовать любую букву ASCII (без учета регистра), любые цифры ASCII и дефисы , плюс некоторые дополнительные правила размещения: без дефиса в начале и в конце и без двойных дефисов в позициях 3 и 4 (из-за "резервирования" для IDN, которые имеют форму 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:
«владелец: это доменное имя, на котором находится 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 записи, как в настоящей зоне)