Home > Manual > Cloud DNS > Domains Tab > Resource Record Types

Resource Record Types

Total Uptime’s Cloud DNS Service supports 27 different DNS resource record types. That includes 26 standard record types and 1 special web-redirect type that we’ve created. Below is a comprehensive list of each record type which you can find in the Cloud DNS management interface.

DNS SOA Record

This is the “Start of Authority” resource record and is required for all domain names. Here is what the SOA record dialog box might look like:

The SOA record contains the following required properties:

Primary Name Server: This is the name server that is authoritative for the domain, and is considered the master. In most cases (unless you’re using us for secondary DNS), this will be one of our name servers, for example xx.uberns.com. It really doesn’t matter which of our name servers you put here, and this should be pre-populated when you create the domain. But if in doubt, go to the domains tab in the management portal and look for the grey box that lists the name servers we’ve assigned to your account.
Responsible Email: This is the email address of the person who is responsible for managing the domain, which is probably you! It could be a role account too. Note, the proper notation for this is to replace the @ symbol in the email with another . (dot, period). So johndoe@example.com would be johndoe.example.com. If you use the @ symbol, we’ll change it to the dot to make it proper. A lot of organizations are concerned about placing a real email here for spam reasons. While an email here is required to make it easy for someone to contact you should they have a problem with the domain, you could put a distribution list here, such as dns@example.com. It must not be blank.
Min TTL: This is a very important setting for your domain. In the early days of DNS this was used for setting the default TTL for newly created records that did not otherwise have a TTL specified, but that is rarely the case these days, especially at Total Uptime. This is now used for NXDOMAIN [RFC 2308] responses. What is an NXDOMAIN, you ask? Well, whenever a record is requested of a DNS server, the server is required by RFC to reply with a TTL (time to live), that is, how long the requesting server should cache the DNS record received in a response. This makes complete sense for records that exist, but what if someone requests a record that does not exist on your domain, for example abcdefg.example.com? If no record exists for abcdefg, the DNS server must respond to the requesting DNS server with that information. But it is also required to send a TTL, even for a non-existent record. So for all DNS records that do not exist, this TTL will be given out with the response. We highly recommend keeping this at 300 seconds (5 minutes) or less. Anything longer inevitably creates issues at some point in your life. Here is one such example.
Refresh Interval: The refresh interval applies only to secondary DNS servers. So if we are your only DNS provider, this does not really apply to you. In that case, we recommend leaving this set to the default value of 14400. If you did have a secondary DNS server, this is how frequently it would check in with us (the primary DNS server) to see if there were any updates. Of course, it would be doing this in addition to responding to NOTIFY messages.
Retry Interval: Just like above, this is applicable for secondary DNS servers only. The default value is 7200, but you may wish to increase it to 86400 (24 hours). In the same secondary DNS scenario, this is how quickly the server would try again if it was unsuccessful when it tried at the normal refresh interval.
Expire Time: This value is also only applicable for secondary DNS servers. The default value of 1209600 is actually at the low end of the recommended range. This is how long a secondary DNS server should wait to refresh before discarding a copy of your domain. This prevents secondary servers from holding onto domains that are out-of-date.
SOA TTL: This is an important value. It is the TTL for the SOA record itself. Unless you are planning a move from one DNS provider to another, this should remain relatively high. The minimum suggested value of 14400 (4 hours) is also the default value. Once your domain is transitioned, we recommend updating this value to 24 hours (86400).

DNS NS Record

This is the “Name Server” resource record and is required for all domain names. When you first create a domain name on our platform, the new domain tool will automatically configure two name servers for you. But you may need to add additional records to match those you configure at your domain registrar.

Below is what the new NS record dialog box might look like:

The NS record contains the following required properties:

Host: This is almost always configured for the apex of your domain, for example, the @ symbol, which is essentially blank. @.example.com is really just example.com. The only time you would specify a hostname with some other value is when you must delegate a sub-domain to another DNS provider. For example, if you had a mail delivery service that sent mail on behalf of your company from sub.example.com and they wanted control of DNS for sub.example.com.
Name Server: This is the name server responsible for DNS resolution. In almost all cases, these will be Total Uptime name servers, such as xx.uberns.com. In the example outlined above for a third party mail delivery service, these would then be configured to their name servers, and you would probably have at least two name servers for that provider with the same host name, but different name servers.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache the NS record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS A Record

