La réponse à votre question spécifique est NON , Active Directory n'autorise PAS les espaces dans DNS hôte . Les caractères interdits sont clairement décrits dans l'article KB 909264 - Conventions de dénomination dans Active Directory pour les ordinateurs, les domaines, les sites et les unités d'organisation dans la section intitulée Caractères interdits qu'il lit:
Le nom d'hôte DNS ne peut pas contenir de caractères vides ou d'espace.
Pour étendre la réponse au-delà d'Active Directory au système de noms de domaine DNS en général, la situation est un peu plus délicate car, bien que techniquement les espaces soient autorisés dans certains cas, en pratique, vous ne rencontrerez probablement jamais un tel cas vous-même.
La réponse courte: N'UTILISEZ PAS D'ESPACES DANS LES HÔTELS DNS!
La réponse longue selon § 2 de la RFC 3696, Restrictions sur les noms de domaine (DNS), est que:
Tous les caractères ou combinaisons de bits (sous forme d'octets) sont autorisés dans les noms DNS.
Il continue à dire (soulignement le mien):
Cependant, il existe une forme préférée qui est requise par la plupart des applications. Cette forme préférée a été la seule autorisée dans les noms de domaines de premier niveau, ou TLD. En général, c'est aussi le seul formulaire autorisé dans la plupart des noms de deuxième niveau enregistrés dans les TLD,
bien que certains noms qui ne sont normalement pas vus par les utilisateurs obéissent à d'autres règles. Il dérive des règles ARPANET d'origine pour la dénomination des hôtes (c'est-à-dire la règle "hostname") et est peut-être mieux décrit comme la "règle LDH", après les caractères qu'il autorise. La règle LDH, telle que mise à jour, prévoit queles étiquettes (mots ou chaînes séparés par des points) qui composent un nom de domaine doivent être constituées uniquement des caractères alphabétiques et numériques ASCII [ASCII], plus le tiret. Aucun autre symbole ou caractère de ponctuation n'est autorisé, pas plus que l'espace vide.
Si le trait d'union est utilisé, il n'est pas autorisé d'apparaître au début ou à la fin d'une étiquette. Il existe une règle supplémentaire qui exige essentiellement que les noms de domaine de niveau supérieur ne soient pas entièrement numériques.
En pratique, cela signifie que vous ne devez PAS utiliser d'espaces , même si dans la spécification la plus générale des noms de domaine telle que définie dans ces extraits du §5.1 de la RFC 1035, il est possible d'autoriser les espaces dans les noms de domaine:
Les <nom-domaine> constituent une part importante des données du fichier maître. Les étiquettes du nom de domaine sont exprimées sous forme de chaînes de caractères et séparées par des points. Les conventions de citation permettent de stocker des caractères arbitraires dans les noms de domaine.
et
<character-string> s'exprime d'une ou de deux façons: comme un ensemble contigu de caractères sans espaces intérieurs, ou comme une chaîne commençant par un "et se terminant par un". À l'intérieur d'une "chaîne délimitée, n'importe quel caractère peut apparaître, à l'exception d'un" lui-même, qui doit être cité à l'aide de \ (barre oblique inverse).
Gardez à l'esprit qu'ailleurs dans la RFC 1035, en particulier le §2.3 , il avertit:
2.3. Conventions
Le système de domaine a plusieurs conventions traitant des problèmes de bas niveau, mais fondamentaux. Bien que l'implémenteur soit libre de violer ces conventions DANS SON PROPRE SYSTÈME, il doit respecter ces conventions dans TOUS les comportements observés à partir d'autres hôtes.
2.3.1. Syntaxe des noms préférés
Les spécifications DNS tentent d'être aussi générales que possible dans les règles de construction des noms de domaine. L'idée est que le nom de tout objet existant peut être exprimé sous la forme d'un nom de domaine avec un minimum de changements.
Cependant, lors de l'attribution d'un nom de domaine à un objet, l'utilisateur prudent sélectionnera un nom qui satisfait à la fois les règles du système de domaine et toutes les règles existantes pour l'objet, que ces règles soient publiées ou implicites par les programmes existants.
Par exemple, lors de la désignation d'un domaine de messagerie, l'utilisateur doit satisfaire à la fois aux règles de ce mémo et à celles de la RFC-822. Lors de la création d'un nouveau nom d'hôte, les anciennes règles de HOSTS.TXT doivent être suivies. Cela évite les problèmes lorsque l'ancien logiciel est converti pour utiliser des noms de domaine.
Je serais certainement heureux de recevoir des éclaircissements ou des corrections supplémentaires sur mon interprétation, mais veuillez ne pas le faire à moins que vous ne puissiez citer des sections spécifiques des RFC pour affirmer ou nier cette interprétation.