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

9

У нас возникают проблемы при создании длинной записи TXT для ключа DKIM в веб-интерфейсе нашего хостера.

Каждая строка может принимать только 256 символов.

Мы попробовали несколько строк, затем попытались добавить ("в первую и ")после последней, как некоторые предполагают. Ни то, ни другое не работает.

Затем мы попытались сделать cname для записи на другом хостере, где мы можем сделать записи DKIM TXT.

Но теперь веб-интерфейс жалуется на незаконное имя в CNAMEзаписи.

mail._domainkey.example.com TXTхорошо
mail._domainkey.example.com CNAMEне хорошо
mail.domainkey.example.com CNAMEэто хорошо, но не то, что мы хотим.

Является ли вебинтерфейс только для того, чтобы сводить нас с ума, или это действительно "незаконно", чтобы подчеркивание CNAME?

domain-name-system opendkim

— Lenne
источник

1

Поставщик исправляет веб-интерфейс, поскольку я пишу это!

— Ленн

18

Да, 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

— Свен
источник

Но является ли CNAME именем хоста? Некоторая документация показывает использование подчеркивания в cname, так что, очевидно, это работает. kb.mailchimp.com/accounts/email-authentication/…

— Ленн

Кроме того, подчеркивания появляются в записях DNS в зонах MS Windows, интегрированных в Active Directory, которые лежат в основе доменов Windows, по крайней мере, в инструменте управления DNS от Microsoft, но я не уверен, являются ли эти подчеркивания частью имени, и Windows поддерживает подчеркивания в DNS запросы, или если подчеркивания появляются только в оснастке управления DNS и фактически не являются частью имен.

— Тодд Уилкокс

Обратите внимание, что цитируемая запись в Википедии связана с именами в Интернете, а не с DNS.

— Джим Б

@ Lenne: CNAME является допустимым именем хоста, потому что это псевдоним хоста. @ToddWilcox: да, это известно, и это (преднамеренное?) Нарушение спецификации со стороны MS, которое не вызвало других проблем, поскольку они появляются в пакетах DNS, DHCP,… несмотря на то, что они не являются законными.

— Мирабилось

2

@mirabilos «CNAME - это действительное имя хоста» нет, цель (RDATA) CNAME - это имя домена, а не имя хоста (имя домена является расширенным набором всех возможных имен хостов). _foo CNAME _barвполне законно, вы можете проверить с named-checkzone.

— Патрик Мевзек

2

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

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

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

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

— Джим Б
источник

«В DNS разрешены любые допустимые символы», это немного сложнее. Есть доменные имена и имена хостов. За исключением случаев, когда указано иное, везде у вас есть ярлыки, которые являются доменными именами, что на самом деле означает любой символ, _или что-то еще, что вам нравится. Но для некоторых записей вы можете использовать только имена хостов, а не доменные имена. Имена хостов - это только буквы, цифры и дефисы, больше ничего. Например, владельцем записи Aили AAAAявляется имя хоста, а не имя домена. RDATA (цель) NSзаписи также является именем хоста, а не именем домена.

— Патрик Мевзек

1

«MX-запись может содержать значение« Алиса », но после поиска это значение следует отклонить, поскольку« Алиса »не является действительным адресом электронной почты». С каких пор MX RRs ссылаются на адреса электронной почты?

— CVn

0

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

— micmav
источник

У меня также есть проблемы с Arduino, где некоторые библиотеки дают имя хоста, например ESP_245537, это имя отклоняется, когда DHCP-сервер пытается обновить DNS.

— Ленн

Это не верно. Метка CNAME не обязательно является именем хоста, поэтому здесь допустимы все символы, включая _.

— Патрик Мевзек

1

И даже без этого, это старые правила. Они запрещали имена хостов, начинающиеся с цифры, но для приспособления, 3com.comнапример, это правило было смягчено, см. Tools.ietf.org/html/rfc1123#page-13 «Настоящим изменен один аспект синтаксиса имени хоста: ограничение на первый символ расслаблен, чтобы позволить или букву или цифру. "

— Патрик Мевзек

@Lenne if esp_245537используется в качестве имени хоста, тогда в обновлении DNS должно быть отказано, поскольку оно не является допустимым именем хоста. Если это имя используется в качестве имени домена, обновление DNS должно быть успешным (в противном случае это ошибка), поскольку это допустимая метка DNS.

— Патрик Мевзек

Я видел намеки на то, что можно переводить недопустимые символы с DHCP на DNS, но так и не получил его на работу.

— Ленн

0

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

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)

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

Для других записей все наоборот: для 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записи, как у настоящей зоны)

— Патрик Мевзек
источник