This is the “Address” resource record and is used to map host names to IP addresses and returns a 32-bit IPv4 address. The record itself is not mandatory, but if you use one, some properties are required as outlined below:

Required Properties:

Host: This is the part that goes before your domain name. For example, if you wanted to configure an ‘A’ record for www.example.com, you would put ‘www’ here. If you need a record for the apex of your domain, for example just example.com, you must put the @ symbol here, which essentially represents a blank.
IP Address: This is the IPv4 address. For example 198.51.100.1 or 203.0.113.50
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

Optional properties:

ALF Pack: This is a Total Uptime specific select list. If you do not subscribe to one of our Networking Solutions (like load balancing, web application firewall etc), you will not see this. This makes it easy to map an ALF Pack (configuration) to a DNS ‘A’ record without having to copy the IP address of the published pack from one part of our management portal to another.
Geo Zone: This is also a Total Uptime specific select list. If you do not have our GEO DNS feature, you will not see this. This allows you to map a GEO Zone pool directly to an ‘A’ record for dynamic IPv4 delivery based on the geographic region of the requesting client/user.
Failover Pool: This is also a Total Uptime specific select list. If you do not have our DNS Failover feature, you will not see this. This allows you to map a DNS Failover pool directly to an ‘A’ record for automated updating during failover scenarios.

DNS AAAA Record

Similar to an ‘A’ record, this is an IPv6 Address resource record. It returns a 128-bit address, most commonly used to map hostnames to an IP address. The record itself is by no means mandatory, but if you use one, some properties are required as outlined below:

Required Properties:

Host: This is the part that goes before your domain name. For example, if you wanted to configure an ‘AAAA’ record for www.example.com, you would put ‘www’ here. If you need a record for the apex of your domain, for example just example.com, you must put the @ symbol here, which essentially represents a blank.
IPv6 Address: This is the IPv6 address. For example 2001:0db8:0a0b:0000:0000:0000:0000:00A1 or 2001:db8:a0b::A1 (which is the same IP, just collapsed)
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

Optional properties:

ALF Pack: This is a Total Uptime specific select list. If you do not subscribe to one of our Networking Solutions (like load balancing, web application firewall etc), you will not see this. This makes it easy to map an ALF Pack (configuration) to a DNS ‘AAAA’ record without having to copy the IP address of the published pack from one part of our management portal to another.
Geo Zone: This is also a Total Uptime specific select list. If you do not have our GEO DNS feature, you will not see this. This allows you to map a GEO Zone pool directly to an ‘AAAA’ record for dynamic IPv6 delivery based on the geographic region of the requesting client/user.
Failover Pool: This is also a Total Uptime specific select list. If you do not have our DNS Failover feature, you will not see this. This allows you to map a DNS Failover pool directly to an ‘AAAA’ record for automated updating of an IPv6 address during failover scenarios.

DNS AFSDB Record

This record provides the location of database servers for an AFS (Andrew File System) cell. This record is commonly used by AFS clients to contact AFS cells outside their local domain. If you don’t know anything about AFS, you don’t need this record.

The AFSDB record supports these properties:

Host: This is the part that goes before your domain name. For example, if you wanted to configure the record for afs.example.com, you would put ‘afs’ here. If you need a record for the apex of your domain, for example just example.com, you must put the @ symbol here, which essentially represents a blank.
Subtype: This is a 16-bit integer. In the case of subtype 1, the host has an AFS version 3.0 Volume Location Server for the named AFS cell. In the case of subtype 2, the host has an authenticated name server holding the cell-root directory node for the named DCE/NCA cell.
Domain Name: This is the fully qualified domain name of the device providing the service. For example, green.example.com
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS ATMA Record

This is an “Asynchronous Transfer Mode Address” resource record. It is considered an obsolete record type since it is not in current use by any notable application.

It supports the following properties:

