Some DNS hosts offer a way to have an A record that serves an IP address which is determined on-the-fly (or frequently enough via scheduled job) by resolving some other hostname behind the scenes. This is used when example.com (and not a subdomain like www.example.com) MUST point to a host whose IP address changes from time to time, without requiring human intervention every time it changes. The result is that resolving example.com produces an A record, where that A record's IP address is determined by the nameserver dynamically by looking up the IP address of another.example.com which itself could be a CNAME.
DNS Made Easy and easyDNS call it an "ANAME record", Route 53 calls it an "alias resource record", CloudFlare calls it "CNAME Flattening", DNSimple calls it an "ALIAS record". Regardless of what they call it, a standard A record is returned when resolving the hostname.
I haven't come across a publication on how one might implement this, although it's a fairly obvious concept. I intend to replicate this behavior in my nameserver, which is the DNS Manager in Windows Server 2012 R2. Does a plugin for DNS Manager exist for doing this?
EDIT: To avoid the XY problem I'm going to provide full background, starting with The Problem in terms of symptoms, and traversing back through the dependencies since they are an indication of what solutions have and haven't been tried.
Symptoms
SSL/TLS connections to the apex domain (example.com) generate a certificate mismatch. Such connections are not attempted very often, but increasingly so, due to things such as automatic host detection by email clients. For example, we just put in Exchange as our client-facing mail server, and when adding user@example.com as an Exchange account in Android or Mac Mail, the auto host discovery apparently derives "typical" hostnames such as example.com, mail.example.com, exchange.example.com, etc., and gives the user a Big Scary Warning that the CN on the certificate at example.com is not example.com. We actually use exchange.example.com which has a matching cert, but the auto detection must be trying example.com first.
The mismatch warning also occurs when a web browser is pointed to https://example.com, but this is mitigated by the fact that most people type example.com into their address bar, not prefixed with https://, so they end up being upgraded to https://www.example.com with a redirect when necessary. Since www.example.com has a CNAME, so it is able to point to a host where there is no CN mismatch.
Why is there only a matching cert at www.example.com and not example.com?
The server with our matching cert (which, by the way, can easily have SAN entries to match both example.com and *.example.com, no trouble there) is located on an AWS ELB (elastic load balancer) for which Amazon warns that the IP address may change at any time. Due to the dynamic IP address, the ELB is only to be referred to via its hostname, which means a CNAME/ANAME/Flattening/etc. That's why we are able to point www.example.com to the ELB, but not example.com. Amazon suggests using Route 53 to overcome any limitations. When that is not possible, the only solution is to have example.com's A record point not to the ELB, but instead to the upstream server to which normally the ELB reverse proxies.
Why not put the matching cert on that upstream server?
Only the ELB itself is dedicated to me, so only the ELB can have my wildcard cert installed. The upstream server is shared among the hosting provider's clientele. I could have the hosting company add example.com to their laundry list of SANs on their certificate and there wouldn't be a mismatch, but instead I am interested in making full use of the ELB for various reasons.
We are fixed on running DNS in-house on Win2012R2, while all WWW hosts must be on AWS for resiliency.
Answer
Given the exact circumstances of the problem, I would say that the ideal solution would be to point the apex at a webserver that redirects HTTP requests for example.com to www.example.com. www.example.com can in turn be a CNAME to the DNS record managed by AWS.
- While it would be possible to set up a solution on your servers that automatically updates the apex A record to "chase" AWS, this introduces a great deal of unnecessary complexity and creates additional dependencies on your internal infrastructure for things to work as expected. I would try my hardest to avoid this.
- Running this webserver yourself would obviously introduce its own set of challenges and dependencies, so it would be natural to turn your attention outward. An example of a commercial service that solves your problem (https inclusive) would be wwwizer.com. Note that I am not linking to their free, non-SSL product.
- A compromise between simplicity and availability would be to set up a simple webserver in the cloud that you yourself run which performs this redirection. You're still stuck with running the webserver, but at least there are no dependencies on your company's local infrastructure and you have a SLA for its availability.
At the end of the day, you have to ask yourself how important it is that your apex record is always functioning properly. In your situation, it should only be a safeguard for users who key in that record by hand. Make sure your servers and applications are configured with this in mind and the risk should be greatly mitigated. It should also be noted in your design docs (if applicable) to ensure that things remain that way.
No comments:
Post a Comment