Tag: DNS record

CNAME record

A CNAME record lets one DNS name act as an alias for another name. It is useful when several hostnames should follow a service whose destination may change, but it has strict rules that distinguish it from an A or AAAA record. Misusing those rules can break a website, mail delivery, domain verification, or an entire DNS name.

This guide explains how CNAME resolution works, where aliases fit well, why they normally cannot be used at a zone apex, and how to test a configuration before relying on it in production.

What is a CNAME record?

CNAME means Canonical Name. The record identifies its owner name as an alias and points that alias to a canonical target name. For example, an administrator might make www.example.com an alias of web.example.net. The target is a hostname, not an IP address.

When a resolver asks for an address for the alias, it receives the CNAME relationship and continues resolution at the target name. The target may then provide an A record, an AAAA record, another CNAME, or other data relevant to the original query. The alias does not copy the target’s records into the source zone; it tells the resolver where to continue.

If the overall lookup process is unfamiliar, Domain Name System Explained describes how clients, recursive resolvers, and authoritative servers work together.

CNAME compared with A and AAAA records

An A record maps a name directly to an IPv4 address, while an AAAA record maps it to an IPv6 address. A CNAME maps one name to another name. The distinction determines who controls the final address.

  • Use A or AAAA when you control the destination address and want the name to resolve directly.
  • Use CNAME when the destination is identified by a hostname and the operator of that hostname may change its addresses.

The existing article DNS A Record Explained covers direct IPv4 mapping in more detail. For a wider comparison of common record types, see the ClouDNS guide to DNS records. This contextual external reference appears in the first half of the article.

How CNAME resolution works

Assume the DNS zone contains this conceptual relationship:

www.example.com.  CNAME  web.example.net.

A client requesting the A record for www.example.com typically follows these steps:

  1. The client sends a query to its recursive resolver.
  2. The resolver finds that www.example.com is an alias.
  3. It continues the lookup for web.example.net.
  4. The authoritative data for the target returns an address or another answer.
  5. The resolver returns the CNAME path and relevant final data to the client, subject to caching and response-size limits.

The alias and target can be in the same DNS zone or in completely different zones. Each zone remains responsible for its own records, availability, TTL values, and DNSSEC signatures.

Good uses for a CNAME

A www hostname

A common design makes www an alias of a web platform or another hostname managed by the same organization. This lets the target’s address change without editing the alias record each time.

Third-party platforms

Cloud applications, content delivery platforms, hosted storefronts, help desks, and software-as-a-service products often provide a target hostname. A customer connects a subdomain such as shop, help, or status through a CNAME while the provider manages the final infrastructure addresses.

Service migration

An alias can separate the public hostname from an internal service name. During a planned migration, administrators can change the canonical destination while applications continue using the familiar alias. Caching still matters, so the change is not necessarily immediate.

The most important rule: no other data at the alias name

A DNS name that owns a CNAME record generally cannot own other record data. In practical terms, do not place A, AAAA, MX, TXT, or unrelated records at the same label as a CNAME. DNSSEC-related records required to secure the CNAME are a protocol-specific exception.

This exclusivity prevents contradictory answers. A name cannot simultaneously say “continue at this canonical name” and independently publish address, mail, or verification data. Many control panels reject the conflict; inconsistent servers or cached data may otherwise produce unreliable results.

Why a traditional CNAME does not fit at the zone apex

The zone apex is the bare domain, such as example.com. It must contain the zone’s SOA and NS records and often has MX, TXT, and other records. Because a CNAME cannot coexist with that required data, a standard CNAME cannot replace the apex.

Some DNS providers offer records called ALIAS, ANAME, flattened CNAME, or similar names. These are provider-specific features rather than ordinary CNAME records. The authoritative service follows the target and synthesizes compatible address answers at the apex. Behavior, TTL handling, DNSSEC support, IPv6 handling, and failure modes differ, so check the provider’s exact documentation before using one.