Host: This is the part that goes before your domain name. For example, if you wanted to configure the record for atma.example.com, you would put ‘atma’ here. If you need a record for the apex of your domain, for example just example.com, you must put the @ symbol here, which essentially represents a blank.
Format: NSAP specifies that your ATM host uses addresses that conform to the Network Service Access Protocol (NSAP) address model for ATM addresses. E164 specifies that your ATM host uses the E.164 address format for ATM addresses.
Address: The ATM address (ATMA) of the ATM host in your network.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS CNAME Record

This is the “Canonical Name” resource record type. It is an alias of one name to another which allows one or more records to be resolved by another.

NOTE: The CNAME is not to be utilized as a redirect record, since it does not redirect, it merely resolves DNS. For example, if your CNAME of here.example.com points to an ‘A’ record of there.example.com, when someone attempts to resolve here.example.com, they will be given the IP address associated with there.example.com. If you need a redirect for web-based traffic, please use the Web-Redirect record type (scroll down to the bottom of this page for further details).

The CNAME record supports the following properties:

Alias: This is much like the Host property in other records. It is the part that goes before your domain name. For example, if you wanted to configure the record for www.example.com, you would put ‘www’ here. The CNAME does not support the apex of your domain. That is, the @ symbol which is equivalent to blank/nothing. In other words, if your domain is example.com, you cannot use a CNAME for example.com.
Points To: This is the alias, or the fully qualified domain name that should be used when providing a DNS response to this alias.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS DNAME Record

This is the “Delegation Name” resource record. It is an alias for the subtree (all subdomains) of the host you define, unlike CNAME, which is an alias only for the exact name. Like a CNAME record, the DNS lookup will provide an IP response based on what it finds at the target. For example, if you configure the DNAME host to be example.com with the target name of example.us, all requests for subdomains of example.com will be resolved by going to the same subdomain of example.us. So for example, if someone tried to resolve a.example.com, it would attempt to get the IP from a.example.us. Additionally, if someone tried to resolve www.example.com, it would attempt to get the IP from www.example.us. If nothing exists, it returns a standard NXDOMAIN response. This is almost like a complete domain alias, if you will, with some pretty powerful capability. For example, if you had similar domains with different TLDs, you could DNAME them all to your primary domain and they would essentially give out the same IPs for the same records.

The DNAME record supports the following properties:

Host: This is the part that goes before your domain name. For example, if you wanted to configure the record for this.example.com, you would put ‘this’ here. If you wanted to configure it for the apex (root) of the domain, you would put the @ symbol there, which is equivalent to a blank, if you will.
Target Name: This is the alias, or the fully qualified domain name that should be used when providing a DNS response to this alias.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS HINFO Record

This is the “Host Information” resource record. It specifies the host (server) CPU type and operating system. This information could be used by application protocols such as FTP, which uses special procedures when communicating with machines of a known CPU and operating system type. For security reasons, this record is not typically used on publicly accessible servers.

It supports the following properties:

Host: This is the part that goes before your domain name. For example, if you wanted to configure the record for this.example.com, you would put ‘this’ here. If you wanted to configure it for the apex (root) of the domain, you would put the @ symbol there, which is equivalent to a blank, if you will.
Host CPU: This may be up to 40 characters taken from the set of uppercase letters, digits, and the two punctuation characters hyphen and slash. It must start with a letter and end with a letter or digit. You can find the complete list in RFC 1700 starting on page 206.
Host Operating System: This may be up to 40 characters taken from the set of uppercase letters, digits, and the three punctuation characters hyphen, period, and slash. It must start with a letter, and end with a letter or digit. You can find the complete list in RFC 1700 starting on page 214.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS ISDN Record

The ISDN resource record maps a domain name to an ISDN (Integrated Services Digital Network) telephone number. The ISDN phone numbers / DDI (Direct Dial In) used should follow ITU-T E.163/E.164 international telephone numbering standards. For example: 12121234567 ( 1=USA, 212=Manhattan New York area code, 1234567=number)

DNS LOC Record

This is the “DNS Locator” resource record type. It is used to specify geographical location information about hosts, networks and subnets. A LOC record describes a location with the following properties:

Latitude / Longitude
Altitude
Size (diameter of the location described)
Horizontal / Vertical precision of the data

Because of the binary storage format used, the first digit of the size and precision properties must not be zero.

DNS MB Record

This is the “Mailbox Resource” record. Only use this record type if you have a specific requirement for it. Most mail servers on the Internet only support MX records.

