Ответ на ваш конкретный вопрос - НЕТ , Active Directory НЕ разрешает пробелы в именах узлов DNS . Запрещенные символы четко обозначены в KB 909264 - Соглашения об именах в Active Directory для компьютеров, доменов, сайтов и подразделений в разделе, озаглавленном « Запрещенные символы» :
Имя хоста DNS не может содержать пробелы или пробелы.
Распространить ответ за пределы Active Directory на систему доменных имен DNS в целом ситуация немного сложнее, поскольку, хотя в некоторых случаях пробелы технически разрешены, на практике вы, вероятно, никогда не столкнетесь с таким случаем самостоятельно.
Краткий ответ: НЕ ИСПОЛЬЗУЙТЕ ПРОСТРАНСТВА В DNS-ХОСТНАМАХ!
Длинный ответ согласно § 2 RFC 3696 «Ограничения на доменные (DNS) имена» заключается в следующем:
Любые символы или комбинации битов (в виде октетов) разрешены в именах DNS.
Это продолжает заявлять (выделение мое):
Однако существует предпочтительная форма, которая требуется большинству приложений. Эта предпочтительная форма была единственной, разрешенной в именах доменов верхнего уровня или TLD. В целом, это также единственная форма, разрешенная для большинства имен второго уровня, зарегистрированных в TLD,
хотя некоторые имена, которые обычно не видны пользователям, подчиняются другим правилам. Он вытекает из исходных правил ARPANET для именования хостов (т. Е. Правила «имени хоста») и, возможно, лучше описывается как «правило LDH» после символов, которые он разрешает. Обновленное правило LDH предусматривает, чтометки (слова или строки, разделенные точками), составляющие доменное имя, должны состоять только из буквенных и цифровых символов ASCII [ASCII], а также дефиса. Другие символы или знаки пунктуации не допускаются, а также пробелы.
Если используется дефис, он не может появляться ни в начале, ни в конце метки. Существует дополнительное правило, которое требует, чтобы доменные имена верхнего уровня не были полностью числовыми.
На практике это означает, что вы НЕ ДОЛЖНЫ использовать пробелы , даже если в самой общей спецификации доменных имен, как определено в этих выдержках из §5.1 RFC 1035, можно разрешить пробелы в доменных именах:
<domain-name> составляют большую долю данных в главном файле. Метки в доменном имени представлены в виде символьных строк и разделены точками. Соглашения о цитировании позволяют хранить произвольные символы в доменных именах.
а также
<символьная строка> выражается одним или двумя способами: в виде непрерывного набора символов без внутренних пробелов или в виде строки, начинающейся с «и заканчивающейся на». Внутри «строки с разделителями может встречаться любой символ, кроме самого», который должен быть заключен в кавычки с помощью \ (обратная косая черта).
Имейте в виду, что в другом месте в RFC 1035, в частности, в §2.3 , он предупреждает:
2,3. Условные обозначения
Система доменов имеет несколько соглашений, касающихся низкоуровневых, но фундаментальных вопросов. Хотя разработчик может свободно нарушать эти соглашения В СВОЕЙ СОБСТВЕННОЙ СИСТЕМЕ, он должен соблюдать эти соглашения во ВСЕМ поведении, наблюдаемом от других хостов.
2.3.1. Предпочитаемый синтаксис имени
Спецификации DNS пытаются быть максимально общими в правилах построения доменных имен. Идея заключается в том, что имя любого существующего объекта может быть выражено как доменное имя с минимальными изменениями.
Однако при назначении доменного имени для объекта разумный пользователь выберет имя, которое удовлетворяет как правилам доменной системы, так и любым существующим правилам для объекта, независимо от того, публикуются ли эти правила или подразумеваются существующими программами.
Например, при именовании почтового домена пользователь должен удовлетворять как правилам этой памятки, так и правилам в RFC-822. При создании нового имени хоста должны соблюдаться старые правила для HOSTS.TXT. Это позволяет избежать проблем при конвертации старого программного обеспечения в доменные имена.
Я, конечно, приветствую дальнейшие разъяснения или исправления моей интерпретации, но, пожалуйста, не делайте этого, если только вы не можете привести конкретные разделы RFC, чтобы подтвердить или опровергнуть эту интерпретацию.