CNAME and email configuration

An MX record names the mail server responsible for a domain. Its target should resolve directly through address records rather than depend on a CNAME alias. Use a dedicated hostname with A and, when applicable, AAAA records for the mail exchanger.

Do not place a CNAME at a label that also needs MX or TXT data. This is especially relevant when the same name must publish SPF, DKIM, DMARC, verification, or other email-related information. The article DNS MX Record Explained describes the mail-routing role separately.

A CNAME is not an HTTP redirect

DNS aliasing happens before a browser makes an HTTP request. A CNAME does not change the address displayed in the browser, redirect one URL path to another, or automatically configure the destination web server for the alias hostname.

The target service must still recognize the requested hostname and present an appropriate TLS certificate. If the server is not configured for the alias, visitors may see a certificate error, a platform error, or the wrong site even though DNS resolution succeeds.

TTL and caching behavior

The CNAME record has its own TTL, and the final A or AAAA record has another. Resolvers may cache each part of the chain independently. Changing the alias target does not purge records already cached under the previous TTL.

Before a planned migration, reduce the relevant TTL early enough for older cached data to expire. After the move is stable, raise the TTL again to reduce unnecessary queries. Remember that the target operator controls the TTL of the final address records.

Avoid long chains and loops

A target may itself be a CNAME, forming a chain. Short chains can work, but every additional dependency may require another lookup and introduces another place where configuration or availability can fail. Long chains also increase the chance that a resolver reaches an implementation limit.

A loop occurs when aliases eventually point back to a name already visited—for example, one name points to a second and the second points to the first. No final answer exists, so resolution fails. Review the complete path whenever changing an alias.

Security risk: dangling aliases

A dangling CNAME remains in DNS after the referenced cloud, hosting, or software-as-a-service resource has been removed. If another party can claim that abandoned target, they may be able to serve content under the organization’s subdomain. This is commonly called subdomain takeover.

Maintain an inventory of third-party aliases, identify an owner for every integration, and remove DNS records promptly when a service is retired. Before deleting the external resource, determine whether the provider requires the DNS mapping to be removed first. Monitor important aliases for unexpected target or response changes.

DNSSEC and CNAME records

DNSSEC can authenticate the CNAME data in a signed source zone. Resolution may then cross into another zone with its own signing status. A validating resolver evaluates each applicable chain of trust; signing the alias zone does not automatically sign or control the target zone.

DNSSEC confirms that signed DNS data has not been altered in transit. It does not prove that the chosen canonical target is operational, correctly configured for the website, or still owned by the intended provider.

How to configure a CNAME safely

  1. Choose the alias label. Use a subdomain that does not need other DNS record types.
  2. Confirm the exact target. Copy the hostname supplied by the service and never enter an IP address as CNAME data.
  3. Check name formatting. In raw zone files, a trailing dot marks a fully qualified target. Control panels often add it automatically, but behavior varies.
  4. Review existing records. Remove or migrate conflicting A, AAAA, MX, TXT, or other data at the alias owner.
  5. Select a sensible TTL. Use a shorter value during a controlled migration and a stable value afterward.
  6. Configure the destination service. Add the alias hostname to the web platform and provision a valid TLS certificate.
  7. Test from multiple resolvers. Confirm both the CNAME relationship and the final address response.
  8. Document ownership. Record who owns the DNS entry and the external resource so it is removed safely during decommissioning.

How to test and troubleshoot

Query the alias explicitly and then query the final record type:

dig CNAME www.example.com
dig A www.example.com
dig AAAA www.example.com

Check the authoritative servers when recursive caches may contain old data. Follow the complete target chain and compare TTL values. If DNS works but the website does not, test TLS certificate coverage, virtual-host configuration, HTTP responses, and the third-party platform’s domain-verification status.

The protocol rule that a CNAME owner must not contain other data, along with requirements for MX and NS targets, is clarified in RFC 2181: Clarifications to the DNS Specification.