The MB record maps a mailbox to a host (server). The host must be a valid A record already defined.

DNS MG Record

This is the “Mail Group Member” resource record. Only use this record type if you have a specific requirement for it. Most mail servers on the Internet only support MX records.

The MG record is used to specify mail group members where each member mailbox must be identical to a valid mailbox.

DNS MINFO Record

This is the “Mailbox or Mail List Information” resource record. Only use this record type if you have a specific requirement for it. Most mail servers on the Internet only support MX records.

The MINFO record specifies the mailbox of the responsible person and optionally a mailbox for errors for this mailbox or list. Each mailbox must be the same as a valid mailbox (MB record) that already exists in the zone.

DNS MR Record

This is the “Renamed Mailbox” resource record. Only use this record type if you have a specific requirement for it. Most mail servers on the Internet only support MX records.

The MR record specifies a renamed mailbox and can be used as a forwarding entry for a user who has moved to a different mailbox.

DNS MX Record

This is the “Mail Exchange” resource record. MX records are used to specify the mail server(s) responsible for a domain name. Each MX record points to the name of a mail server and holds a preference number for that server.

The MX record supports the following properties:

Hostname: This represents the domain that is receiving the email. For example, if your domain is example.com and you receive email to johndoe@example.com, the Hostname would be @ for the apex of your domain, equivalent to blank.
IMPORTANT! Do not put something like “mail” into this box unless you have email addressed to something like johndoe@mail.example.com. This is a very common mistake. In 99% of client configurations, the hostname should be the @ symbol.
Mail Server: This is the fully qualified domain name of the server that receives the mail. For example, mail.example.com, or it could be the mail server for another organization that may handle mail on your behalf.
Preference: The preference is a number where the lowest number of all available servers specifies the server that should be used first when attempting mail delivery. Should that server be unavailable, mail servers will select the MX record with the 2nd lowest priority. This must NOT point to an IP address, so if it is to point to your existing domain, like mail.example.com, you will need to configure an ‘A’ record for that as well.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS NAPTR Record

This is the “Naming Authority Pointer” resource record. It allows regular-expression-based rewriting of domain names which can then be used as URIs for DDDS (Dynamic Delegation Discovery System) applications. It is most commonly used for applications in Internet Telephony, for example, in the mapping of servers and user addresses in SIP. The combination of NAPTR records with SRV records allows the chaining of multiple records to form complex rewrite rules which produce new domain labels or URIs.

The NAPTR record has the following properties:

Host: This is the part that goes before your domain name. For example, if you wanted to configure the record for this.example.com, you would put ‘this’ here. If you wanted to configure it for the apex (root) of the domain, you would put the @ symbol there, which is equivalent to a blank, if you will.
Order: This field is a number from 0 to 65535 specifying the order in which multiple NAPTR records must be processed from low to high. It is much like the preference value of MX records.
Preference: This field is equivalent to the Priority value in the DDDS algorithm. It is a number from 0 to 65535 that specifies the order from low to high in which NAPTR records with equal Order values should be processed. Again, it is quite similar to the preference value of MX records.
Flags: This field contains flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from A to Z and 0 to 9. The use of this field is specified by the individual DDDS application.
Services: This field specifies the service parameters applicable to this delegation path. The individual DDDS application specifies the possible values for this field.
Regular Expression: This field contains a substitution expression that is applied to the original string held by the client in order to build the next domain name to look up. See the DDDS algorithm for the correct syntax here.
Replacement: This field specifies the next fully qualified domain name to query based on the values found in the flags field. This field is used when the regular expression is empty.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS NSAP Record

This is the “Network Service Access Point” resource record. It contains an address entered using hexadecimal digits and supports any NSAP address format.

This record is best defined by RFC 1706. Please consult the RFC documentation for further information.

DNS RP Record

This is the “Responsible Person” resource record. It usually contains an email address for the responsible person(s) for a specific host. Much like the SOA record where the responsible person is listed there for the entire zone/domain, this allows you to specify a specific host/record. Also like the SOA record, the @ is replaced by a dot/period (.)

The RP record contains the following properties:

