8

developer here... I'd like your IT perspective on this one...

I'm building a new internal web app for my company, and starting to think about how it will be deployed. Many of the existing web apps here are linked-to using their server names directly, like this:

http://webserver123/someInternalApp/

This makes me uncomfortable for a variety of reasons. Server names change, servers go down, and users shouldn't have to know server names to find their web application. Using server names prevents us from swapping servers or adding load balancers. If you can think of other reasons this is bad, let me know so I can make a better case for changing this practice.

Going forward, I'd like to have some better domain names set up in our internal DNS that will point back to the appropriate web server & app. In my last job, we followed a convention something like this:

  • For Production: http://someInternalApp.myCompany.com/
  • For Test: http://test.someInternalApp.myCompany.com/
  • For Development: http://dev.someInternalApp.myCompany.com/

I like this better, as the application name is a key part of the domain name, and the dev/test/prod environment designation is simple. However, I have some reservations:

  • Putting the app name in the subdomain will eventually create a lot of long, unique subdomains. I like having different domains for each app, but I also feel it could get difficult to manage.
  • Other than the app name, there is nothing to designate that this URL is internal only. I've read about other organizations using a subdomain like "corp.myCompany.com" or "int.myCompany.com" which could be good. I don't want users to get the impression they can access these from home.

Here are some options on what I'm leaning toward for internal domain names:

App name in the internal subdomain: (they get a bit long, but everything is packaged together well I think)

  • http://someInternalApp.corp.myCompany.com/
  • http://dev.someInternalApp.corp.myCompany.com/

App name as a subdirectory: (shorter domain name, but it implies all the apps are part of one unified site, which they may not be, and it disconnects the environment designation from the app)

  • http://corp.myCompany.com/someInternalApp
  • http://dev.corp.myCompany.com/someInternalApp

So, let's discuss... What do think about these options? Is there something better or more common I may have missed? I have the opportunity to set my company on a better path in this regard, so I'd like to find a good convention to recommend.

Thanks!

3
  • DNS tricks, URL rewriting and virtual hosting are your friends here. Will this be on a Microsoft stack or Linux? – ewwhite Sep 11 '14 at 14:14
  • Microsoft... .Net web apps running on IIS in Windows – Ben Brandt Sep 11 '14 at 14:16
  • naming things is a hard problem in computer science. Expect any scheme (especially with auto-incremented numbers) to fail at some point. Redirects and DNS are the way to go to ambiguate specific names. – tedder42 Sep 17 '14 at 19:20
7

Never rely on whether your app will be internal or external. Always develop as though the audience of the app will be outside your control (because it is).

Go with ENV.APPNAME.DOMAIN.TLD

With www. as the alias for "production".

1
  • Simple and solid approach, I like it. All the more relevant these days with browsers like Chrome that sync your bookmarks & history. If I bookmark an internal workplace app in Chrome, that bookmark gets sync'ed to my home PC and my android device. Once the bookmark gets there, it had better not point to something else on the internet. – Ben Brandt Sep 12 '14 at 15:37
3

If you are deploying internal only, you have great freedom in selection. However with the Top Level Domains opening up as they have recently, you do want to take some care to not conflict with an upcoming new external name.

eg, you could deploy as http://contact.app/ but if the .app TLD gets registered then you could find yourself conflicting.

So you are probably best using something like http://contact.local/ or http://contact.lan/

For reasons of Apple and their Bonjour service compatibility you are best to avoid .local so perhaps go with .lan

Alternatively just http://contact.ourcompany/ would work pretty good if your company name is highly unlikely to ever become a TLD.

I would avoid the app name as a subdirectory because it is unnecessary and just makes it longer. Virtual hosting is the way to go there with a unique URL per app.

And you are quite correct in avoiding server names, that is a definite no-no because servers come and go.

Edit 1: See RFC2606 and take your pick from the available internal use TLD's referenced there.

Just as a note to the comments - .local and .lan as I recommend are not registerable as per the above RFC. You could use .priv and .test as well for the same reasons.

3
  • 5
    The only DNS namespace you can practically be assured control of, on the Internet, is subdomains of a second-level domain you own. Any idiot with money can get a TLD created today, so using any kind of custom TLD inside a network seems like a bad idea to me. I'd go with subdomains of my own company's name and live with the fact that the URLs will be longer. – Evan Anderson Sep 11 '14 at 15:19
  • @EvanAnderson I propose a KickStarter to raise $185k for the application fee to register the .local gTLD and establish a permanent lesson on how to properly configure your environments. – Sammitch Sep 11 '14 at 21:10
  • It is no longer recommended to use a TLD that you don't own, or to use DNS search spaces. See ICANN Name Collision information. – Michael Hampton Sep 12 '14 at 7:10
1

This somehwat opinion based because when you only deploy your application internally you have full control and than it really doesn't matter what you do...

Most users will bookmark what internal web applications they need to use anyway, so don't fret too much about their URL's.

As the sysadmin I would love more applications that give me the choice to deploy either in a configurable subdirectory or the root on a subdomain, allowing the choice of using subdomains or not.

It takes a more considerate developer not to go the "easy" route and just include a hardcoded (relative) reference "href=/images/bullet.png" on a random page and instead of building a reference from a number of deployment/configuration settings "href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Please make your deployment choices such as any hostnames, port numbers, choices in HTTP/HTTPS configuration settings and do not hardcode them.

I have often been on the receiving end "management wants all internal apps under http://intranet/apps/ because appname.intranet is soo confusing. And the opposite from our vendors; we need appname.intranet for our appliance/application as we have built-in check against iframes, inlining man-in-the-middle-attacks and reverse proxying....

I've found that a lot of commercial web applications expect to be deployed in the root of the webserver and don't work too reliably when deployed in some random subdirectory. I.e. they include, for instance, more or less hard-coded paths to /css/main.css sub-directories, making it difficult to host multiple applications on the same host. But those lot do not appear overly worried about the portability of their code either.

2
  • Installing multiple apps that all have a root install requirement onto the same server is trivially solved via virtual hosting with a separate DNS name for each app. – Ian Macintosh Sep 12 '14 at 9:03
  • For the layman (my then manager and CTO) that still makes for multiple servers (albeit not actual boxes) in the sense that they don't appear as intranet/apps/inventory and intranet/apps/billing. – HBruijn Sep 12 '14 at 11:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.