

A Proper Server Naming Scheme - merickson
http://www.mnxsolutions.com/devops/a-proper-server-naming-scheme.html

======
jlgaddis
The U.N.'s "Code for Trade and Transport Locations" [0] was new to me and its
use makes sense in some cases. I was also quite surprised to see on the list
two _very small_ towns where I have facilities.

For those who have no gear outside of the U.S., however, CLLI codes [1],
common in the telco industry, might be a better fit. Some of the codes on the
U.N. list aren't very "intuitive" and the CLLI codes (the six-character
"Network Site Codes", specifically) make a bit more sense. The U.N. code for
Albin, Wyoming, for example, is "US AQI" while the (geographical portion of
the) CLLI code is ALBNWY.

Side note: As seen below, you'll often see CLLI codes in PTR RRs when running
traceroutes across the Internet. This can sometimes help when troubleshooting
networking issues ("LSANCA" refers to Los Angeles, California).

    
    
        $ traceroute route-server.ip.att.net
        traceroute to route-server.ip.att.net (12.0.1.28), 30 hops max, 60 byte packets
    
        ... snip ...
    
         3  ge-0-7-0-24.r04.lsanca03.us.bb.gin.ntt.net (129.250.198.185)  0.691 ms  1.393 ms  1.098 ms
    

[0]:
[http://www.unece.org/cefact/locode/service/location.html](http://www.unece.org/cefact/locode/service/location.html)

[1]:
[https://en.wikipedia.org/wiki/CLLI_code](https://en.wikipedia.org/wiki/CLLI_code)

~~~
elasticdog
Author here...I hadn't heard of the CLLI codes before, but that's a nice
reference, thanks! I do tend to prefer the UN/LOCODE values just because you
can almost always get away with using just three letters to define a location,
and they work well internationally. I do agree that they're not always the
most intuitive though, so that's certainly a trade-off.

------
jlgaddis
One important thing to keep in mind for those who run their own mail systems
is that you'll want the A and PTR RRs to match up or you increase the chances
of your messages being considered spam.

In addition, you'll want the name used by your users (e.g. "mail.example.com")
to match what's on your certificate or (at least some) mail clients will throw
up errors (just as browsers do).

Multiple mail servers used by different users? nginx can proxy POP3, IMAP, and
SMTP as well, so everyone can use "mail.example.com" and get routed to the
correct backend server.

~~~
elasticdog
I did add a quick section under "special cases" on making sure to assign
usable A records for mail servers and name servers, but you make a good point
about ensuring the reverse matches in those scenarios as well (and to pay
attention to your certificates).

