Select a Record type from the Table of Contents to view the information about that Record type and instructions on how to complete the form to add that Record type into your Zone.
(A) IPv4
Host record, used to point a host name to an IPv4 address. See RFC 1035 for more information on (A) IPv4 records including information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
IP Address — Enter the IPv4 address for the host defined by this record and zone.
Add Dynamic DNS Service — Selecting this check box will override the TTL value setting it to 1 minute. This is to accommodate the need for Dynamic DNS to propagate changes quickly.
Add — Click to add the record to your zone.
(AAAA) IPv6
Host record, used to point a host name to an IPv6 address. IPv6 is still in the early adopter phase of its lifecycle and is not as prevalent as IPv4. See RFC 3596 for more information on (AAAA) Records including information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
IP Address — Enter the IPv6 address for the host defined by this record and zone.
Add Dynamic DNS Service — Selecting this check box will override the TTL value setting it to 1 minute. This is to accommodate the need for Dynamic DNS to propagate changes quickly.
Add — Click to add the record to your zone.
(ALIAS)
Used to create a private pseudo-record to allow the CNAME functionality at the apex of a zone for A & AAAA record types. Valid for Dyn’s Managed DNS customer accounts only. This is a non-standard use of record types. View our ALIAS guide for a more detailed explanation of this record type.
TTL — The Time To Live (TTL) field is not editable. The TTL of an ALIAS record is based on the TTL of the response record the ALIAS record points to.
Alias — Enter the zone alias, for example: foo.example.com.
Add — Click to add the record to your zone.
(CAA)
CAA records allow a DNS domain name holder to specify one or more Certification Authorities authorized to issue certificates for that domain. See RFC 6844 for more information about CAA records.
For the Expert Editor, you must format the RData value as follows: Flags, Tag, Value (for example, 1 5 value.com).
Flags – An unsigned integer between 0-255. The issuer-critical flag is the only flag currently defined, per RFC 6844. If the flag value is set to 128, this indicates that a Certificate Authority (CA), which does not understand or does not implement the property tag in this record, should refuse to issue a certificate for the domain.
Tag – A non-zero sequence of US-ASCII letters and numbers in lowercase. Valid values: “issue”, “issuewild”, and “iodef”
Value – The authority for this record. EXAMPLE: ”letsencrypt.com”.
(CDNSKEY)
Used for moving a CDNSSEC signed zone from one DNS provider to another. The information you provide in this record needs to match the CDNSKEY information for your domain at your other DNS provider. This record is automatically created if you enable DNSSEC on a Primary Zone in Managed DNS. See RFC 7344 for more information on CDNSKEY including information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Flags — Numeric value that states that this CDNSKEY is the zone’s key. Default value = 256
Protocol — Always set to 3 (DNSSEC).
Algorithm — Which public-key encryption algorithm is to sign this zone. A value of 5 is for the algorithm RSA/SHA-1, which is considered mandatory. Default value = RSA/SHA-1
Key — Enter the DNSSEC public key from your current DNSSEC signed zone.
Add — Click to add the record to your zone.
(CDS)
The Child Delegation Signer (CDS) record is created at the top-level domain where the zone resides. Examples of top level domains are .com, .edu, .org, and .net.
The CDS record is created when DNSSEC security authentication is added to the zone, requiring a CDNSKEY record on the zone itself. The delegation signer (CDS) record is inserted at a zone cut (i.e., a delegation point) to identify the DNSSEC signing key of a delegated zone.
See More Information on DNSSEC to learn about the DNSSEC feature in DynECT DNS.
See Setting Up DNSSEC On Your Zone for the instructions to setup DNSSEC authentication in your zone.
See RFC 7344 for more information on CDS records.
For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
(CERT)
Used to store public key certificates and related certificate revocation lists in DNS. See RFC 4398 for more information including information to complete the RData field in DynECT Managed DNS’ Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
The fields in Managed DNS for this record type include:
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Format — Listed by RFC 4398 as Certificate Type. Must use the numeric value for Certificate type. Example: 3
Key Tag — Identifies which private key was used to sign the public-key certificate. Must use a numeric value for the Key Tag.
Algorithm — The public-key algorithm number used to generate the certificate.
Example: if RSA/SHA 1 was used, its algorithm # is 5, which would be placed in this field.
Certificate — Enter the actual public-key certificate.
Add — Click to add the record to your zone.
(CNAME)
Used to identify the Canonical Name (CNAME) of the zone.
For example, if there is a DNS zone as follows:
NAME TYPE VALUE -------------------------------------------------- foo.example.com. CNAME bar.example.com. bar.example.com. A 192.0.2.23
When an (A) record lookup for foo.example.com is done, the resolver will see a CNAME record and restart the checking at bar.example.com and will then return 192.0.2.23.
See RFC 1035 for more information on the (CNAME) records including information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
CNAME — Enter the Canonical Name for the zone.
Add — Click to add the record to your zone.
(CSYNC)
See RFC 7477 for more information on CSYNC including information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
SOA Serial — A copy of the 32-bit SOA serial number from the child zone.
Flags — Flags that define operations that affect the processing of the CSYNC record.
Valid values:
immediate
soaminimum
immediate AND soaminimum
Types — Types covered by this record. Can be any/all of NS/A/AAAA.
Add — Click to add the record to your zone.
(DHCID)
Sometimes even when using DHCP to assign IPs to a host, you want to keep the IP assignment static for a particular host. There are plenty of homegrown approaches to making this happen in a local network. Inevitably conflicts occur.
The DHCID provides a way to store DHCP client identifiers in the DNS to eliminate potential hostname conflicts within a zone. The data in a DHCID is a hashed representation of a unique identifier and the fully qualified domain name of the host. By pairing an IPv4 or IPv6 Address record in DNS with a DHCID record, site administrators can set strict policies on which DHCP client has rights to update the DNS for that host name.
Generating the digest for DHCID records is beyond the scope of this documentation, however you can find recommendations and examples described in RFC 4701 including information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Digest — Generating the digest for DHCID records is beyond the scope of this documentation, however you can find recommendations and examples described in RFC 4701.
Add — Click to add the record to your zone.
(DKIM)
The DomainKeys Identified Mail (DKIM) record is a special TXT record set up specifically for the purpose of supplying the public key to be used to authenticate arriving mail for the domain. For more information on (DKIM) text records, please see RFC 4871 and RFC 5672 including information to complete the RData field in the Managed DNS Expert Editor.
DKIM uses a TXT record to contain DNS data. The generic format of the TXT and DKIM TXT record is:
; Generic TXT RR format name ttl class TXT text ;DKIM TXT RR format selector._domainkey ttl class TXT DKIM-specific-text
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Data — Enter the DKIM information
Here are example SPF and Domain Key TXT records (note the use of double quotes):
example.com. 43200 IN TXT "v=spf1 a a:outbound.mailhop.org ~all" _domainkey.example.com. 43200 IN TXT "t=y\; o=~\; r=postmaster@example.com"
Here is an example of a TXT record for DKIM with more than 255 characters. (note the use of double quotes) When splitting the TXT record, make sure that all intended spaces are within the quotation marks. When the separate strings are concatenated, there are no spaces between the strings.
"v=DKIM1\; k=rsa\; p=MIIBIjANB" "gkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHsdDxL+4Gs44BV0TZ8hY2NZ0/qYkqXC1rFHj1WayMXnliHYXZtGdmtpDRJWDC1+/6M8D68 sRu4zQNRiUho4ZISbrmQNbTxe7Zv4GaegexF6yDjzl+BtegDo24gVP/9DMbObv/cFny+Qa8ifM5ThEUMDlKAG+qZL1E/U2fq6vXsHakbfw0Ostz/WeB85c kW5qePj/yY" "n3FyKxVy28oKAvOt1rhx1hvkRQA59RfhzmhV/FF78y7OFy87q2k0qHvXKjuTIrHckU95x1wFM6baL7fUIBb3CJSCla7FXoFUip6DwAudm9xO+lnrY4lTo 3nAzw+gCNA+dDGxKETdinFdaJwIDAQAB"
Add — Click to add the record to your zone.
(DNAME)
A DNAME record (defined in RFC 6672) is essentially a wildcard version of a CNAME record. While CNAME records are limited to working on a single node, a DNAME record allow you to map an entire subtree underneath a node to another domain.
The key point to remember is that a DNAME record can only apply to the subtree underneath a node, not the node that it lives on. This prevents the use of DNAME records to map an entire zone to another zone, as placing a DNAME record at the apex of the zone (example.com) only covers nodes underneath the apex of the zone (foo.example.com, bar.example.com, etc.), not the apex of the zone itself (where your zone apex records such as SOA, NS, MX, A, etc. records are stored).
A DNAME record cannot coexist with a CNAME record on the same node, however it can coexist with any other record type (such as SOA, NS, A, MX, etc).
So far Dyn has seen limited adoption of the DNAME record type due to these limitations. Also there are many expected behaviors that DNS resolvers must be able to handle in order to use DNAME records properly. We recommend a thorough reading of RFC 6672 if you intend to use this record type. This RFC also includes information to complete the RData field in the Managed DNS Expert Editor.
Example of DNAME record at apex of zone:
- Create a zone called example.com
- Create a DNAME record at apex of zone pointing to example.net and publish the zone
- You will notice that you cannot add another node to the zone as the DNAME now controls the subtree of the zone.
- Add your A record, MX record, etc to the apex of the zone.
- If you query for foo.example.com, then the DNAME record translates that query to foo.example.net
- However, if you query for example.com, you will get the A record you created back and not the DNAME record.
Example of a DNAME record on a node without an A record coexisting with it:
- Create a node called foo.example.com
- Create a DNAME record on foo.example.com that points to foo.example.net
- Publish your zone.
- If you query for bar.foo.example.com, they will get a DNAME record in return that says bar.foo.example.net
- If you query for just foo.example.com, you will get no record back since the DNAME record doesn’t cover foo.example.com, just anything underneath it such as bar.foo.example.com. If you need an answer for foo.example.com, simply add an A record on the foo.example.com node alongside the DNAME record.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
DNAME — Enter the chosen DNAME for this domain.
Add — Click to add the record to your zone.
(DNSKEY)
Used for moving a DNSSEC signed zone from one DNS provider to another. The information you provide in this record needs to match the DNSKEY information for your domain at your other DNS provider. This record is automatically created if you enable DNSSEC on a Primary Zone in Managed DNS. See RFC 4034 for more information on DNSKEY including information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Flags — Numeric value that states that this DNSKEY is the zone’s key. Default value = 256
Protocol — Always set to 3 (DNSSEC).
Algorithm — Which public-key encryption algorithm is to sign this zone. A value of 5 is for the algorithm RSA/SHA-1, which is considered mandatory. Default value = RSA/SHA-1
Key — Enter the DNSSEC public key from your current DNSSEC signed zone.
Add — Click to add the record to your zone.
(DS)
The Delegation Signer (DS) record is created at the top-level domain where the zone resides. Examples of top level domains are .com, .edu, .org, and .net.
The DS record is created when DNSSEC security authentication is added to the zone, requiring a DNSKEY record on the zone itself. The delegation signer (DS) record is inserted at a zone cut (i.e., a delegation point) to identify the DNSSEC signing key of a delegated zone.
See More Information on DNSSEC to learn about the DNSSEC feature in DynECT DNS.
See Setting Up DNSSEC On Your Zone for the instructions to setup DNSSEC authentication in your zone.
See RFC 4034 for more information on DS records.
(IPSECKEY)
The IPSECKEY resource record is used to store public keys for a host, network, or application and which remote host to connect to for use in IP security (IPsec) systems. It is defined in RFC 4025 along with information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
There can be multiple IPSECKEY resource records on a node due to multiple gateways and the need to rollover keys over time. Use of IPSECKEY resource records in Reverse DNS zones is approved as in many cases customers may only know the IP address they are connecting to and not the actual hostname. It is highly recommended that IPSECKEY be used in alongside DNSSEC to ensure the security of the DNS query.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Precedence (Required)— Similar to the preference value in MX records. If multiple IPSECKEYs exist on a node, the lower value (10) takes precedence over the higher value (20).
Gateway Type (Required) — Value that states what type of gateway is used, if any. Types are:
- 0 – No gateway present
- 1 – IPv4 address present (such as 192.0.2.38)
- 2 – IPv6 address present (such as 2001:0DB8:0:8002::2000:1)
- 3 – Gateway hostname present (such as mygateway.example.com)
Algorithm (Required) — Identifies the public key’s cryptographic algorithm and the format of the public key field.
- 0 – No key present
- 1 – DSA key present
- 2 – RSA key present
Gateway (Required) — The gateway that can be used to create the IPsec tunnel.
- If gateway type is 0, then the gateway field must contain a single period “.”
- If gateway type is 1, then type in the IPv4 address
- If gateway type is 2, then type in the IPv6 address
- If gateway type is 3, then type in the hostname with a trailing period (such as mygateway.example.com.)
Public Key — Base64 encoding of the public key. Whitespace is allowed.
For several examples of IPSECKEY resource records properly formatted, please see RFC 4025 section 3.2.
Add — Click to add the record to your zone.
(KEY)
Used to store a public key that is associated with a domain name. Currently only used by SIG and TKEY resource records. IPSECKEY and DNSKEY have replaced KEY for use in IPsec and DNSSEC respectively. Please see RFC 2535 section 3.1 and RFC 2930 for more information including information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Flags — Please see RFC 2535 section 3.1 for more information on the format for flags.
Protocol — Which protocol this KEY record is to be used for
- 1 – TLS
- 2 – Email
- 3 – DNSSEC
- 4 – IPsec
Algorithm — Which algorithm is used.
- 1 – RSA/MD5 (recommended)
- 2 – Diffie-Hellman (optional, key only)
- 3 – DSA (mandatory)
Key — Public Key
Add — Click to add the record to your zone.
(KX)
Key eXchanger record
RFC 2230 states that “The KX record is useful in providing an authenticatible method of delegating authorization for one node to provide key exchange services on behalf of one or more, possibly different, nodes.” Please consult RFC 2230 for more information including information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Preference — Similar to the MX record’s preference. Lower value (10) takes precedence over a higher value (20) if multiple KX records exist on the same node.
Key Exchanger Host — The hostname that will act as the key exchanger. The hostname must have a CNAME record, an A record, and/or an AAAA record associated with it.
Add — Click to add the record to your zone.
In order to ensure that KX records are properly authenticated, DNSSEC is required on the zone according to RFC 2230 Section 4.
(LOC)
Designed to store geographic location data of computers, subnets, and networks within DNS as defined by RFC 1876. DNS LOC has some great resources for how to use LOC records along with some experimental maps. Please refer to RFC 1876 for more information including information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Latitude — Measured in degrees
Longitude — Measured in degrees
Altitude — Measured in meters above sea level
Size(optional) — Defaults to 1 meter
Horizontal Precision (optional) — Defaults to 10,000 meters
Vertical Precision (optional) — Defaults to 10 meters
Add — Click to add the record to your zone.
(MX)
Mail Exchanger records are used to define the mail server accepting email for the domain.The Mail Exchanger record should be a fully qualified domain name (FQDN). (MX) records should not point to the CNAME or IP address as some email systems are not able to handle these and it could prevent the proper delivery of email. See RFC 1035 and RFC 7505 for more information on the (MX) record including information to complete the RData field in the Managed DNS Expert Editor.
For the Expert Editor, you must specify the preference in the RData field in the following format: 15 mailexchangerhost.com
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Preference — The MX record with the lowest Preference number is used first, then the record with next highest number. Default = 10.
Mail Exchanger Host — Host name of the server responsible for accepting mail messages in the zone.
Add — Click to add the record to your zone.
(NAPTR)
The Naming Authority Pointer (NAPTR) stores information used by ENUM (Telephone Number Mapping) to map E.164 numbers to URIs. See RFC 3403 for more information on (NAPTR) records including information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Order — Similar to the MX record’s preference value or SRV record’s priority value. The lowest value is used first, highest value used last
Preference — If one or more NAPTR records have the same value for order, the value of the preference is used to decide which NAPTR record is used first. Similar to the Order value (and MX & SRV records), lowest value is used first, highest value is used last.
Flags — Currently only the “u” flag is currently defined for NAPTR records. By using the “u” flag, this indicates that this NAPTR record terminal (E.164 number that maps directly to a URI).
Regexp — The NAPTR record accepts a Regular Expression string containing a substitution expression and formatted in accordance with the grammar rules explained in RFC 3403 section 3.
Services — Always starts with “e2u+” (E.164 to URI). After the e2u+ there is a string that defines the type and optionally the subtype of the URI this NAPTR record points to.
Replacement — If this is a non-terminal NAPTR record, this field specifies the next domain name to look up.
Add — Click to add the record to your zone.
(NS)
Nameserver (NS) records are used to list all of the authoritative nameservers for your domain or subdomain. By default, any new primary zone in Managed DNS will automatically create NS records at the apex of the zone for your assigned nameservers. Dyn’s Managed DNS allows you to add other NS records at the apex of the zone if you are using multiple DNS providers (such as a scenario if Dyn’s Managed DNS is primary and another provider is secondary). Additionally, you can create cut-nodes within your zone that allows you to delegate a subdomain to another zone or DNS provider by adding NS records on that subdomain. See RFC 1035 for more information on the (NS) record including information to complete the RData field in the Managed DNS Expert Editor.
Nameserver — Hostname of the authoritative Nameserver for the zone.
Add — Click to add the record to your zone.
(NSAP)
The Network Service Access Point (NSAP) record maps a domain name to an NSAP address. See RFC 1637 for more information on NSAP records including information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Digest — Enter the NSAP Address
Add — Click to add the record to your zone.
(PTR)
A pointer record (PTR) is used for reverse mapping an IP address to a hostname, which is the opposite of an A Record that is forward mapping a hostname to an IP address. PTR records are commonly found in Reverse DNS zones (in-addr.arpa for IPv4, ipv6.arpa for IPv6). See RFC 1035 for more information on (PTR) records including information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Pointer — Hostname where the IP address should be directed. For example, if you are creating a Reverse DNS record for your mail server, you would enter the mail server’s name (mail.example.com) here.
Add — Click to add the record to your zone.
(PX)
Resource record used for RFC822 to X.400 mapping. Please see RFC 822 and RFC 2163 for more information including information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Preference — Similar to the preference value for MX records. The lowest value (for example, 10) is preferred before a higher value (for example, 15)
RFC822 Host — Enter the domain name used in RFC 822 part of MCGAM
X.400 Mapping — Enter the domain name derived from the X.400 part of the MCGAM
Add — Click to add the record to your zone.
(RP)
The Responsible Person (RP) record contains information on how to contact the designated Responsible Person(s) for the zone as defined in RFC 1183. This RFC also includes information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Mailbox — Email address of the Responsible Person with the ‘@’ symbol replaced with a dot ‘.’ Example: mail.sample.com
Further Info at — Enter the hostname where there is a TXT Record with more information.
Here is an example of a RP record configuration take from RFC 1183:
sayshell.umd.edu. A 128.8.1.14
MX 10 sayshell.umd.edu.
...
RP louie.trantor.umd.edu. LAM1.people.umd.edu.
LAM1.people.umd.edu. TXT (
"Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
Add — Click to add the record to your zone.
(SOA)
The Start of Authority (SOA) record is automatically created by Managed DNS when you create a zone. It specifies authoritative information about a DNS zone, including the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone. See RFC 1035 and RFC 2308 for more information on the Start of Authority record. Most of the fields in the SOA record are set to a standard and are not editable.
Nameserver — The primary name server assigned by Managed DNS. Not editable.
Mailbox — The administrative mailbox for the zone. May be any stable and valid Email address.
Default TTL — The time to live (TTL) of this record on the DNS networks. Set by default to 1 hour. May be set anywhere from 30 seconds to 1 week.
Refresh — Set to 1 hour by default. Not editable.
The time, in seconds, a secondary DNS server waits before querying the primary DNS server’s SOA record to check for changes. When the refresh time expires, the secondary DNS server requests a copy of the current SOA record from the primary. The primary DNS server complies with this request. The secondary DNS server compares the serial number of the primary DNS server’s current SOA record and the serial number in it’s own SOA record. If they are different, the secondary DNS server will request a zone transfer from the primary DNS server.
Retry — Set to 10 minutes by default. Not editable.
The time, in seconds, a secondary server waits before retrying a failed zone transfer. Normally, the retry time is less than the refresh time.
Expire — Set to 1 week by default. Not editable.
The time, in seconds, that a secondary server will keep trying to complete a zone transfer. If this time expires prior to a successful zone transfer, the secondary server will expire its zone file. This means the secondary will stop answering queries, as it considers its data too old to be reliable.
Minimum — Set to the recommended value of 30 minutes by default. NOTE: Changing the minimum TTL may impact your QPS usage. Click Help next to the Minimum value field for additional information.
Defines the time in seconds that any name server or resolver should cache a negative response.
Serial Style — Set to Increment by default. Editable only during the creation of a new zone, when the SOA record is created. Serial Style can be set to date-based serial number, epoch, or an incremental serial number.
Serial — Set by default. Value increments when any resource record in the zone file is updated. Not editable.
The revision number of this zone file. Increment this number each time the zone file is changed. It is important to increment this value each time a change is made, so that the changes will be distributed to any secondary DNS servers.
Update — Click to update the record settings.
(SPF)
The Sender Policy Framework (SPF) record is a special TXT record used to store the framework data. See RFC 4408 for more information on the Sender Policy Framework including information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Data — Free text box.
Here is an Example of a simple SPF record:
v=spfl mx ptr -all
NOTE The following special characters must be escaped with a single \
; \ ”
Add — Click to add the record to your zone.
(SRV)
The SRV record allows administrators to use several servers for a single domain. This is useful for load-balancing and backup scenarios. See RFC 2782 for more information about the SRV record.
For the Expert Editor, you must format the RData value as follows: Priority Weight Port Target (for example, 1 0 9 server.example.com).
Priority — Numeric value for priority usage. Lower value takes precedence over high value where two records of the same type exist on the zone/node.
Weight — Secondary prioritizing of records to serve. Records of equal Priority should be served based on their weight. Higher values are served more often.
Port — Indicates the port number where the service is running.
Target — The domain name of a host where the service is running on the specified Port. Must be the CNAME (canonical name) of the host and NOT be an alias.
(SSHFP)
The SSH Key Fingerprint (SSHFP) is a resource record for publishing SSH public host key fingerprints using DNS. SSHFP is defined in RFC 4255, RFC 6594, and draft-moonesamy-sshfp-ed25519-02 which include information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Algorithm — Enter one of the following: 1(RSA), 2(DSS), 3(ECDSA) or 4(ED25519) for the algorithm you are using.
Fingerprint Type — Enter 1 (SHA-1)
Fingerprint — Enter SSH Key Fingerprint
Add — Click to add the record to your zone.
(TLSA)
The TLSA record is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a “TLSA certificate association”. TLSA is defined in RFC 6698 which includes information to complete the RData field in the Managed DNS Expert Editor. For the Expert Editor, the order of additional record information will follow the layout in Simple Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs. Value is entered in seconds.
Usage — Specifies the provided association that will be used to match the certificate presented in the TLS handshake. Example values: 0 (CA constraint), 1 (Service certificate constraint), 2 (Trust anchor assertion ), 3 (Domain-issued certificate)
Selector — Specifies which part of the TLS certificate presented by the server will be matched against the association data. Example values: 0 (Full certificate), 1 (SubjectPublicKeyInfo)
Match Type — Specifies how the certificate association is presented. Example values: 0 (No hash used), 1 (SHA-256), 2 (SHA-512)
Certificate – Full certificate or its SubjectPublicKeyInfo, or hash based on the matching type.
Add — Click to add the record to your zone.
(TXT)
Used to hold descriptive, human readable text. May also include non-human readable content for specific uses. It is commonly used for Sender Policy Framework (SPF) records and Domain Key (DKIM) records that do require non-human readable text items. See RFC 1035 for more information on TXT records including information to complete the RData field in the Managed DNS Expert Editor.
TTL — Time to Live recommended value is 1 hour. You may need more or less time based on your network’s needs.
Data — Free text box. The content can be any text. For example: This is the sample text record.
Note: The underline effect is only here to show the TXT record content. You do not underline the text in the TXT record.
Here is another example, it is a sample SPF record:
v=spfl mx ptr -all
Add — Click to add the record to your zone.