Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm working at a company which primarily provides SaaS products but also will host some of our customers corporate websites. My question relates to recommendations for managing DNS for client's domain names. My objectives:

  1. Not restrict my ability to change the server's IP address such as might happen when I move my servers to a new host. Specifically, I do not want to be required to contact the customer to change their domain's DNS if I need to change the server's IP address. Often times, customers lose this information or have to track down the one person with any knowledge of the domain settings.
  2. Map both .clientdomain.com and www.clientdomain.com to the proper IIS site.

However, I'm running into some common problems:

  1. Sometimes, the DNS console provided by the client's hosting company does not allow for CNAME records.
  2. Sometimes, the DNS console provided by the client's hosting company will not let me create a CNAME entry for .spiffydomain.com because the given hosting company has created a SOA record for that entry or simply requires that .spiffydomain.com be an A record.

I believe one solution to #2 is to use a wildcard for a CNAME entry (i.e. *.spiffydomain.com). Is that correct?

How do other folks that are hosting many customer's site manage change of DNS entries on their servers?

Addition

An additional constraint is that many customers are adverse to having their DNS hosted by someone other than themselves. It might be a security issue or a control issue but regardless we are often unable to convince them to change control of DNS to us. One solution of course is to simply mandate that we must control DNS in order to host their site but it is unlikely that our salespeople have the fortitude to make that mandate if it meant potentially losing the business. From a salesperson's perspective, the inconvenience of managing DNS only causes IT problems, not them.

share|improve this question
add comment

3 Answers

up vote 1 down vote accepted

Sounds like you're mixing oil and water with your DNS requirements: for the clients who's corporate sites you plan on hosting for them, there's really not much you can do unless you manage their DNS for them; this is how the commodity hosting providers of the world work because static IPs are a valuable asset to them and when you use your own nameservers, you need a static IP for your A records, and the whole cheap hosting thing stops working for them and for you.

As for SaaS, why not do what Google Apps does? Require your customers to create a CNAME record to your.app.com (like Google does with ghs.google.com). That way, you can change the A record of your.app.com whenever you want and their CNAME stays the same.

share|improve this answer
    
RE: Saas - The primary reason I mentioned it is that hosting one-off corporate sites isn't our main business. We control the DNS for our SaaS applications so they are not an issue. The issue is the corporate sites and having to move servers when I have dozens of customers with A records pointing to one of our public IPs. –  Thomas Feb 4 '11 at 17:27
    
You can keep beating on this dead horse, but unless you control the DNS for the corporate sites, there's not much you can do besides having an agreed upon change management process in place that'll allow you to communicate and implement IP changes effectively. Personally, I'd tell them to host their own sites; you're in the SaaS business and commodity hosting is cheap and done well elsewhere. –  gravyface Feb 4 '11 at 18:34
    
Yeah, it would appear there is no clean solution whereby I can give a pointer to the client instead of a IP and have both the root and the www subdomain mapped properly in all cases. Sigh. –  Thomas Feb 4 '11 at 19:20
add comment

The solution to (2) is not a wildcard CNAME for *.example.com because that won't match example.com.

example.com must have SOA and NS records and it is impossible to have a CNAME with other record types.

Your requirements are impossible to meet so you'll have to give up on one of them.

share|improve this answer
    
Arg. Ok. So how do hosting providers handle mapping of the root domain to a website: just accept that they have to use an A record? –  Thomas Feb 4 '11 at 3:11
    
Yes, and that is why they want to manage your DNS as well as Christopher Evans said. Otherwise, what hosting providers do is notify their customers when they need to change their A records. –  Mark Wagner Feb 4 '11 at 17:23
add comment

We do hosting, and we include managing DNS as part of the service. If you start running DNS yourself, you'll be able to change whatever settings you want.

This won't work in a few cases:

  • They have their own dns server locally in the office using that domain. For running active directory, or to override specific dns entries, such as the mail server.
  • They have the domain at places like godaddy, and use godaddy for email too. Changing the whois to you invalidates their use of godaddy's email service.
share|improve this answer
    
Unfortunately, the common scenario is that customer is hosting their own DNS at GoDaddy, NSI or whatever. Among their entries will be MX records and the like. Thus, the customers are adverse to having their DNS migrated to a different DNS host control by us and therein lies the problem. –  Thomas Feb 4 '11 at 2:19
    
Depending on their use of spiffydomain.com, you may be able to have them set it to a shared server, that has redirects to www.spiffydomain.com. Then try to use a CNAME for www.spiffydomain.com to spiffydomain.com.yourdomain.com ( or something else ). You will then be allowed to tweak where the site is hosted. –  becomingwisest Feb 4 '11 at 2:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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