Skip to main content
Understanding DNS basics helps you configure domains correctly and troubleshoot issues faster. This guide covers the concepts most relevant to Entri integrations.

What Entri Does (and Doesn’t Do)

Entri is a platform that helps developers offer seamless domain experiences to their users.
ProductWhat it does
ConnectAutomates DNS configuration at the user’s existing provider
SellEnables in-app domain purchasing through partner registrars (IONOS, Squarespace)
SecureProvisions and manages SSL certificates
PowerPowers custom domains for SaaS applications
MonitorTracks DNS changes and alerts on issues
Key distinction: When users connect an existing domain through Entri Connect, we configure DNS records at their current provider. We don’t transfer domains or change where they’re registered.

The Domain Ecosystem

ServiceRoleExamples
Domain RegistrarSells and registers domain namesGoDaddy, Namecheap, IONOS
DNS ProviderHosts DNS records (often the registrar itself)Cloudflare, Route 53
EntriAutomates the configuration process

DNS Record Types

A Record

Points a domain to an IPv4 address.
example.com → 93.184.216.34
Use case: Pointing your root domain to a server.

AAAA Record

Points a domain to an IPv6 address.
example.com → 2606:2800:220:1:248:1893:25c8:1946
Use case: Same as A record, but for IPv6.

CNAME Record

Points a domain to another domain (an alias).
www.example.com → example.com
shop.example.com → myapp.herokuapp.com
Use case: Subdomains that should resolve to another hostname.
CNAME records cannot be used at the root domain (@) on most DNS providers. See CNAME at Root below.

MX Record

Directs email to mail servers.
example.com → mail.example.com (priority: 10)
Use case: Email delivery. Always requires a priority value.

TXT Record

Stores text data, commonly used for verification and email authentication.
example.com → "v=spf1 include:_spf.google.com ~all"
Use case: SPF, DKIM, DMARC, domain verification.

NS Record

Specifies which DNS servers are authoritative for the domain.
example.com → ns1.dnsprovider.com
Use case: Delegating DNS to a different provider. Rarely needed in typical Entri flows.

Root Domain vs Subdomain

TermExampleAlso called
Root domainexample.comApex domain, naked domain, @
Subdomainwww.example.com, shop.example.com
In DNS configuration:
  • @ or blank host = root domain
  • Any other value = subdomain

CNAME at Root: The Technical Limitation

Why it doesn’t work

The DNS specification (RFC 1034) states that if a CNAME record exists for a name, no other records can exist for that name. Since root domains typically need MX records (for email) and often TXT records (for verification), a CNAME at root would break email and other services.

What happens when you try

ProviderBehavior
Most providersReject the record or show an error
CloudflareAccepts it via “CNAME flattening” (see below)
Route 53Accepts it via “ALIAS” records

Solutions

Option 1: Use A records instead
dnsRecords: [
  { type: "A", host: "@", value: "93.184.216.34", ttl: 300 }
]
Option 2: Use a provider that supports CNAME flattening Some DNS providers work around this limitation using techniques like CNAME flattening, ALIAS records, or ANAME records. The provider resolves the CNAME to its final IP address and returns that as an A record. The user sees a CNAME in their DNS panel, but queries receive an A record response. Support varies by provider and may have restrictions (for example, some only support aliasing to their own resources). Use the checkDomain response to detect whether the user’s provider supports this:
const result = await entri.checkDomain("example.com", config);

if (result.cnameFlattening) {
  // Provider supports CNAME at root — safe to use CNAME records
}
Option 3: Use Entri Secure Entri Secure handles root domain configuration automatically by pointing A records to Entri’s servers, which then proxy traffic to your application.
{
  secureRootDomain: true,
  wwwRedirect: true,
  // ...
}

Detecting flattening support

The checkDomain response includes CNAME flattening information:
const result = await entri.checkDomain("example.com", config);

if (result.cnameFlattening) {
  // Provider supports CNAME at root
}

TTL (Time to Live)

TTL specifies how long DNS resolvers should cache a record before checking for updates.
TTLMeaningUse case
300 (5 min)Minimum recommendedDuring setup, when changes are expected
3600 (1 hour)StandardNormal operation
86400 (24 hours)Long cacheStable records that rarely change
Entri uses 300 seconds as the minimum TTL. Some providers enforce their own minimums and will override lower values.

DNS Propagation

After DNS changes, it takes time for the new records to be visible worldwide. This is called propagation. Typical propagation times:
  • Same DNS provider: Minutes
  • Across the internet: 15 minutes to 48 hours
What affects propagation:
  • Previous TTL value (old records stay cached until TTL expires)
  • Geographic location of DNS resolvers
  • Provider-specific delays
Checking propagation: Entri automatically monitors propagation and sends webhooks when records are fully propagated. You can also use external tools like whatsmydns.net.

Common Misconceptions

”Entri transferred my domain”

Entri Connect configures DNS records at your existing provider. It doesn’t transfer domains between registrars. If you purchased a domain through Entri Sell, that domain is registered with a partner registrar (like IONOS) and managed through their systems.

”I need to change my nameservers to use Entri”

Not required for most use cases. Entri works with your existing DNS provider. Nameserver changes are only needed if you’re delegating DNS to a different provider entirely.

”My DNS changes should be instant”

DNS propagation takes time. Even after Entri reports success, some users may not see changes immediately due to caching.

”CNAME and A records do the same thing”

They’re fundamentally different. A records point to IP addresses; CNAME records point to other domain names. This matters for root domains and for services that change IPs frequently.