2

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 [email protected] 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.

Constraint

We are fixed on running DNS in-house on Win2012R2, while all WWW hosts must be on AWS for resiliency.

Improve this question
5
  • 1
    I'm marking your question as "primarily opinion based", because this is going to end up being a custom solution that your company has to implement. Open ended questions of how to get from A to B don't lend themselves well to the Serverfault format, which presumes that there should be a correct answer that is not rooted in personal opinion or implementation. If you have difficulty implementing this and want to come back to us with a specific challenge you've faced, that's fine -- just explain what you've done so far and the attempted solutions which didn't work.
    – Andrew B
    Nov 20, 2014 at 22:11
  • @AndrewB Thanks for the reply. As you can see I'm rather new here, but I readily admit I've seen that argument while lurking and I do agree with it. To ensure there can be a correct answer, I've edited the question such that it now strictly asks if a tool exists (binary), rather than how to build a tool (open ended). This is because the specific challenge I'm facing at this time is ensuring that I don't reinvent the wheel so I may determine for certain whether this requires custom implementation.
    – yeahforbes
    Nov 21, 2014 at 3:40
  • Sorry, I'm leading you in circles. My intent was to steer you toward doing some original research and providing us a list of solutions that you've ruled out already. This demonstrates effort on your part and makes it less of a free for all by reducing the number of potential solutions. (i.e. the correct one for your circumstance) Having too narrow of a focus on a hypothetical solution is a completely different problem. I'll provide an answer to your original question below. Thanks for being patient!
    – Andrew B
    Nov 21, 2014 at 5:22
  • The other way that DNS providers implement this is by having a client phone in whenever the target host's IP address changes. See e.g. ddclient or ipcheck.
    – Andrew Schulman
    Nov 21, 2014 at 10:24
  • @AndrewB No worries at all, and please trust that I do appreciate your guidance here. That XY problem you linked to made me realize that I really do need to tell the whole story, starting with my Actual Problem rather than whether it's feasible to implement X. I have revised my question to include how I got to this point, so any point along the way can be identified as the correct place to put in a solution.
    – yeahforbes
    Nov 22, 2014 at 0:19

3 Answers 3

Reset to default
1

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.

Improve this answer
2
  • Please note that I've edited this answer to take into consideration the difference between wwwizer.com's commercial product (SSL enabled) versus their free product.
    – Andrew B
    Dec 2, 2014 at 18:17
  • That definitely makes sense. We're not adverse to managing a WWW server so long as it has higher availability (like AWS) than our on-site facility with it's less than redundant network and mains power connections. Our apex domain needs to respond through such outages and also not throw certificate errors, and a tiny dedicated box in the cloud does sound better than "chasing" our elastic box.
    – yeahforbes
    Dec 4, 2014 at 3:53
0

Andrew's answer is absolutely the correct one; a small webserver for the sole purpose of pushing people onto WWW solves the web browser side of the problem nicely.

For mail auto discovery, have you investigated SRV records? Given that you're running Windows, I'll take a leap and guess that you're running Exchange. If so, Outlook will autoconfigure based on SRV, and will thereby forgo the certificate CN mismatch scenario.

Moving on to orthogonal options, using a better cloud would allow you to forgo this silliness altogether (because they know how to handle anycast fixed IPs), while using a higher-tier CDN comes with that ability built in. [N.b. I work for a cloud provider that offers HA services.]

Improve this answer
4
  • Using the autodiscover tester I see that it tries example.com:443/Autodiscover/Autodiscover.xml followed by autodiscover.example.com:443/Autodiscover/Autodiscover.xml -- we use the latter, which points to our in-house Exchange server, while the former has the cert mismatch (shared WWW). This unfortunate order is the source of frustration. Setting an SRV record will effectively make clients try autodiscover.example.com first?
    – yeahforbes
    Dec 4, 2014 at 3:34
  • It actually seems as though checking for an SRV record is further down in the order that a client will use, after trying the apex, autodiscover.example.com, and HTTP redirect method. It would be useful for those who use none of the above, such as foo.example.com, but all of the above still need to have valid certificates if they have any response at all.
    – yeahforbes
    Dec 4, 2014 at 4:13
  • Yes, SRV is lower in the list, but the selection logic is rather complicated; if Outlook doesn't like the answer it gets from an earlier stage, it'll try later ones, and then circle back to the original if it can't find a complete answer from those later stages. Certificate mismatches are an example of this, if I recall correctly; if it finds Autodiscover.xml but it has a cert mismatch, it'll keep going to see if it can find it without a cert mismatch, and if so, it'll present the latter.
    – BMDan
    Jan 13, 2015 at 15:14
  • I suppose that explains why we've had no issues with Outlook presenting a cert mismatch to the user, while certain versions of Android Mail and Mac Mail do present a cert mismatch (seemingly intermittently... haven't tested exhaustively). The latter must not be properly "skipping" example.com's mismatch and silently proceeding to exchange.example.com as expected. Plausible?
    – yeahforbes
    Jan 13, 2015 at 21:16
0

The best solution is to use Amazon Route 53 for DNS, then add an Aliased A record for the cloudfront address. It works great, we use it every day, and your DNS will be more "resilient" than running it on a box on your local network.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .