There is one additional thing you may need to know: If the host or subdomain part of the url contain an underscore, IE9 (have not tested other versions) cannot write cookies.
So be careful about that. :-)
Recently the CAB-forum (*) decided that
All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019. https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
This means that you are no longer allowed to use underscores in domains that will have a ssl/tls certificate.
(*) The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of leading Certificate Issuers (as defined in Section 2.1(a)(1) and (2) below) and vendors of Internet browser software and other applications that use certificates (Certificate Consumers, as defined in Section 2.1(a)(3) below).
Here my 2 cents from Java world:
From a Spark Scala console, with Java 8:
scala> new java.net.URI("spark://spark_master").getHost
res10: String = null
scala> new java.net.URI("spark://spark-master").getHost
res11: String = spark-master
scala> new java.net.URI("spark://spark_master.google.fr").getHost
res12: String = null
scala> new java.net.URI("spark://spark.master.google.fr").getHost
res13: String = spark.master.google.fr
scala> new java.net.URI("spark://spark-master.google.fr:3434").getHost
res14: String = spark-master.google.fr
scala> new java.net.URI("spark://spark-master.goo_gle.fr:3434").getHost
res15: String = null
It's definitely a bad idea ^^
I followed the link to RFC1034 and read most of it and was surprised to see this:
The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.
For clarification, a domain names are made up of labels which are separated by dots ".". This spec must be outdated because it doesn't mention the use of underscores. I can understand the confusion if anybody stumbles over this spec without knowing it is obsolete. It is obsolete, isn't it?
I followed the link to RFC2181 and read some of it. Especially where it pertains to the issue of what is an authoritative, or canonical, name and the issue of what makes a valid DNS label.
As posted earlier it states there's only a length restriction then to sum it up it reads:
(about names and valid labels)
These are already adequately specified, however the specifications seem to be sometimes ignored. We seek to reinforce the existing specifications.
Kind of leaves me wondering if "a length only restriction" is "adequate". Are we going to start seeing domain names like @#$%!! soon? Isn't the internet screwed up enough?
Clarifying bortzmeyer and David Tonhofer, domain name and subdomain name labels can contain leading underscores, but nowhere else.
As David Tonhofer wrote, labels are the in-between-the-periods parts and should follow the LDH rule except when specifying service labels and port labels to differentiate them from regular labels. Then they must occur at the beginning of the label which should be the "Short Names" from the Service Name and Port Number Registry, the port number with no leading 0s, or the protocol (ie. tcp, udp). These service labels are further limited to 15 characters.
Contrary to David Tonhofer's answer, IDN does not allows for encoding underscore ('_' U+005F LOW LINE) or any other invalid ASCII character.
From RFC5890
[..] two new subsets of LDH labels are created by the introduction of IDNA. These are called Reserved LDH labels (R-LDH labels) and Non-Reserved LDH labels (NR-LDH labels). Reserved LDH labels, known as "tagged domain names" in some other contexts, have the property that they contain "--" in the third and fourth characters but which otherwise conform to LDH label rules.
Punycode encodes all ASCII codepoints as ASCII directly, including underscore. The resulting R-LDH would not conform the the LDH label rules. For example, S_.com would be encoded as xn--_-zmb.com which violates the rules. There may be a homographic codepoint which looks like an underscore that can be coded legally (perhaps '_' U+FF3F fullwidth low line), but these kinds of codepoints would be categorized as DISALLOWED by RFC5892 under 2.3 IgnorableProperties as a Noncharacter_Code_Point.
RACE (the other proposed IDN encoding scheme) was not accepted as a standard by IETF and should not be used.
Individual TLD's can place their own rules & restrictions on domains names as they see fit, such as to accomodate local languages.
For example, according to the CIRA, Canada's .ca domain names are allowed:
Letters
athroughz, and the following accented characters:é ë ê è â à æ ô œ ù û ü ç î ï ÿ. Note that Domain Names are not case sensitive. This means there will be no distinction made between upper case letters and lower case letters (A=a);The numbers
0123456789, andThe hyphen character ("
-) (although it cannot be used to start or end a Domain Name).
The maximum length is 63 characters, except each accented character reduces that limit by 4 characters.
(Source)
Incidentally, this allows for around 4 Quadragintillion domain name possibilities (not counting sub-domains) for dot-ca domains.
One should be clear about definitions. As used here:
The hostname is subject to the restrictions of RFC 952 and the slight relaxation of RFC 1123
RFC 2181 makes clear that there is a difference between a domain name and a hostname:
...[the fact 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...
So underscores in hostnames are a no-no, underscores in domain names are a-ok.
In practice, one may well see hostnames with underscores. As the Robustness Principle says: "Be conservative in what you send, liberal in what you accept".
In the 21st century, it turns out that hostnames as well as domain names may be internationalized! This means resorting to encodings in case of labels that contain characters that are outside the allowed set.
In particular, it allows one to encode the _ in hostnames (Update 2017-07: This is doubtful, see comments. The _ still cannot be used in hostnames. Indeed, it cannot even be used in internationalized labels.)
The first RFC for internationalization was RFC 3490 of March 2003, "Internationalizing Domain Names in Applications (IDNA)". Today, we have:
You may also want to check the Wikipedia Entry
RFC 5890 introduces the term LDH (Letter-Digit-Hypen) label for labels used in hostnames and says:
This is the classical label form used, albeit with some additional restrictions, in hostnames (RFC 952). Its syntax is identical to that described as the "preferred name syntax" in Section 3.5 of RFC 1034 as modified by RFC 1123. Briefly, it is a string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets.
Going back to simpler times, this Internet draft is an early proposal for hostname internationalization. Hostnames with international characters may be encoded using, for example, 'RACE' encoding.
The author of the 'RACE encoding' proposal notes:
According to RFC 1035, host parts must be case-insensitive, start and end with a letter or digit, and contain only letters, digits, and the hyphen character ("-"). This, of course, excludes any internationalized characters, as well as many other characters in the ASCII character repertoire. Further, domain name parts must be 63 octets or shorter in length.... All post-converted name parts that contain internationalized characters begin with the string "bq--". (...) The string "bq--" was chosen because it is extremely unlikely to exist in host parts before this specification was produced.
Just created local project (with vagrant) and it was working perfectly when accessed over ip address. Then I added some_name.test to hosts file and tried accessing it that way, but I was getting "bad request - 400" all the time. Wasted hours until I figured out that just changing domain name to some-name.test solves the problem. So at least locally on Mac OS it's not working.
No, you can't use underscore in subdomain but hypen (dash). i.e my-subdomain.agahost.com is acceptable and my_subdomain.agahost.com would not be acceptable.
Not if you want it to resolve on the Internet.
You cannot have: http://my_subdomain.example.com is invalid.
You can have: http://my-subdomain.example.com with a hyphen.
Source: Stackoverflow.com