Does Active Directory support DNS names with spaces?

A domain name can include any binary octet in the range 0 to 255.

However if your AD entries represent host names, then a space is not a valid character. A host name (i.e. a domain name that points to an A or AAAA record) must follow the rules from RFC 1123, which essentially restricts the legal characters to LDH ("letter digit hyphen").

Hence for other entries it's perfectly possible that MS have misinterpreted the RFCs. They won't be the first, and they certainly won't be the last.

References

§5.1 of RFC 1035:

Quoting conventions allow arbitrary characters to be stored in domain names.

and §6.1.3.5. of RFC 1123:

The DNS defines domain name syntax very generally -- a string of labels each containing up to 63 8-bit octets, separated by dots

and §11 of RFC 2181:

any binary string whatever can be used as the label of any resource record

Ah - sorry to be snippy, but you have a wag the dog here. It is not that AD does not support DNS names with spaces, but that DNS names per definition and RFC are not allowed to have spaces to start with. RFC 952 and 1123 both do not allow spaces as part of a DNS name.

So, AD does not lack support for spaces in DNS names as a shortcoing but because it follows the same rules as everyone else.

The answer to your specific question is NO, Active Directory does NOT allow spaces in DNS hostnames. The prohibited characters are clearly outlined in KB 909264 - Naming conventions in Active Directory for computers, domains, sites, and OUs in the section labeled Disallowed characters it reads:

The DNS host name cannot contain blank or space characters.

To extend the answer beyond Active Directory to the DNS domain name system in general the situation is a little trickier because while spaces technically are allowed in certain instances, in practice you will probably never encounter such a case yourself.

The short answer: DO NOT USE SPACES IN DNS HOSTNAMES!

The long answer according to §2 of RFC 3696, Restrictions on domain (DNS) names, is that:

Any characters, or combination of bits (as octets), are permitted in DNS names.

It continues stating (emphasis mine):

However, there is a preferred form that is required by most applications. This preferred form has been the only one permitted in the names of top-level domains, or TLDs. In general, it is also the only form permitted in most second-level names registered in TLDs, although some names that are normally not seen by users obey other rules. It derives from the original ARPANET rules for the naming of hosts (i.e., the "hostname" rule) and is perhaps better described as the "LDH rule", after the characters that it permits. The LDH rule, as updated, provides that the labels (words or strings separated by periods) that make up a domain name must consist of only the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen. No other symbols or punctuation characters are permitted, nor is blank space. If the hyphen is used, it is not permitted to appear at either the beginning or end of a label. There is an additional rule that essentially requires that top-level domain names not be all-numeric.

In practice this means you should NOT use spaces, even though in the most general specification of domain names as defined in these excerpts from §5.1 of RFC 1035 it is possible to allow spaces in domain names:

<domain-name>s make up a large share of the data in the master file. The labels in the domain name are expressed as character strings and separated by dots. Quoting conventions allow arbitrary characters to be stored in domain names.

and

<character-string> is expressed in one or two ways: as a contiguous set of characters without interior spaces, or as a string beginning with a " and ending with a ". Inside a " delimited string any character can occur, except for a " itself, which must be quoted using \ (back slash).

Keep in mind that elsewhere in RFC 1035, specifically §2.3, it warns:

2.3. Conventions

The domain system has several conventions dealing with low-level, but fundamental, issues. While the implementor is free to violate these conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in ALL behavior observed from other hosts.

2.3.1. Preferred name syntax

The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes.

However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs.

For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names.

I would certainly welcome further clarification or correction of my interpretation, but please do not do so unless you're able to cite specific sections of RFCs to either affirm or deny this interpretation.