La risposta alla tua domanda specifica è NO , Active Directory NON consente spazi nei nomi host DNS . I caratteri proibiti sono chiaramente indicati in KB 909264 - Convenzioni di denominazione in Active Directory per computer, domini, siti e unità organizzative nella sezione denominata Caratteri non consentiti che legge:
Il nome host DNS non può contenere caratteri vuoti o di spazio.
Per estendere la risposta oltre Active Directory al sistema di nomi di dominio DNS in generale, la situazione è un po 'più complicata perché mentre in alcuni casi gli spazi sono tecnicamente ammessi, in pratica probabilmente non incontrerai mai un caso del genere.
La risposta breve: NON UTILIZZARE GLI SPAZI NEGLI HOSTNAMI DNS!
La risposta lunga secondo §2 della RFC 3696, Restrizioni sui nomi di dominio (DNS), è che:
Qualsiasi carattere o combinazione di bit (come ottetti) sono consentiti nei nomi DNS.
Continua affermando (enfasi la mia):
Tuttavia, esiste un modulo preferito richiesto dalla maggior parte delle applicazioni. Questa forma preferita è stata l'unica consentita nei nomi di domini di primo livello o TLD. In generale, è anche l'unica forma consentita nella maggior parte dei nomi di secondo livello registrati nei TLD,
anche se alcuni nomi che normalmente non sono visti dagli utenti obbediscono ad altre regole. Deriva dalle regole originali di ARPANET per la denominazione degli host (cioè la regola "hostname") ed è forse meglio descritta come "regola LDH", dopo i caratteri che consente. La regola LDH, come aggiornata, lo prevedele etichette (parole o stringhe separate da punti) che compongono un nome di dominio devono essere costituite solo dai caratteri alfabetici e numerici ASCII [ASCII], oltre al trattino. Non sono ammessi altri simboli o segni di punteggiatura, né spazi vuoti.
Se viene utilizzato il trattino, non è consentito apparire all'inizio o alla fine di un'etichetta. Esiste una regola aggiuntiva che richiede essenzialmente che i nomi di dominio di livello superiore non siano tutti numerici.
In pratica questo significa che NON dovresti usare spazi , anche se nella specifica più generale dei nomi di dominio come definita in questi estratti dal §5.1 di RFC 1035 è possibile consentire spazi nei nomi di dominio:
I <domain-name> s costituiscono una grande parte dei dati nel file principale. Le etichette nel nome di dominio sono espresse come stringhe di caratteri e separate da punti. Le convenzioni di quotazione consentono di memorizzare caratteri arbitrari nei nomi di dominio.
e
<character-string> è espresso in uno o due modi: come un insieme contiguo di caratteri senza spazi interni o come una stringa che inizia con un "e termina con un". All'interno di una "stringa delimitata, può verificarsi qualsiasi carattere, ad eccezione di un" stesso, che deve essere citato usando \ (barra rovesciata).
Tieni presente che altrove in RFC 1035, in particolare §2.3 , avverte:
2.3. Convegni
Il sistema di dominio ha diverse convenzioni che trattano questioni di basso livello, ma fondamentali. Mentre l'implementatore è libero di violare queste convenzioni ALL'INTERNO DEL SUO PROPRIO SISTEMA, deve osservare queste convenzioni in TUTTI i comportamenti osservati da altri host.
2.3.1. Sintassi del nome preferito
Le specifiche DNS cercano di essere il più generali possibile nelle regole per la costruzione di nomi di dominio. L'idea è che il nome di qualsiasi oggetto esistente possa essere espresso come nome di dominio con modifiche minime.
Tuttavia, quando si assegna un nome di dominio per un oggetto, l'utente prudente selezionerà un nome che soddisfi sia le regole del sistema di dominio sia le regole esistenti per l'oggetto, indipendentemente dal fatto che tali regole siano pubblicate o implicite da programmi esistenti.
Ad esempio, quando si assegna un nome a un dominio di posta, l'utente deve soddisfare sia le regole di questo memo sia quelle in RFC-822. Quando si crea un nuovo nome host, è necessario seguire le vecchie regole per HOSTS.TXT. Questo evita problemi quando il vecchio software viene convertito per usare nomi di dominio.
Gradirei sicuramente ulteriori chiarimenti o correzioni della mia interpretazione, ma per favore non farlo a meno che tu non sia in grado di citare sezioni specifiche di RFC per affermare o negare questa interpretazione.