Host: This is the host that the person is responsible for. For example, if John Doe is responsible for the “www” record, you would also put “www” here.
Responsible Email: This is the responsible person’s email. Again, for John Doe, you would put john.doe.example.com (@ replaced with a . )
TXT Record Domain Name: This is an optional field where you can provide additional information, such as a phone number.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS RT Record

This is the “Route Through” resource record. It specifies an intermediate host that routes packets to a destination host. The RT record is used in conjunction with the ISDN and X25 resource records. It is syntactically and semantically similar to the MX record type and is used in much the same way.

DNS SPF Record

This is the Sender Policy Framework record. This record type was deprecated in 2014. See RFC 7208 for more detail (synopsis below). While you may still use it, you should always create SPF records using the TXT record type first, then duplicate that content into an SPF record if you wish. It will be removed at some point in the near future.

According to RFC 7208 Section 3.1: During the period when SPF was in development, requirements for assigning a new DNS RR type were more stringent than they are today and support for the deployment of new DNS RR types was not deployed in DNS servers and provisioning systems. The end result was that developers of SPF discovered it was easier and more practical to follow the TXT RR type for SPF.

DNS SRV Record

This is the “Service Locator” resource record. It allows servers providing a TCP/IP based service to be found using a single DNS query. This record type enables you to maintain a list of servers for well-known ports and transport protocol types, all ordered by preference. It is commonly used for LDAP (Lightweight Directory Access Protocol), Windows directory services and recently with SIP (Session Initiation Protocol) servers.

The SRV resource record has the following properties, all of which are mandatory:

Service: The service field consists of both the service and the protocol (generally TCP or UDP) with specific notation. For example, for SIP using TLS, you would fill this field out with “_sip._tls” and of course, your domain name is appended to the end of that automatically as shown in the dialog box image above. Note the underscore in front of both the service and protocol, as well as the dot (.) separating the two.
Port: This is simply the TCP or UDP port that is providing the service, from 1 to 65535. An example for SIP using TLS might be 443.
Weight: This is used for advanced load balancing when multiple identical records exist. If you only have one record for this service and protocol, the value does not matter much, but it must be configured. A default value of 0 is set, but 10 or 100 would be acceptable too.
Priority: This is a preference number used when more servers are providing the same service. If you only have one record for this service and protocol, the value does not matter. Lower numbers are always tried first. A default value of 0 is set.
Target: This is the fully qualified domain name of the server providing the service. For example, a common entry here for Microsoft Lync would be “sipdir.online.lync.com”.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS TXT Record

This is the “Text” resource record. It was originally designed for arbitrary human-readable text in a DNS record. But more recently it is now used to carry machine readable data, such as that specified in RFC 1464 for SPF (Sender Policy Framework), DKIM (Domain Keys Identified Mail, or just Domain Keys) and more.

The Text Resource record contains the following properties:

Hostname: This is the part that goes before your domain name. For example, if you wanted to configure the record for this.example.com, you would put ‘this’ here. If you wanted to configure it for the apex (root) of the domain, you would put the @ symbol there, which is equivalent to a blank, if you will.
Text: This is the free form text data. A TXT record is designed to only hold 255 characters here, but the Total Uptime DNS system will accept much more, such as 4096 bit DKIM keys. You may paste the entire key here, and our back-end systems will break it up into individual 255 character TXT records so you don’t have to.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

Here are some common use examples for TXT records:

Domain Keys: For domain keys, the hostname would be configured as your selector, and the Text would be the value of the key. For example. If your selector were “mail”, you would put “mail._domainkey” into the Hostname field. Note that it contains both the selector and the word “domainkey” separated with a dot (.) and an underscore (_). This is essential. The Text field would then contain your key. As an example:

v=DKIM1; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDfl0chtL4siFYCrSPxw43fqc4z
Oo3N+Il220oK2Cp+NZw9Kuvg8iu2Ua3zfbUnZWvWK4aEeooliRd7SXIhKpXkgkwn
AB3DGAQ6+/7UVXf9xOeupr1DqtNwKt/NngC7ZIZyNRPx1HWKleP13UXCD8macUEb
bcBhthrnETKoCg8wOwIDAQAB

SPF Record: For SPF records, if mail flows from users at your domain @example.com, you would configure the hostname with the @ symbol to represent the apex of your domain and then the Text with your SPF content. For example:

