DNS and Hosting for Developers: A Practical Guide to Records, TLS, and Deployment Routing

Overview

A domain name is a human-readable address; DNS translates that address into the information clients need to reach a service. Hosting provides the application, static files, API, or edge endpoint. TLS protects the connection and proves that a certificate is valid for the requested hostname. Routing determines which deployment receives the request after DNS resolution and certificate validation succeed.

These layers are connected, but changing one does not automatically fix another. A correct CNAME record cannot compensate for a hosting platform that has not been configured to accept the hostname. A valid certificate does not guarantee that the application is listening on the expected path. Likewise, DNS can resolve correctly while an HTTP redirect, firewall rule, or origin configuration still causes an error.

Before making changes, record the current DNS zone, hosting target, certificate names, redirect rules, and intended owner for each component. Keep this information in version control or another reviewed system where practical. For background on individual record types, see DNS Record Types Explained for Developers.

DNS record reference

The exact record values and supported apex-domain configuration vary by provider. Treat the hosting platform's domain setup screen and your DNS provider's documentation as the source of truth for those values, while using this guide to organize the work.

Checklist by scenario

New production site

• Confirm the registrar, authoritative DNS provider, hosting account, and technical owner.
• Add the production domain to the hosting platform before changing public DNS, if the platform requires domain verification.
• Choose the intended canonical hostname, such as example.com or www.example.com.
• Configure the required A, AAAA, or CNAME records. Avoid adding alternatives “just in case.”
• Leave unrelated records, especially MX and existing TXT records, unchanged.
• Enable or request certificates for every hostname that will serve traffic.
• Configure one canonical redirect direction between the apex and www, and test both HTTP and HTTPS.
• Verify the application, static assets, API paths, robots directives, and health endpoint after DNS becomes visible.

Environment subdomains

A predictable naming scheme makes deployments and access reviews easier. A practical template is:

• example.com — production web application
• www.example.com — canonical web alias, if used
• api.example.com — production API
• staging.example.com — shared pre-release environment
• pr-123.staging.example.com — temporary preview deployment
• admin.example.com — administrative interface, if it must be separately routed

For each subdomain, document its DNS target, hosting project, certificate coverage, authentication requirements, data boundary, and removal process. Staging should not become publicly discoverable or share production credentials merely because it uses a familiar hostname. Coordinate this work with your secrets process; the DevSecOps secrets management guide covers separation and rotation considerations.

Migration to a new host or edge provider

1. Lower the relevant TTL ahead of the change if your operational plan requires faster correction. A lower TTL does not instantly clear caches already holding an older response.
2. Build and test the site on the new host using a provider preview URL, hosts-file override, or another private validation method.
3. Add the domain to the new platform and complete verification before switching traffic.
4. Issue and validate certificates on the new path, including redirects and alternate hostnames.
5. Copy required DNS records, but review each one rather than importing the zone blindly.
6. Change only the records needed to direct web traffic, then monitor responses from more than one network.
7. Keep the old host available until cached DNS responses have aged out and application checks are clean.
8. Restore the normal TTL and remove obsolete records, certificates, access tokens, and origin permissions after the migration is accepted.

For the deployment side of a migration, pair this runbook with the CI/CD pipeline troubleshooting checklist so infrastructure and release failures are not mixed together.

Verification commands

Run checks from a workstation or CI job with network access. Replace the example hostnames with your own:

dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com CNAME
dig +trace example.com
curl -I http://example.com
curl -I https://example.com
openssl s_client -connect example.com:443 -servername example.com 

Use dig to inspect answers and delegation, curl to inspect HTTP status and redirect behavior, and openssl to investigate the certificate presented for a specific hostname. A result from one resolver is not proof that every recursive resolver has the same cached answer.

What to double-check

• Nameservers: Confirm the registrar delegates the domain to the DNS provider where you are editing records. Editing a different provider's zone has no public effect.
• Zone scope: A record for staging.example.com is different from a record for example.com. Check the exact hostname and whether the interface appends the domain automatically.
• Apex behavior: The zone apex often cannot use a conventional CNAME in the same way as a subdomain. Use the hosting provider's supported apex method rather than improvising.
• IPv6: Test the AAAA path if one exists. Clients may prefer IPv6, exposing a stale server or missing firewall rule that IPv4 tests do not reveal.
• TLS coverage: Confirm the certificate includes every hostname users and integrations call. Also verify the server presents the correct certificate through SNI.
• Redirects: Check for loops between HTTP, HTTPS, apex, and www. Review both edge rules and application-level redirects.
• Origin routing: A reverse proxy may route by hostname, path, or header. Confirm that the expected host header reaches the intended service.
• Email continuity: Web migrations should not alter MX, SPF-related TXT, DKIM, or other mail records unless email is also being migrated.
• Monitoring: Add checks for DNS resolution, certificate expiry, HTTP status, redirect target, and a representative application path. Observability guidance can help connect these checks to incident response.

Common mistakes

Changing nameservers when only a record change is needed. Nameserver changes move authority for the whole zone and can affect mail, verification, and other services. Prefer an individual record update unless a full DNS-provider migration is intentional.

Deleting records to make the zone look tidy. Unknown TXT, MX, or CAA records may support services that are not visible in the web application. Identify an owner before removing them.

Assuming propagation is a single event. Recursive resolvers cache responses according to TTL and may serve different answers during a transition. Compare authoritative answers with several public resolvers and test from relevant user networks.

Testing only the homepage. A homepage can return 200 while assets, APIs, callbacks, uploads, or authentication endpoints fail. Test the paths used by browsers, deployment jobs, and integrations.

Using a production-looking staging hostname without access controls. Staging often contains debug features or test data. Require appropriate authentication, prevent accidental indexing where suitable, and keep its credentials and data separate.

Forgetting the certificate after changing the hostname. DNS can point correctly while browsers reject the connection because the new hostname is absent from the certificate or the platform has not completed validation.

When to revisit

Use this checklist before every new domain launch, environment creation, hosting migration, edge-provider change, or certificate workflow change. Revisit it during seasonal planning cycles when ownership, on-call coverage, or deployment architecture may change. It is also worth reviewing after a DNS incident, an unexpected certificate failure, an acquisition or domain transfer, or the introduction of a new preview-environment workflow.

Final launch checklist

1. Write down the intended hostname-to-service map.
2. Back up the current DNS zone and identify its authoritative nameservers.
3. Confirm records, certificates, redirects, and origin routing at the new destination.
4. Change the smallest possible set of DNS records.
5. Verify A, AAAA, CNAME, HTTP, HTTPS, certificate, redirect, and application behavior.
6. Check email and third-party verification records separately.
7. Monitor from multiple networks and keep the rollback path documented.
8. After the change is stable, restore normal TTL settings and remove obsolete access and routing configuration.

Keep the completed record map and verification output with the project documentation. That small habit turns DNS and hosting work from a one-off troubleshooting exercise into a repeatable engineering operation.