Domain names in messages are expressed in terms ofa sequence of labels. Each label is represented asaone octet length field followed by that numberof octets. The domain name terminates withthe zerolength octet forthenull label ofthe root. Note that this field may be an odd numberof octets; no padding is used.
The following syntax will result in fewer problems with many applications that usedomainnames (e.g., mail, TELNET).
<domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= any one of the 52 alphabetic characters A through Z in uppercaseand a through z inlowercase <digit> ::= any one of the ten digits 0through9
Note that whileupperandlowercase letters are allowed indomain names, no significance is attached to the case. That is, two nameswith the same spelling but different caseareto be treated asif identical.
The labels must follow the rulesfor ARPANET host names. They must startwith a letter, endwith a letter or digit, and have as interior charactersonly letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63charactersor less.
Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose.
The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default.
Note however, that the various applications that make use of DNS data can have restrictions imposed on what particular values are acceptable in their environment. For example, that any binary label can have an MX record does not imply that any binary name can be used as the host part of an e-mail address. Clients of the DNS can impose whatever restrictions are appropriate to their circumstances on the values they use as keys for DNS lookup requests, and on the values returned by the DNS. If the client has such restrictions, it is solely responsible for validating the data from the DNS to ensure that it conforms before it makes any use of that data.
DNS was specified in the era of [ASCII]. DNS names were expected to look like most host names or Internet email address right halves (the part after the at-sign, "@") orto be numeric, as in the in-addr.arpa part of the DNS name space. For example,
foo.example.net. aol.com. www.gnu.ai.mit.edu. or 184.108.40.206.in-addr.arpa.
Case-varied alternatives to the above [RFC3092] would be DNS names like
Foo.ExamplE.net. AOL.COM. WWW.gnu.AI.mit.EDU. or 220.127.116.11.in-ADDR.ARPA.
However, the individual octets of which DNS names consist are not limited to valid ASCII character codes. They are 8-bit bytes, and all values are allowed. Many applications, however, interpret them as ASCII characters.