Common mistakes checklist

  • Entering an IP address instead of a hostname as the CNAME target.
  • Adding a CNAME where A, AAAA, MX, TXT, or other records already exist.
  • Trying to use a standard CNAME at the zone apex.
  • Assuming DNS aliasing performs an HTTP redirect.
  • Creating a long chain or an alias loop.
  • Changing DNS without configuring the destination platform and certificate.
  • Leaving a third-party alias behind after deleting the associated resource.
  • Testing only through one recursive resolver and overlooking cached data.

Conclusion

A CNAME record is a clean way to make one DNS name follow another, especially for subdomains connected to managed platforms. Its simplicity depends on respecting strict boundaries: the target must be a hostname, the alias cannot carry unrelated data, the apex needs a different solution, and every dependency must remain controlled. Keep chains short, plan TTL changes, configure the destination service, test the full resolution path, and remove obsolete aliases promptly.

CAA DNS record

A TLS certificate helps a browser authenticate a website and establish an encrypted HTTPS connection. Before issuing one, a certificate authority validates control of the requested domain. A Certification Authority Authorization record adds a DNS-based policy layer: it lets the domain owner state which certificate authorities are permitted to issue certificates for that name.

CAA does not replace domain validation or prevent every form of certificate abuse. Its purpose is narrower and useful: reduce the set of certificate authorities that may issue, express separate policy for wildcard certificates, and optionally publish an incident-reporting contact. Correct deployment requires an inventory of every legitimate certificate workflow, careful DNS syntax, and verification before relying on enforcement.

What is a CAA DNS record?

CAA is a DNS resource-record type. A record contains flags, a property tag, and a property value. Certificate authorities are expected to check the relevant CAA policy before issuing a publicly trusted certificate. If an applicable policy authorizes the CA, issuance may continue after the CA’s normal validation. If the policy does not authorize it, the CA should not issue.

If no applicable CAA record exists, CAA itself does not restrict which certificate authority may issue. The absence of CAA is therefore different from an explicit restrictive policy.

For a refresher on where records fit in resolution, see Domain Name System explained. A focused setup reference is also available in the ClouDNS CAA record guide. Because it points to the ClouDNS domain, this contextual reference appears in the first half of the article.

The three commonly used CAA property tags

issue: authorize normal certificate issuance

The issue tag authorizes a certificate authority for certificates that are not wildcard certificates. A basic zone-file example is:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"

The value identifies the certificate authority according to its documented CAA issuer-domain name. Do not guess this value from the CA’s marketing name or website hostname. Obtain the exact identifier and any required parameters from the certificate authority’s current documentation.

Multiple issue records can authorize more than one CA. This is useful when production, disaster recovery, a CDN, and a managed hosting provider legitimately use different issuers. Every authorized issuer expands the policy, so keep the list intentional.

issuewild: control wildcard certificates separately

The issuewild tag applies to wildcard certificate requests. For example:

example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

If an applicable issuewild property is present, it governs wildcard issuance instead of issue. This allows a domain owner to permit one CA for ordinary certificates and a different CA for wildcard certificates.

An empty issuer value can explicitly prohibit the relevant category. A policy such as CAA 0 issuewild ";" can be used to deny wildcard issuance while still authorizing selected CAs for ordinary certificates. Verify how your DNS provider expects quotes and record fields to be entered before publishing.

iodef: publish an incident-reporting contact

The iodef tag provides a URL that a certificate authority may use to report policy violations or related issues. A mail-based example can point to a dedicated security mailbox:

example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

Publishing iodef does not guarantee that every CA will send a report. The destination should be monitored, protected from abuse, and incorporated into the organization’s incident-response process.

How CAA lookup and inheritance work

A CA starts with the domain name in the certificate request and follows the standardized CAA processing rules, including alias handling and tree climbing when the requested name has no CAA policy of its own. A policy found higher in the DNS hierarchy can therefore apply to subdomains that do not publish a more specific applicable record.

