Fix VRMS redirect link without subdomain

[trillium]

Overview

When a user types "https://vrms.io" or "http://vrms.io/" the browser doesn't connect to the website (i.e., if user is missing "www").

Action Items

• Follow instructions in the devops contributing guide & create a feature branch from main
• Add resource for A record configuration as shown here
• partner w/ Chelsey to manually delete the previous A record in AWS

See potential recommended steps below from ChatGPT

The potential problem you're describing is related to DNS (Domain Name System) configuration. `[www.example.com](http://www.example.com/)` and `[example.com](http://example.com/)` are technically different domains from a DNS perspective. When `https://www.example.com/` works but `https://example.com/` doesn't, it usually means that the DNS records for `[example.com](http://example.com/)` (often referred to as the "root domain" or "naked domain") are not correctly set up.

Here are a few things you could check:

1. Check your DNS records: Ensure that you have an A record or CNAME record set up for [example.com](http://example.com/). If you're using an A record, it should point to the IP address of your server. If you're using a CNAME record, it should point to the correct domain (but note that CNAME records are not allowed on root domains according to the DNS specification, although some DNS providers allow this as an extension).

2. Check your web server configuration: Your web server (e.g., Nginx, Apache) needs to be configured to respond to requests for both [www.example.com](http://www.example.com/) and [example.com](http://example.com/). This might involve setting up server blocks (in Nginx) or virtual hosts (in Apache) for both domains.

Screenshots

"https://vrms.io"

"http://vrms.io"

Desired Behavior

Navigating to http://vrms.io or https://vrms.io will redirect to: https://www.vrms.io

Resources/Instructions

In order to do this we will need access to the AWS DNS.

[tylerthome]

Analysis

---

The current hosted zone in Route 53 for vrms.io is configured to route traffic differently:

www.vrms.io resolves to the IPv4 address of the incubator-prod load balancer configured in ECS

vrms.io has multiple records which is likely causing the behavior:

• an A record which points to the two IPv4 addresses for the same load balancer endpoint as the www subdomain (highlighted in green)

• an AAAA record which points to a set of four IPv6 addresses that were unfamiliar (highlighted in red);

(these are apparently registered hosts of a subdomain of 1e100.net:)

---

This means clients, like browsers, will hit this other location if they default to using IPv6. Confirmed this locally with curl - notice that using IPv4 returns a 'minified' html/js bundle (i.e. the VRMS app) which is what we want, whereas using IPv6 fails to connect at all:

(SSL handshake happens to be where curl breaks, but that's because there is no HTTP application serving at that host at all)

---

Recommended solution

1. Remove the AAAA record in AWS. Since our load balancer doesn't provide an IPv6 address, there is no need to replace it with a new record.

2. Update the existing A record to point to the same hostname that the www subdomain points to, i.e. incubator-prod-lb-569274394.us-west-2.elb.amazonaws.com (or prepend the dualstack subdomain, which is what currently works via IPv4). This can be done one of two ways:

3. Add the resource to the incubator terraform configuration. This will look similar to the existing CNAME resource for the www subdomain, with the following distinctions:
   * the record must be of type A (as root-level hostnames like vrms.io cannot have CNAME records)

   • it must declare an alias block (since A records are assumed to point directly to IPv4 addresses, but in incubator terraforms we are supplied with only a hostname). A good example in the terraform docs is here: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/route53_record#alias-record

4. Make the resource terraform-managed. Easiest way to do this is just delete the existing A record in AWS and let the terraform recreate it. Alternatively, you can run a terraform import command to import the existing resource into the state, then terraform will destroy it on its own.

Let me know if I can follow up on any of these, happy to help advise where I can!