Skip to main content

DNS record types supported by Dotsync

Overview​

This article explains the DNS record types Dotsync supports and when to use each one. Use these plain-language notes to pick the right record for your site, mail, or verification needs.

Common record types​

  • A (IPv4 address)

    • What it does: Connects a name (for example example.com) to a server's IPv4 address so browsers and mail servers know where to reach your service.
    • Where you set it: Add an A record in the Dotsync dashboard (or your DNS provider) and enter the hostname and the server's IPv4 address.
    • When to use it: Use an A record when you have a server with an IPv4 address (web host, API, etc.) that should answer for the hostname.
    • How it behaves: When someone visits your domain, DNS returns this IP and their browser connects to the server at that address. If you change hosting, update the A record and allow time for DNS to propagate (TTL). Example: example.com. 300 IN A 198.51.100.42.

  • AAAA (IPv6 address)

    • What it does: Same as an A record but uses an IPv6 address instead of IPv4.
    • Where you set it: Add an AAAA record in Dotsync (or your DNS provider) with the hostname and the IPv6 address.
    • When to use it: Use AAAA when your server or hosting provider supports IPv6 so visitors on IPv6 networks can reach your site directly.
    • How it behaves: DNS returns the IPv6 address and clients with IPv6 will connect to that address. Example: www.example.com. 300 IN AAAA 2001:db8::1.

  • CNAME (canonical name)

    • What it does: Makes one hostname an alias of another hostname (e.g., blog.example.com becomes an alias for blogs.examplehost.com).
    • Where you set it: Create a CNAME record in Dotsync (or your DNS provider) pointing the alias name to the target hostname.
    • When to use it: Use CNAME for subdomains when you want them to follow another hostname (common with external services like hosted blogs or CDNs).
    • Important details: CNAMEs cannot be used at the root/apex (example.com) due to DNS rules; instead, use an ALIAS/ANAME or ALIAS-like feature. When the target hostname changes, the alias follows automatically, so you don't need to update the alias record.
    • Example: blog.example.com. 300 IN CNAME blogs.examplehost.com..

  • ALIAS / ANAME (apex-friendly alias)

    • What it does: Lets you point the root of your domain (for example example.com) to another hostname (like a CDN) even though CNAMEs aren't allowed at the apex.
    • Where you set it: Add an ALIAS/ANAME record in Dotsync for the root/apex or another name that must act like an alias.
    • When to use it: Use this when a service asks you to point your root domain at a hostname (for example, a hosted site or CDN) and you can't use a standard CNAME at the apex.
    • How it behaves: Dotsync resolves the target hostname and supplies real A/AAAA answers to DNS queries so the root behaves like a CNAME without breaking the DNS rules.

  • MX (mail exchanger)

    • What it does: Tells other mail servers where to deliver email addressed to your domain (for example, who handles email for @example.com).
    • Where you set it: Create MX records in the DNS zone for your domain in Dotsync or your DNS provider. Each MX record includes a priority (lower numbers are higher priority).
    • When to use it: Always set MX records if you want to receive email for your domain. If you're using Clearbox for mail, use the MX values provided in the Clearbox dashboard.
    • How it behaves: Sending servers look up MX records and try delivery in order of priority. Changing MX records moves mail delivery to the new servers once DNS propagation completes. Example: example.com. 300 IN MX 10 mail.clearbox.example..

  • TXT (text record)

    • What it does: Stores short pieces of text for verification and policy information that other services read.
    • Where you set it: Add a TXT record in Dotsync with the name and value given by the service that needs verification (e.g., _acme-challenge, _dmarc, or the root domain).
    • When to use it: Use TXT records to prove ownership of a domain, publish sender rules (SPF), publish DMARC policies, or complete certificate validation (ACME). Services will ask you to add a specific TXT value and then check for it.
    • How it behaves: After you add the TXT record, wait for DNS propagation and then the service can verify the value. Examples: SPF (v=spf1 include:dotsync.net -all), DMARC, and ACME challenge TXT values.

  • SRV (service locator)

    • What it does: Acts as a signpost telling clients which server and port to use for a particular service (for example, VoIP or messaging).
    • Where you set it: Add a specially named SRV record in Dotsync with the service name, priority, weight, port, and target host as instructed by the application.
    • When to use it: Only when an application or third-party service specifically asks you to create an SRV record (they're not needed for normal websites or email).
    • How it behaves: Applications that understand SRV records look them up and use the listed host and port to connect to the correct service. Example: _sip._tcp.example.com. 300 IN SRV 10 60 5060 sipserver.example.com..

  • NS (nameserver)

    • What it does: Says which nameserver computers are in charge of your domain's DNS records (who controls the "phone book" for your domain).
    • Where you set it: Nameserver (NS) entries are set at the registrar — when you register a domain with Clearbox/Dotsync the registrar will set NS records to Dotsync nameservers by default. To use another DNS provider you change the NS entries at the registrar to that provider's nameservers.
    • When to use it: NS records are used whenever you delegate a domain to a DNS provider; you rarely change them unless moving DNS providers. If you host nameservers on the same domain (e.g., ns1.example.com), you may also need glue records at the registrar.
    • How it behaves: NS records point resolvers to the authoritative servers that hold the actual A, MX, TXT records for your domain. Changing NS at the registrar delegates control to a different provider after propagation.

  • CAA (certificate authority authorization)

    • What it does: Lets you control which certificate authorities (CAs) are permitted to issue TLS/SSL certificates for your domain — a safety measure to prevent unexpected certificates.
    • Where you set it: Add a CAA record in your DNS zone in Dotsync with the CA you allow to issue certificates.
    • When to use it: Use CAA when you want to restrict certificate issuance to a specific CA (for example, to prefer Let's Encrypt or another CA) for better security control.
    • How it behaves: Certificate authorities check CAA records before issuing certificates; if the CA is not listed they should refuse to issue the certificate.

  • PTR (reverse DNS)

    • What it does: Maps an IP address back to a hostname (the reverse of an A/AAAA record) and is often used by mail servers and logging tools to confirm who owns an IP.
    • Where you set it: PTR records are normally managed by the owner of the IP address (your hosting or cloud provider or ISP), not in the Dotsync dashboard.
    • When to use it: If you run mail servers or host services that require readable reverse DNS, ask the IP owner/provider to set the PTR record to the correct hostname.
    • How it behaves: When a reverse lookup is performed on an IP, DNS returns the PTR hostname; some receiving mail servers verify PTRs as part of anti-spam checks.

Dotsync-specific notes​

  • ALIAS/flattening: Dotsync supports apex aliasing (ALIAS/ANAME) and CNAME flattening so you can point root domains to hostnames (CDN origins, managed services) without violating DNS rules. In plain terms: if a service asks you to point example.com at service.examplehost.com, use ALIAS so the root can act like an alias.

  • TTLs: TTL (time to live) controls how long other computers cache DNS answers. Use lower TTLs (e.g., 300s) when you expect to change records soon, and longer TTLs for stable records. Lower TTLs mean changes happen faster but increase DNS lookup traffic.

  • Automatic TLS/CDN: In Dotsync, when you add a hostname (A/AAAA/CNAME) you can turn on TLS to get an HTTPS certificate and CDN for caching. Dotsync will usually provision certificates automatically once DNS points correctly — follow the dashboard prompts if validation is required.

  • Verification & ACME: Some tasks (DKIM, verification, wildcard certificates) may ask you to add a specific TXT or CNAME record. The dashboard will give the exact name and value to paste; add it and wait for verification.

  • Email & MX: If your domain uses Clearbox for mail, make sure the MX records and related TXT records (SPF/DKIM/DMARC) are present at the DNS provider where the domain is delegated. If you register via Clearbox, Dotsync-managed DNS can publish these automatically for you.

Troubleshooting tips​

  • If certificates fail to provision, verify that the hostname resolves to the expected A/AAAA/CNAME and that _acme-challenge TXT records (if required) are present.
  • If mail is not delivered, check MX records and that SPF/DMARC records allow Clearbox's sending servers.
  • For delegation issues (NS records), use dig +trace example.com to inspect the chain of authority and verify glue records when hosting nameservers under the same domain.

Related: dns-management, ssl-and-cdn, nameservers, registering-a-domain