This inheritance is convenient, but it makes testing essential. An organization may operate delegated subdomains, external platforms, or independently managed business units with different certificate workflows. Inventory those boundaries before placing a restrictive policy at a parent name.

CAA records are their own resource-record type. They are not TXT records, even though their values contain text-like strings. The article TXT record – why to use it? covers the separate TXT type and its common verification and email-security uses.

What the flags field means

The first number in a CAA record is an eight-bit flags field. Most records use 0. The issuer-critical bit has value 128. When it is set, a CA that does not understand the property tag must treat the property as critical and refuse issuance rather than ignore it.

Do not set the critical flag casually or invent private tags without testing. A typo combined with critical processing can block legitimate issuance. For the standard issue, issuewild, and iodef properties, a flag value of 0 is the conventional starting point unless a documented requirement says otherwise.

A safe CAA deployment process

1. Inventory every certificate issuer

List certificates used by web servers, load balancers, CDNs, cloud platforms, hosting control panels, mail systems, APIs, device-management platforms, and disaster-recovery environments. Identify both the visible service provider and the actual certificate authority it uses.

2. Review automated renewal

Check ACME clients, hosting automation, CDN-managed certificates, and provider-specific issuance workflows. A certificate that works today may renew through a different account or issuer path. Test the complete renewal process rather than checking only the current certificate.

3. Publish the minimum required authorizations

Add only the issuer-domain values required by approved workflows. Decide explicitly whether wildcard certificates are allowed and which CA may issue them. Avoid copying a long generic list from another domain.

4. Verify from authoritative and recursive DNS

Query the record directly from authoritative servers and through multiple recursive resolvers:

dig example.com CAA
dig example.com CAA @ns1.example.net

Confirm the expected flags, tags, values, TTL, and inheritance at relevant subdomains. If DNSSEC is enabled, also ensure the signed response validates correctly.

5. Test issuance and renewal before enforcement matters

Use a non-critical certificate or staging environment where possible. Confirm that each approved CA can issue or renew and that an unapproved path is denied. Keep an emergency procedure for updating CAA when a provider changes its issuer.

Common mistakes

  • Authorizing the wrong issuer-domain name: Use the identifier published by the CA, not an assumed company domain.
  • Forgetting a managed platform: CDNs, hosting providers, and SaaS products may obtain certificates automatically.
  • Ignoring wildcard policy: Decide deliberately whether issuewild should authorize or prohibit wildcard issuance.
  • Publishing malformed syntax: Quotes, semicolons, parameters, and provider-specific form fields require careful entry.
  • Expecting immediate universal visibility: Existing caches can retain the previous CAA set until its TTL expires.
  • Assuming CAA protects existing certificates: CAA is checked during issuance; it does not revoke certificates already issued.

CAA and DNSSEC solve different problems

CAA expresses authorization policy, while DNSSEC allows validating resolvers to detect forged or altered DNS data. Publishing CAA without DNSSEC can still restrict compliant certificate authorities, but DNSSEC adds origin authentication and integrity protection for signed DNS responses.

The guide DNSSEC Explained describes that chain of trust. Neither technology replaces account security at the registrar, DNS provider, hosting platform, or certificate authority.

What CAA does not do

CAA does not create HTTPS, validate control of the domain, encrypt traffic, or select which certificate visitors receive. It does not prevent compromise of an authorized CA account, DNS account, web server, or private key. It also does not revoke an unwanted certificate.

Use CAA alongside secure DNS administration, multi-factor authentication, DNSSEC where appropriate, certificate transparency monitoring, protected private keys, automated renewal monitoring, and a documented incident-response process.

The authoritative processing rules, property definitions, and security considerations are specified in RFC 8659: DNS Certification Authority Authorization.

Conclusion

