Are Co-Branded Domain Names Causing an Issue for Trust and Security in the Cloud?

David Quaid
by David Quaid 14 Jul, 2014

With the growth of SaaS services, more and more Web applications and technologies are no longer being deployed as plug-ins or COM components that the Internet was built on, but more and more through API and hosted services. This model is a lot safer and the burden of buying into tools is greatly reduced thanks to both the business model (software rental) and scalability.

For example, almost every Web agency uses the Google's Analytics tool to measure Web statistics. There's almost no reason to have a proprietary in-house solution. Google Analytics is free, constantly evolving and automatically integrated into Google's other features. You could trace data back to 2004 or 2003 if you've been using it that long. Given that the average small to medium business website fits in a 50mb of hosting space or less, most businesses have never even considered the cost of storing that kind of data. 

 

Phishing fraudsters frequently use branded-terms inside other generic domains that cause millions of dollars in damages every year. Big brands are highly susceptible because people see the brand name inside another URL - sometimes as a page name, but mostly as a sub-domain. 

 

Businesses are getting more and more used to letting technology providers worry about scaling up. Nobody bats an eyelid when considering SaaS for a newsletter service, online surveys, event bookings, appointment setting or creating landing pages. With so many companies finding new niches by coming up with SaaS solutions such as these, a new challenge presents itself, especially for SEO's. This challenge is the break-up of domains.

 

THE BREAKUP OF DOMAINS

 

Not too long ago, domain name choices were highly limited. The .COM still remains the top top level domain (TLD) of choice. Businesses and individuals can spend upward of a million dollars to acquire highly desirable domain names. Even as the TLD group has expanded into 1,000s of TLD extensions, we still love our .COMs. With hosted SaaS products, a new problem of integrating these services on the same domain name has been a small but noticeable problem.

 

Ideally, you'd like to host your email newsletter sender on your own domain, but the email sender needs to build in a whole lot of image tracking and delivery technology that they can't share with you. So your emails are sent from mydomain.mynewslettercompany.com. You'd love to integrate your new landing page builder on your expensive myshortbranddomain.com, but it's not on a sub-domain at the vendor's hosting company. It's a small price to pay, but a growing cause for concern. The real question is this: Is running your brand as a sub-domain on somebody else's bad for business?

 

There are other pressing issues, too. For example, the sometimes fanatical question of which CMS to use for your site might then affect your blogging platform. Many Web designers might have the same answer for both, but what happens when you have to use a platform related to your ERP systems and you don't have a choice? You might want to run Microsoft Dynamics for ecommerce as your shop front because it integrates nicely with your Dynamics back office, but your SEO and content marketing team may be left crying for WordPress. Or, what if you're hosting on Amazon but need to use OWA from Office365? That's where load balancing and Application Delivery Controllers come in. 

 

HOW LOAD BALANCERS AND ADCs CAN HELP

 

By setting your DNS to the load balancer, you can move all of your Web applications up a gear or two. First, a load balancer will give you extra security enhancements, like helping to prevent DoS attacks. A load balancer also provides Layer 7 content switching and URL re-writing. Your blog can be on a different server or in a different hosting company. Hackers won't know the hosting company IP addresses. Google will just see the IP of the server, so your email repository, blog, online store and other apps can all be on the same .com.

 

But there's more. With a load balancer, you might choose to host a U.S. site in the U.S. and a UK version in the UK, thus reducing latency. When your logistics provider gives you a third-party track and trace sub-domain, you can wrap it with an on-domain URL and you wont even need to edit your HTAccess file. The GEO facility built-in to your load balancer will automatically work out which site to show content from - saving you precious seconds in load-up time, reducing workload, processing time and avoiding penalties from Google, who frowns on page load times.

 

You can also take advantage of multi-factor authentication, SSH, Single-Sign-On, SSL off-loading, ASIC cache compression and content switching. So, if your hosting company in Texas goes down, your load balancer will automatically switch users to your NY or CA hosting. 

 

Stop Accepting Limitations

 

Much of the way the Internet is designed was based on the very simple beginnings of the ARPAnet as a DARPA project. As such, the ability for scalability and high availability wasn't initially considered. The proof of concept quickly became the Internet we have today. This is why we have many of the limitations we face today in how websites are hosted. Many companies can't customize their hosting environment because of the cost of all the services needed to keep a Web presence online and available. As such, we have started to accept those limitations. Clearly there is a case for evangelizing the layer-7 features of a load balancer as part of an overall solution.