"v=spf1 a:mail.example.com -all"

You can learn a lot more about SPF records and how to configure them here at openspf.org.

DNS X25 Record

This is the “X.25” record type. It maps a DNS domain name in the owner field to a Public Switched Data Network (PSDN) address number specified in the psdn_number. PSDN numbers used with this record should following the X.121 international numbering plan. For more information, see RFC 1183.

DNS PTR Record

This is the “Pointer” resource record. This record type is only available in reverse zones and is used to map IP addresses to domain names (the reverse of an A or AAAA record).

For a reverse IPv4 mapping, the name of the PTR-record is the IP address with the segments reversed and with “in-addr.arpa” appended to the end. As an example, looking up the domain name for IP address “203.0.113.1” is done with a query for the PTR-record for “1.113.0.203.in-addr.arpa”. To create a reverse IPv4 zone, you first need to know how it has been routed to Total Uptime’s DNS servers. The easiest is for an entire /24. For example, if you control the entire IP block of 203.0.113.0/24, you would create a reverse zone for 113.0.203.in-addr.arpa and then simply create PTR records for each individual IP representing the last octet.

For a reverse IPv6 mapping, the name of the PTR-record is each hex digit of the IP address in reverse order, with dots between each digit, and with “ip6.arpa” appended to the end. As an example, looking up the domain name for IPv6 address “1234:5678:90ab:cdef:1234:5678:90ab:cdef” is done with a query for the PTR-record for “f.e.d.c.b.a.0.9.8.7.6.5.4.3.2.1.f.e.d.c.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa”. To create a reverse IPv6 zone, you also need to know how it has been routed to Total Uptime’s DNS servers, but you may also want to consider breaking it out into much smaller ip6.arpa zones to group your records into more easily managed blocks.

The PTR resource record contains the following properties:

Hostname: This represents a portion of the reverse zone, based on how you’ve configured the zone. For the example above where you control all of 203.0.113.0/24, you would only need to manage the last octet within the hostname field. For example (and as shown in the image above) for the IP of 203.0.113.1 you would only put the digit “1” into the hostname field. For IPv6 it is a little more difficult, but in general all 32 hexadecimal must be represented (separated by a dot, of course) by the combination of the zone name and hostname field combined.
Domain Name: This is the fully qualified domain name that maps to this IP address.
TTL: This is the Time To Live. This is how long a recursive DNS server should cache this record. Caching means that subsequent requests to that server for the same record will not come to Total Uptime, the server will utilize the response it previously obtained until the TTL expires. Then, after expiration, it will come to Total Uptime to get an updated response, just in case it has changed in the interim.

DNS Web Redirect Record

This is a custom record created by Total Uptime to redirect DNS host names to a URL. It only works in web-browsers, of course, but can be quite powerful. For example, it could be used to redirect test.example.com over to http://www.example.com. It can even support more complex URLs that start with HTTPS or even contain query strings, for example https://www.example.com/sub-directory/another/index.aspx?stringvalue=1234

The Web Redirect record contains the following properties, all of which are mandatory:

Hostname: This is the part that goes before your domain name. For example, if you wanted to configure the record for www.example.com, you would put ‘www’ here. If you wanted to configure it for the apex (root) of the domain, you would put the @ symbol there, which is equivalent to a blank, if you will.
Destination: This is a fully qualified URL that you want to redirect user to. For example, http://www.example.com. As noted above, it can contain a more complex URL inclusive of directories and querystring variables in addition to HTTPS. For example: https://www.example.com/sub-directory/another/index.aspx?stringvalue=1234
Carry Original path: This determines if anything after the domain (e.g. a directory path or page) should be carried along to the new destination. For example, if someone visits example.org/directory/page.php and you want to redirect them to example.com do you want it to bring the original path of /directory/page.php along with it and append it to the new URL? If yes, check this box. If not, all path details will be stripped.
Redirect Type: You must select between a 302 (temporary redirect) or a 301 (permanent redirect) option. If it will be permanent, use 301 which is highly preferred by search engines.

We also support other DNS record types behind-the-scenes such as DNSKEY, RRSIG, NSEC, NSEC3, DS and DLV used for DNSSEC. These are generated automatically for signed domains.