A CAA DNS record narrows which certificate authorities may issue certificates for a domain. A reliable policy begins with a complete issuer inventory, uses correct issue and issuewild values, accounts for inherited policy, and is tested against every automated renewal path. CAA is most effective as one layer in a broader certificate and DNS security program.

DNSSEC

The Domain Name System is one of the Internet’s essential services. It translates familiar domain names into the IP addresses that computers use to communicate. That convenience also creates an important security question: how can a resolver know that the DNS answer it received is authentic and has not been replaced in transit?

DNS Security Extensions, usually called DNSSEC, address that problem with digital signatures. DNSSEC allows a validating resolver to verify where DNS data came from and whether it changed after the authoritative zone signed it. It strengthens trust in DNS without replacing the DNS protocol or encrypting ordinary DNS queries.

What problem does DNSSEC solve?

Traditional DNS was designed for availability and speed, not for cryptographic verification. A resolver can ask an authoritative server for a record, but the basic protocol does not prove that the response is genuine. An attacker who succeeds in inserting a forged answer could direct visitors to an unintended server even when they typed the correct domain name.

This risk is easier to understand after reviewing how the Domain Name System resolves a name. DNSSEC adds verifiable signatures to that process. A validating resolver can reject a forged or altered response instead of treating it as legitimate DNS data.

How DNSSEC creates a chain of trust

DNSSEC does not rely on one universal key for every domain. It creates a chain of trust that begins at the DNS root and continues through the top-level domain to the signed domain. Each level can securely point to the key used by the level below it.

DNSKEY records publish public keys

A signed zone publishes its public keys in DNSKEY records. The corresponding private keys remain protected by the zone operator and are used to sign groups of DNS records. Keeping the private key secure is critical because anyone who obtains it may be able to produce signatures that appear valid.

RRSIG records contain digital signatures

For each signed record set, the authoritative zone supplies an RRSIG record. A validating resolver uses the appropriate DNSKEY to check that signature. Successful validation confirms both the origin of the data and its integrity: the response was signed by the expected zone and was not modified after signing.

DS records connect parent and child zones

A DS record in the parent zone contains a digest associated with a key in the child zone. For example, a registrar can publish a domain’s DS information in the relevant top-level-domain zone. The resolver follows these references from a previously trusted level, building a verifiable path to the final answer.

NSEC and NSEC3 authenticate negative answers

DNSSEC must also prove when a requested name or record does not exist. NSEC and NSEC3 records provide authenticated denial of existence. This prevents an attacker from simply returning an unsigned “not found” response for valid signed data.

What DNSSEC protects—and what it does not

DNSSEC provides DNS data origin authentication, integrity protection, and authenticated denial of existence. These controls help defend against forged DNS answers and cache-poisoning scenarios when validation is performed correctly.

However, DNSSEC does not encrypt DNS traffic. Anyone able to observe an unencrypted DNS query may still see the requested name. DNSSEC also does not secure a vulnerable website, repair an infected server, prevent every distributed denial-of-service attack, or protect a registrar account with a weak password. HTTPS, access controls, monitoring, backups, and secure account practices remain necessary.

Why deployment has two important sides

DNSSEC works only when zone signing and validation connect correctly.

  • Authoritative side: The domain owner or DNS provider signs the zone, publishes DNSKEY and signature records, and keeps the signatures current.
  • Parent-side delegation: The correct DS record is published through the registrar or registry so the parent can establish trust in the child zone.
  • Resolver side: A validating recursive resolver checks the signatures and the chain of trust before returning an answer to the client.

If a signed zone changes its keys without updating the parent DS information correctly, validating users may receive failures even though the records look normal to a non-validating resolver. Careful key rollover and monitoring are therefore part of operating DNSSEC, not optional housekeeping.

