The user portal includes DNS record management service. It provides DNS services and a REST API and gives you a secure and efficient way to create, publish, and manage your DNS zones and records. Using this service, you can easily create and manage name records for the services and application you build on the platform or elsewhere.
While DNS record management service is a part of the platform functionality, DNS registrar is not. You can't "buy" or register a new domain via the platform - you need to buy it elsewhere. However, once you own the domain, you can easily manage DNS for that domain using the DNS record management service.
As a part of the service functionality, the platform includes a set of DNS servers, that respond to the clients' requests about DNS records stored. These servers are not set up like regular internet service provider DNS servers you might be familiar with, or public DNS servers like Google's 8.8.8.8 or 8.8.4.4. First, they are configured to reply to DNS queries only (UDP port 53). They do not respond to ICMP (ping) or any other protocol requests. But more importantly, they are not configured to support recursion (which means, if you ask these servers about record they do not own, they will not go to other DNS servers to look up this information for you). Therefore, you should not use these DNS servers for any other purpose, such as using them in DNS client configuration.
To get started, let's consider a couple of possible scenarios how you may want to use DNS record management service. Let's say you own a domain mycompany.com. In the first scenario, you may want to manage the entire domain in this service - this will allow you to create a manage records like www.mycompany.com and mail.mycompany.com. In the second scenario, you may want to leave the domain management where it is now, however, create a separate zone within the domain - let's say dev.mycompany.com, and use the DNS record management service to manage records within this zone - such as bugtracking.dev.mycompany.com or app1.dev.mycompany.com.
Depending on which of those scenarios you want to go with, the initial configuration with you current DNS registrar will be slightly different. Subsequent operations on the platform, however, will be absolutely the same for both of these scenarios.
For both of these scenarios, you will need to delegate your zone to DNS servers under the user portal. To do that, first, navigate to the DNS record management in the portal (Networking->DNS), and click "Add DNS" button. Type the "DNS name" you want - in the examples above, it would be either mycompany.com. or dev.mycompany.com. Click "Create". When record is created, click on the action button of that record, and select "Edit domain".
In the window that opens, note the "Name Servers" field. Those are the name servers that will hold authority (also called SOA - Start Of Authority) records. You will need to use these name servers to configure DNS delegation with your current domain registrar.
As the next step, go the domain management control panel of your DNS registrar. Select the domain you want to manage. The next action depends on which scenario you want to perform:
To delegate the entire domain (mycompany.com), you will need to change the name servers for this domain to the name servers noted above in the portal. Likely, that means changing name servers from "default" (provided by the registrar itself) to "custom" (shown in the "edit domain" settings in DNS record management.)
To delegate a subdomain within the domain (dev.mycompany.com), leave the name servers as they are. Instead, use the DNS record management functionality provided by the registrar to create NS record type within domain mycompany.com for the name dev, pointing to the Name Servers noted above. That operation effectively registers a zone dev in the domain mycompany.com, delegating the zone management to the name servers running under the platform.
The initial configuration is now complete - you may begin name managing records for your domain now. The examples below assume that you delegated dev.mycompany.com zone.
To manage DNS records on your domains, click on the action button on the domain, and select "Manage Records". A record management window opens. In the window, you can create records of the following types:
A is an "Address record" - this is the most well-known record type, returning IPv4 address of the name. Common network clients like browser, ssh or ping will look up for this record type to find IP address of the destination specified by name. For example, you can specify that name www.dev.mycompany.com resolves to IP address 1.2.3.4.
CNAME is a short for "Canonical Name", this is an alias of one name to another, creating a record that contain another name rather than IP. The DNS lookup process will continue by retrying the lookup with the new name, until final record (for example A type) will be found. Let's say if your app.dev.mycompany.com application is running on the same IP as www.dev.mycompany.com, you can create CNAME alias app to www.
MX is a "Mail Exchange Record" used by e-mail clients. For example, when someone sends an email to user@dev.mycompany.com, the mail server will look up MX record for dev.mycompany.com. The record itself must be specified in the format weight hostname, for example 10 mail.mycompany.com. You can add multiple records with different weights to specify primary and backup mail servers - if one with highest priority (lowest weight number) is unavailable, the clients attempting to send an e-mail to the "user@dev.mycompany.com" will keep trying to contact other servers in the list.
TXT is a "Text Record". Originally designed for humans to read (one could provide arbitrary information about the name records), it is also used to supply text data for machine reading. Arbitrary text may be specified in the record body; DNS servers and clients do not treat this information in any specific way.
SRV is a "Service locator" record - it may be used by newer protocols, similar to MX that do not have their own record types. The record must conform to certain format requirements, where name is in the format _service._proto.name., and the record - priority weight port target., where
For example, if you want to run a SIP server within your organization, you may add a record similar to this:
Type: SRV
Name: _sip._tcp.dev.mycompany.com.
TTL: 3600
Record: 0 5 5060 sipserver.dev.mycompany.com.
Which will result in the following record in DNS:
_sip._tcp.dev.mycompany.com. 3600 IN SRV 0 5 5060 sipserver.dev.mycompany.com.
NS is a "Name Server" record. This is a mechanism to delegate a zone (sub-domain) to another name server. For example, you can create a record indicating that to look up names within qa.dev.mycompany.com domain, one should contact server "ns1.dev.mycompany.com".
PTR is a "Pointer record", which creates pointer to a canonical name. Unlike a CNAME, DNS processing stops and just the name is returned. The most common use is for implementing reverse DNS lookups (allowing to find domain names for IP addresses). For example, you can create a record for reverse DNS lookup of IP address "192.168.1.1" pointing to "test.internal.dev.mycompany.com". Note however configuration of reverse DNS zones require creating in-addr.arpa zone (reverse DNS records cannot be created within "mycompany.com" domain), and full guide building such configuration is beyond the scope of this document.
SPF ("Sender Policy Framework") records were used by SPF protocol to validate that incoming mail from a domain comes from an IP Address that is authorized to send such emails. This mechanism is used one of the anti-spam techniques. Note however that recent RFC 7208 defines this type of record as discontinued, and TXT records are used instead. For more details, consult this Wikipedia article.
SSHFP records are "SSH Public Key Fingerprint", it identifies SSH key with a host name. The record format is Algorithm Type Fingerprint (for example, 2 1 123456789abcdef67890123456789abcdef67890), where
SOA is a "Start of authority" record. It indicates that current DNS server has an authority over the zone. This record is automatically created when you add a zone to manage to the DNS record manager. You can only modify this record via "Manage domain" functionality (click "Manage domain" in the action menu to access it.)
TTL, or Time to Live fields specify maximum period of time (in seconds) that a response can be cached by the client or other name servers. The value 3600 means 1 hour, and 86400 means 24 hours. Generally, with longer TTL you will have fewer clients accessing DNS servers, however, if you need to update your records, it will take longer for the clients to receive that update. As a compromise between time to propogate a record change and DNS servers load, many administrators use 24 hours by default - however, when they plan to modify some records, they decrease TTL to 1 hour or shorter for these records several days in advance.
Note that DNS record management service require you to provide full names (FQDN). For example, to create an A type record for www.dev.mycompany.com, you must specify the name as www.dev.mycompany.com, and not just www - in the latter case, you will receive an error stating that "RecordSet is not contained within it's parent zone".