A resposta para sua pergunta específica é NÃO , o Active Directory NÃO permite espaços nos nomes de host DNS . Os caracteres proibidos estão claramente descritos no KB 909264 - Convenções de nomenclatura no Active Directory para computadores, domínios, sites e OUs na seção Caracteres não permitidos, que se lê:
O nome do host DNS não pode conter caracteres em branco ou em espaço.
Para estender a resposta além do Active Directory para o sistema de nomes de domínio DNS em geral, a situação é um pouco mais complicada, porque embora espaços tecnicamente sejam permitidos em certos casos, na prática, você provavelmente nunca encontrará esse caso.
A resposta curta: NÃO USE ESPAÇOS NOS HOSTNAMES DNS!
A resposta longa, de acordo com o §2 da RFC 3696, Restrições aos nomes de domínio (DNS), é que:
Quaisquer caracteres ou combinação de bits (como octetos) são permitidos nos nomes DNS.
Continua declarando (grifo meu):
No entanto, existe uma forma preferida exigida pela maioria dos aplicativos. Esse formulário preferido foi o único permitido nos nomes de domínios de nível superior ou TLDs. Em geral, também é a única forma permitida na maioria dos nomes de segundo nível registrados nos TLDs,
embora alguns nomes que normalmente não são vistos pelos usuários obedeçam a outras regras. Deriva das regras originais da ARPANET para a nomeação de hosts (isto é, a regra "hostname") e talvez seja melhor descrita como "regra LDH", após os caracteres que ela permite. A regra LDH, conforme atualizada, fornece queos rótulos (palavras ou sequências separadas por pontos) que compõem um nome de domínio devem consistir apenas nos caracteres alfabéticos e numéricos ASCII [ASCII], além do hífen. Nenhum outro símbolo ou caractere de pontuação é permitido, nem espaço em branco.
Se o hífen for usado, não será permitido que apareça no início ou no final de um rótulo. Existe uma regra adicional que exige essencialmente que os nomes de domínio de nível superior não sejam todos numéricos.
Na prática, isso significa que você NÃO deve usar espaços , embora na especificação mais geral de nomes de domínio, conforme definido nesses trechos do §5.1 da RFC 1035 , seja possível permitir espaços nos nomes de domínio:
Os <domain-name> s representam um grande compartilhamento dos dados no arquivo mestre. Os rótulos no nome do domínio são expressos como cadeias de caracteres e separados por pontos. As convenções de cotação permitem que caracteres arbitrários sejam armazenados em nomes de domínio.
e
<caractere> é expresso de uma ou duas maneiras: como um conjunto contíguo de caracteres sem espaços interiores ou como uma sequência que começa com "e termina com". Dentro de uma "string delimitada, qualquer caractere pode ocorrer, exceto um" em si, que deve ser citado usando \ (barra invertida).
Lembre-se de que em outras partes da RFC 1035, especificamente §2.3 , ele alerta:
2.3 Convenções
O sistema de domínio possui várias convenções que lidam com questões de baixo nível, mas fundamentais. Enquanto o implementador é livre para violar essas convenções DENTRO DE SEU PRÓPRIO SISTEMA, ele deve observar essas convenções em TODO o comportamento observado de outros hosts.
2.3.1 Sintaxe de nome preferida
As especificações de DNS tentam ser o mais genéricas possível nas regras para a construção de nomes de domínio. A ideia é que o nome de qualquer objeto existente possa ser expresso como um nome de domínio com alterações mínimas.
No entanto, ao atribuir um nome de domínio para um objeto, o usuário prudente selecionará um nome que satisfaça as regras do sistema de domínio e quaisquer regras existentes para o objeto, sejam elas publicadas ou implícitas pelos programas existentes.
Por exemplo, ao nomear um domínio de email, o usuário deve atender às regras deste memorando e às do RFC-822. Ao criar um novo nome de host, as regras antigas para HOSTS.TXT devem ser seguidas. Isso evita problemas quando um software antigo é convertido para usar nomes de domínio.
Eu certamente agradeceria mais esclarecimentos ou correções de minha interpretação, mas não o faça, a menos que você possa citar seções específicas de RFCs para afirmar ou negar essa interpretação.