Frequently Asked Questions

Externally Delegated DNS Configuration

Generally, GCom Internet does not support hosted sites with externally delegated DNS, unless those sites are controlled by authorised resellers. However, in all such cases, the following details set out the only acceptable methods of DNS zone record construction for domains with externally delegated DNS.

Under no circumstances should apex or other host records be hard coded by IP to point to one of our servers. We dynamically load balance down to the server level, and physically upgrade our hosting servers on a frequent basis. During such load balancing and upgrades, IPs assigned to individual sites and services will change. If a DNS zone outside of our control points to one of our servers directly by IP, the resolution for the client's site or service will fail whenever an IP is changed at the server level.

To work around this, we provide two dedicated host records on our cnames121.com domain for each externally delegated domain. We control these records internally to keep them in sync with the target server IPs at all times. As an example, for an externally delegated domain such as xyz.com.au, we would maintain records of the following form...

xyz-com-au-http.cnames121.com  A  123.123.123.123
xyz-com-au-smtp.cnames121.com  A  234.234.234.234

...where 123.123.123.123 is always set to the IP of the HTTP(S) and FTP/FTPES/SFTP services for the domain, and 234.234.234.234 is always set to the IP of the incoming SMTP and POP3/IMAP services for the domain.

Important

To maintain the connectivity of their hosted domains, clients should never redelegate their domains, either away from or towards our network, without first advising us of their plans.

Host records on our cnames121.com domain will not be created for any domain until/unless we receive email advice of an intention to delegate DNS externally. Such advice must be received directly from the recorded Administrative and Billing Contact of the hosting account.

Once the cnames121.com host records have been created at our end, all references of non apex host records in the client's externally delegated DNS zone should be made by CNAME to the appropriate record from above, and not by way of A records referencing the IP directly.

To remain RFC compliant, the apex record can only be handled with a CNAME approach if your DNS host is running modern DNS servers which support ANAME, ALIAS or other CNAME flattening solutions. A few DNS providers who support CNAME flattening are...

Unfortunately though, many DNS hosts still do not have this ability available within their DNS servers, so the apex often needs to be treated specially.

There are 4 methods to handle the apex for externally delegated domains...

  1. For modern DNS servers which internally provide CNAME flattening, the apex can be simply handled with an ANAME/ALIAS/CNAME flattened record in the same way as the www host record.

  2. For systems where the hostmaster has full control of their DNS servers, a frequent cron can be configured on the DNS servers to keep the apex A record synced with the www CNAME record resolution.

  3. For DNS servers with only basic functions, an SSL compatible redirection is available by using the free (first domain only) nakedssl service. Please note that this method is not compatible with websites redirecting the www to the apex, as such a configuration will cause an endless redirection loop.

  4. For DNS servers with only basic functions, a simpler but much less preferred solution is to set the apex A record to 174.129.25.170 to use the free wwwizer service. Please note that this method is not compatible with websites redirecting the www to the apex, as such a configuration will cause an endless redirection loop. This method will also not allow https:// SSL/TLS on the apex directly.

In all cases, the MX is easily handled by direct reference to the appropriate record from above.

Given the above, a typical snip of an externally delegated DNS zone record using the preferred CNAME flattening method of resolution for the apex with an ANAME (or equivalent record) would look something like the following for the example xyz.com.au domain...

@     ANAME      xyz-com-au-http.cnames121.com.
      MX     10  xyz-com-au-smtp.cnames121.com.
ftp   CNAME      xyz-com-au-http.cnames121.com.
mail  CNAME      xyz-com-au-smtp.cnames121.com.
www   CNAME      xyz-com-au-http.cnames121.com.

A typical snip of an externally delegated DNS zone record using the nakedssl method of resolution for the apex would look something like the following for the example xyz.com.au domain and with an example IP of 123.123.123.123 which would be provided by nakedssl...

@     A          123.123.123.123
      MX     10  xyz-com-au-smtp.cnames121.com.
ftp   CNAME      xyz-com-au-http.cnames121.com.
mail  CNAME      xyz-com-au-smtp.cnames121.com.
www   CNAME      xyz-com-au-http.cnames121.com.

A typical snip of an externally delegated DNS zone record using the much less preferred wwwizer method of resolution for the apex would look something like the following for the example xyz.com.au domain...

@     A          174.129.25.170
      MX     10  xyz-com-au-smtp.cnames121.com.
ftp   CNAME      xyz-com-au-http.cnames121.com.
mail  CNAME      xyz-com-au-smtp.cnames121.com.
www   CNAME      xyz-com-au-http.cnames121.com.

SPF

To authorise all our outgoing email servers to send email on behalf of their hosted domains, clients must include the following mechanism in their SPF TXT records...

include:_spf.servers121.com

DKIM

To allow DKIM tests to succeed for email sent by any of our outgoing email servers on behalf of their hosted domains, clients must include the following records in their DNS zones...

default._domainkey  CNAME  dkim.servers121.com.
dkim121._domainkey  CNAME  dkim.servers121.com.
Scroll