Skip to content

Cloud accounts, prepared and documented for technical teams

Prices in USD
OldCloudShop
TelegramWhatsApp
Providers Google Cloud$55AWS$20Kamatera$30Azure$25DigitalOcean$25Oracle Cloud$45OVHcloud$30Hetzner$50Linode$25UpCloud$30
Networking

DNS Basics for Cloud-Hosted Applications

Record types, TTL and propagation explained in the terms that matter when you are pointing a domain at a cloud server.

Networking and Storage2 min read

NETWORKING AND STORAGE

DNS is where a surprising share of deployment problems live, usually because a change was made correctly and then judged too early.

The records you will actually use

  • A — points a name at an IPv4 address.
  • AAAA — points a name at an IPv6 address.
  • CNAME — points a name at another name. Cannot coexist with other records at the same name, which is why it does not belong at the root of a domain.
  • MX — names the servers that receive mail for the domain.
  • TXT — arbitrary text, used for domain verification and for mail authentication such as SPF and DMARC.
  • NS — delegates a zone to a set of nameservers.

TTL and why changes feel slow

Every record carries a time-to-live telling resolvers how long they may cache the answer. If the TTL is 24 hours, a resolver that answered a query an hour ago will keep giving the old answer for another 23.

This is the entire explanation for propagation. Nothing is spreading; caches are expiring.

The practical technique is to lower the TTL to a few minutes at least one full old-TTL period before a planned change. Then the switch takes minutes. Raise it again afterwards, since very low TTLs mean more lookups.

Pointing a domain at a cloud server

  1. Reserve a static address so it survives the machine being rebuilt. See cloud networking basics.
  2. Create an A record for the root pointing at that address.
  3. Create a CNAME for www pointing at the root name, or a second A record.
  4. Wait for the old TTL to expire before concluding anything is wrong.

Records mail depends on

If the domain sends mail, three TXT-based mechanisms matter: SPF listing permitted senders, DKIM publishing a signing key, and DMARC stating a policy. Reverse DNS on the sending address is configured at the provider rather than in your zone. Context is in port 25 and outbound mail.

Where to host the zone

Registrar, cloud provider or a dedicated DNS service all work. What matters more is knowing which one is authoritative. Zones edited in two places, with one quietly ignored, are a recurring source of confusion on inherited environments.

Check the NS records to confirm which nameservers are actually in charge before editing anything.

Cloud accounts on OldCloudShop

Ten providers, every configuration and the starting price for each.

Browse cloud accountsBack to the library

Question about a listing? Message us on Telegram or WhatsApp.

TelegramWhatsApp

Continue in the library

Other entries covering account structure, billing, security and provider infrastructure.

CreditsHow Cloud Credits Are Applied, and What They Never CoverCredit is not cash. It applies to eligible services, expires on a date, and is consumed silently. Those three properties explain most credit surprises.ComputeSnapshots, Images and a Rebuild StrategySnapshots restore a machine. Images create new ones. Knowing which you need decides whether recovery takes minutes or hours.FundamentalsHow Cloud Billing Models WorkOn-demand, committed, spot and promotional balances behave differently. Knowing which one is paying for a resource explains most unexpected invoices.AzureAzure Subscriptions, Tenants and Pay-As-You-GoAzure layers a directory, a subscription and resource groups. Knowing which layer holds identity, which holds billing and which holds resources prevents most confusion.ReferenceA Plain-English Glossary of Cloud Infrastructure TermsShort, practical definitions of the terms that appear constantly in provider consoles and account listings, with the distinctions that actually matter.PlanningCloud Planning for Early-Stage TeamsEarly infrastructure decisions are mostly about preserving optionality cheaply. Most early-stage teams need far less than they expect.
TelegramWhatsApp