Forward the root domain to the www subdomain using DNS records
Unfortunately, this is a well-known shortcoming of the DNS protocol. There is no record type defined within the DNS standards that will allow you to alias the apex of a domain. Many people assume that CNAME
records can be used to accomplish this but there are technical reasons why they cannot.
Many DNS providers implement custom (read: fake) DNS record types to try and address this shortcoming. Behind the scenes, these fake records implement custom behavior in that company's software using a combination of synthesized A
records and webserver redirection to accomplish your desired goal. FWD
is one of these, much like the WebForward
that Michael directed you to in the comments.
Summary: In short, you can't have the record you want, and your DNS host is doing things The Right Way.
Explanation: It is a violation of the DNS standadards to have a CNAME (alias record / forward record) at zone apex (the empty name at the front of the zone).
The reason for this is a CNAME record cannot have the name portion conflict with any record except a DNSSec record. In a typical zone, a CNAME record at zone apex would collide with at least the SOA and NS records (and likely several others). While some DNS servers will allow this, it is a Bad Thing, and can cause hard to diagnose failures (not to mention will not work if you move hosting of the zone to a standards-compliant DNS server, such as anything BIND-based).
Either have A records at zone apex (they can be a simple web server that just throws an HTTP 302 to www). If you can get static IP numbers for your Azure server instances, put an A record for each at the apex of your zone, and create a single CNAME record called "www" that points to the apex record.
As an example :
$ORIGIN example.com. @ IN SOA ns1.example.com. [email protected]. ( 101 ; 172800 ; 900 ; 1209600 ; 3600 ; ) @ IN NS ns1.example.com. @ IN NS ns2.example.com. @ IN A 123.234.1.123 @ IN A 123.234.1.124 @ IN A 123.234.1.125 ns1 IN A 123.234.1.126 ns2 IN A 123.234.1.127 www IN CNAME example.com.
Some protocols have standards for DNS record types, other than A records, for finding the service. SMTP with it's associated MX records is a good example of this. There are no defined DNS record types for HTTP. It's likely that your prior DNS/registrar provider had either an HTTP redirect or reverse proxy service.
In order to accomplish your goal you'll need to setup a webserver (virtual host) to do an HTTP 301 or 302 redirect from one hostname to the other, setup a reverse HTTP proxy, setup independent virtual hosts, or use virtual host aliases so the same webserver instance will respond to both A names.