A practical DNSSEC deployment checklist

  1. Confirm support. Check that the authoritative DNS provider, registrar, and top-level domain all support the required DNSSEC workflow.
  2. Review current DNS data. Make sure the zone is accurate before signing it. DNSSEC can authenticate incorrect data just as effectively as correct data.
  3. Enable zone signing. Generate or activate the signing keys through the authoritative DNS service and confirm that DNSKEY and RRSIG records appear.
  4. Publish the DS record. Submit the exact DS values through the registrar. A mismatch can break validation for the domain.
  5. Test from validating resolvers. Confirm the complete chain of trust, not merely the presence of DNSSEC records.
  6. Monitor signatures and rollovers. Watch expiration dates, DS consistency, and planned key changes. Include DNSSEC checks in routine DNS monitoring.

Reliable authoritative infrastructure still matters after a zone is signed. Features such as redundant servers, anycast distribution, monitoring, and failover address availability rather than authenticity. The distinction is similar to the operational benefits discussed in the guide to Premium DNS: security and resilience are strongest when several complementary controls work together.

DNSSEC is a trust layer, not a complete security stack

A successful DNSSEC deployment gives validating resolvers cryptographic evidence that DNS data is authentic. It reduces an important class of DNS manipulation risk, but it should be combined with HTTPS, secure registrar access, multi-factor authentication, protected signing keys, monitored DNS changes, and resilient authoritative service.

For a practical overview of the technology, see DNSSEC, the DNS Security extension. The protocol’s security model and requirements are defined in RFC 4033: DNS Security Introduction and Requirements.

TXT record

Domain Name System (DNS) includes many different records to execute different functions required for the Internet to work as easily and efficiently as users expect.

TXT records’ functionality is absolutely essential. Check out why to use TXT record.

What is the TXT record?

Text or TXT record is a DNS record that holds text information related to a domain for external sources to read it. TXT records commonly have general information about a domain and important data frequently used for validating (security processes). They can validate information for e-mailing or for confirming if you really are the owner of a domain.

When created, the TXT record was for administrators’ notes. But machines have evolved through the years, and such text notes are also legible for them. This is very convenient for administrators because using TXT records, they can send text entries into the DNS, with specific instructions for machines to accomplish.

Do you know how to prevent your emails from going to spam? Check how DNS TXT record can help you!

(more…)

DNS A record

Understanding DNS record is easy. The only thing that you need a simple explanation. We will see what a DNS record is, and we will start speaking about one of the most used ones – DNS A record. It is the simple record that connects what you are typing in your web browser and the address of the site, but let’ go in-depth. 

In the following page you can find in-depth information about the A record!

DNS and DNS records explained

We will not go into detail, but we should really define what DNS and DNS records are before we go to the topic of DNS A records. 

(more…)

DNS MX record

We just started to chat about DNS records with the DNS A Records, and now we will see a second DNS record – DNS MX record. MX does not mean Mexican. It means Mail Exchanger. We will go into details about why such a DNS record must exist and why can’t we freely send emails the way we want. 

Check this page if you need additional information about the DNS MX record!

What is a DNS MX record?

Every action that relates to domains needs DNS records for instruction. In the DNS MX record case, it is a text document, mail exchanger record, that shows which server is responsible for receiving the emails that go for a particular domain. 

(more…)

Cloud DNS

So are you interested in boosting your site performance with the power of Cloud DNS service? You probably have plenty of doubts, but don’t worry. Here we will speak about Cloud DNS in an easy way, and we will answer your doubts in a breeze.  

DNS in short

DNS or domain name system is how the Internet is organized. Each host has its IP address and services that it uses. To access it and use those services, you will need to find it. The DNS is an international network of name servers that helps you navigate. It will translate your requests from words that you understand or commands on software to the language that the servers speak.

It is one communication level that we use without even knowing it!

DNS uses DNS records. Those are simple text messages with descriptions and instructions that servers understand. They link services, servers, and hosts. Thanks to those records, you don’t need to remember the IP addresses of sites you want to visit. You simply type the domain names in your browser, and you visit the site!

Cloud DNS

(more…)