[cisco-voip] DNS Friendly Names and URL Paths

Anthony Holloway avholloway+cisco-voip at gmail.com
Thu Oct 20 15:06:32 EDT 2016


Since the list is slow this week....

Ever since the push for DNS and FQDN over IP Address, I have been giving
application servers a Subject Alternative Name (SAN) so that users
accessing Self-Care Portal, Finesse, etc. do not have to be bothered with
server names.

E.g.,
Instead of this:

https://mspvmcucm001.company.com/ucmuser


They would be able to use this:

https://myphone.company.com/ucmuser


That works pretty well, and Tomcat certs are easily signed to support the
extra alias.

However, when it comes to UCCX, it's a little more complicated with the
following example:

https://finesse.company.com:8445/desktop


Because the alias is not exactly fitting for all things on UCCX, such as:

https://finesse.company.com:8444/cuic


That's confusing, and also because the user still has to remember the port
and path on the end.

https://finesse.company.com will not automatically take you to
https://finesse.company.com:8445/desktop


Today I had a co-worker ask me how it might be possible to have both:

A) A different alias for each sub-component of the application server
(E.g., Finesse vs CUIC)

B) Have the port and path appended automatically


I decided that a shim would be appropriate here.  We would take the various
aliases, send them to a web server, which would then initiate an HTTP
Header Location redirect to the appropriate port and path.

A PHP example could be:

URL: https://agent.company.com/

PHP: <?php header('Location: https://mspvmuccx001.company.com:8445/desktop'');
exit; ?>


This uses the HTTP Location <https://en.wikipedia.org/wiki/HTTP_location>
header, which sends an HTTP 3XX response code to the client and let's them
know where to go to get the "right" page.  Unfortunately, that does mean
that the address changes in your browser from the first URL to the second
URL.  This isn't terrible, but it does mean that you'll still want a
friendly looking CNAME record for your host still, as I described above.

But, this would require me to install a web server in each environment and
configure it, or ask for shared web server space.  A better solution?  The
cloud!

I stumbled across a public service that does just this.  The cloud service
I found is:

https://www.easyredir.com/


They have both paid and a free plans:

https://www.easyredir.com/free-url-redirection


I was able to set this up in about 10 minutes and it works exactly like I
have explained above.  I have no affiliation to them, and I'm sure there's
other services out there.

Icing on the cake I suppose, I was even able to take a public domain record
(E.g., company.com) and redirect it to a private domain record (E.g.,
company.local), proving that your application servers need not be
accessible from the internet.

In fact, your target url doesn't even have to be a public domain either.

E.g.,
https://agent.company.local can point to
https://mspvmuccx001.company.local:8445/desktop


The only requirement is that your client PC can resolve the private record
(.local) to the public service host (on easyredir.com), and that the
returned redirect location (.local again) is also accessible to your client
PC.

Has anyone come across something like this before?  How are you solving all
the different ports and paths now under your administrative domain?

This does not replace your need for a smart load-balancer in the case of a
server failure, though Finesse should at least redirect you to the Master
node, should your DNS record point to the Slave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161020/d8f3eed3/attachment.html>


More information about the cisco-voip mailing list