Author: Clint Language: text
Description: Domain names Timestamp: 2015-05-01 02:49:21 -0400
View raw paste Reply
  1. I own several misspelled domains that I would like to properly resolve/redirect to my "good" domain that uses a public key certificate for all connections.
  3. What I have been doing for years is simply creating A records for each misspelled root domain and common subdomains (i.e. www) and pointing them to the IP address of the server hosting the good domain. Then Nginx 301s the connections to the good domain on port 443. Also, I only have an SSL cert for my good domain.
  5. But I thought of a potential problem today as I was renewing my domains and double checking my DNS and Nginx configurations. My good site is **only** served on port 443. Plus an HSTS header with a one year expiration is sent for every connection. So, if someone types in a misspelled domain, which by default will be to port 80, would their browser issue a security warning and prevent them from being redirected to my good domain on a secured connection?
  7. One potential solution I thought of is to use CNAME records instead, but I vaguely remember Allan mentioning why it is bad to use a CNAME for your root domain. Does that apply to me in this case? I don't use these misspelled domains for any other reason.
  9. What's the best way to redirect connections from all these unsecured misspelled domains to my secured good domain while avoid the big scary security warnings that browsers may issue?
  11. If I set up a CNAME to my good domain for a subdomain of my misspelled root, it does not change the domain name in the browser. I thought it might, but I can see how this would be a security issue.
  13. For example, the zone file for misspelled domain would read:
  15.  ; zone for
  16.  www        IN      CNAME
  18. Remember, in my case only allows secure connections on port 443. So when I manually entered in the Chrome browser, I got the following warning:
  20.  [initial warning]
  22.  Your connection is not private
  23.  Attackers might be trying to steal your
  24.  information from (for
  25.  example, passwords, messages, or credit cards).
  28.  [after clicking Advanced]
  30.  This server could not prove that it is
  31.; its security certificate is
  32.  from This may be caused by a
  33.  misconfiguration or an attacker intercepting
  34.  your connection.
  37. If I proceed, my Nginx server 301 redirects to my secure domain at and I get a valid secure connection.
  39. So with my current configuration, it seems there is only a problem if someone manually enters the secure protocol, "https://", before the misspelled domains or subdomains. This most likely won't happen unless HTTPS becomes the default protocol some day. If that's the case, then public key certs would be required for all domains in play, right?
  41. Otherwise, all of my A RRs on my misspelled domains and subdomains pointing to the IP address of my good domain with 301 redirects seem to work. Setting CNAME RRs for the "www" subdomains also seems harmless. If you have any reason to use A vs CNAME for these subdomains, that would be helpful.
  43. Also, according to the RFC, setting a CNAME for the root (@) isn't technically possible because no other records can exist for that node if a CNAME exists. The caveat is, SOA and NS records must be defined for root, thus no CNAME can.
View raw paste Reply