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.
| Product | What it does |
|---|
| Connect | Automates DNS configuration at the user’s existing provider |
| Sell | Enables in-app domain purchasing through partner registrars (IONOS, Squarespace) |
| Secure | Provisions and manages SSL certificates |
| Power | Powers custom domains for SaaS applications |
| Monitor | Tracks 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
| Service | Role | Examples |
|---|
| Domain Registrar | Sells and registers domain names | GoDaddy, Namecheap, IONOS |
| DNS Provider | Hosts DNS records (often the registrar itself) | Cloudflare, Route 53 |
| Entri | Automates 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
| Term | Example | Also called |
|---|
| Root domain | example.com | Apex domain, naked domain, @ |
| Subdomain | www.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
| Provider | Behavior |
|---|
| Most providers | Reject the record or show an error |
| Cloudflare | Accepts it via “CNAME flattening” (see below) |
| Route 53 | Accepts 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.
| TTL | Meaning | Use case |
|---|
| 300 (5 min) | Minimum recommended | During setup, when changes are expected |
| 3600 (1 hour) | Standard | Normal operation |
| 86400 (24 hours) | Long cache | Stable 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.
Related Pages