Feature Requests

CNAME intervals support

1. • CommentAuthoruare
   • CommentTimeNov 3rd 2011

    
   Hi there,
   As far as I can tell you don't have, nor plan on having support for custom CNAME DNS support. My question is why not. I've seen some answers in the forums, but I don't see the actual problem. Let me explain how I think it could work, and you tell me why it would be really hard/difficult.
   My example of how it could be done will be in PHP, but you could do it in whatever language you use.....
   
$calling_url = $_SERVER['SERVER_NAME'];
if(strpos($calling_url, ".timetask.com") === FALSE)
{
// might check a cache here otherwise:
$dns_records = dns_get_record($calling_url, DNS_CNAME);
if($dns_records !== FALSE && !empty($dns_records))
{
$dns_record = reset($dns_records);
if(isset($dns_record['target']) && !empty($dns_record['target'])
{
$calling_url = $dns_record['target'];
//might cache this value to skip constant lookups
}
}
}
// Do what you would normally do with $calling_url to determine the client id, etc.

   Not sure why that would be too hard, then there is 0 configuration except for a CNAME entry in the DNS table to the correct subdomain as you currently already have it.
   Thoughts?
2. •  
     CommentAuthorjreeve
   • CommentTimeNov 4th 2011

    
   Thanks for the code samples. You are absolutely correct that something like this would work. The issue isn't so much one of difficulty in developing the feature. It has more to do with time spent developing and supporting the feature. Here are some reasons why we are not pursuing this feature at this time:
   
   

   
   
   1. We have not had enough customers request this feature to allocate development time toward building this out.
   
   
   2. Supporting this type of feature can be difficult because most customers are not familiar with how DNS works. Our support staff would need to ramp up on DNS to support customers who like the idea of using this feature, but don't have the tech know-how to pull it off.
   
   
   3. DNS updates take a while to propagate. Combine that with caching lookups and an international customer base and it quickly becomes a support nightmare trying to figure out why it's not working in the hours after DNS is updated.
   
   
   4. Any change in DNS is going to cause problems while the change propagates, causing everyone using the account to have problems accessing the site.
   
   
   5. There are several contingencies that the code does not address. The code isn't at any fault here, it's just that for every feature added there are several more contingencies to address. While all of these contingencies do have solutions, my point is that each one requires more development work, testing, and support. Some examples:
      
      
      
      1. The code assumes that any URL that does not match timetask.com, projectaccount.com or intervalsonline.com is a CNAME record and does a dns lookup. This means false positives could increase web server processes that are waiting for a dns response. Yes, caching results would alleviate this, but could still leave us open to an unintentional DDOS attack. We could cache false positives to avoid repetitive lookups, but then what happens if one of those false positives becomes a legitimate URL?
      
      
      2. How long would we cache the results for? 24 hours, 48 hours, 7 days? What happens when the CNAME record is changed and the customer wants the results to appear immediately?
      
      
      3. What happens when the customer changes their Intervals domain, but not the CNAME record, while the CNAME lookup is still stored in cache?
      
      
      4. How do we handle multiple CNAME records per client?
      
      
      5. Do we need to provide settings in the Intervals app for customers to update CNAME settings to get around caching issues?
      
      
      6. Do we need to provide info showing Intervals customers which CNAME records are effectively resolving and which are not?
      
      
      
      
      
   
   

   
   Thanks, again, for submitting the code on how to pull this off. I think it's a great solution. I'm not trying to invalidate your efforts. My goal is to point out that each feature we add requires more than just a few lines of code. Each feature effects every level of the Intervals application, from the code that runs it, to the team that supports it.