DNS Records (A, CNAME, TXT)

Start with a name, not a website

You type https://www.example.com/products into a browser. DNS looks up the hostname www.example.com; it does not look up https:// or /products. After resolving the hostname to an address, the browser connects, checks HTTPS and requests the page. DNS can direct visitors to a service, but it does not upload your HTML, publish a deployment or create an HTTPS certificate by itself.

A domain registration, a DNS zone and a deployed website are separate things. Owning the name does not mean it already points to your project. Likewise, a correct DNS answer does not guarantee that the host is configured to serve your website under that name.

All records below are fictional practice data. example.com and the address 192.0.2.10 are reserved for documentation; they are not targets for your live website. For a real connection, copy the current records supplied by your deployment host. You can do the paper practice and the academy simulator without buying a domain; external domain registration may cost money.

Who answers the lookup?

1. Your browser or computer may already have a cached answer.
2. Otherwise it asks a recursive resolver, often provided by your network or a public DNS service. The resolver may also have a cached answer.
3. On a cache miss, the resolver follows DNS referrals: root nameservers → the relevant top-level domain, such as .com → the domain's authoritative nameservers.
4. The authoritative service answers from the domain's DNS records. The resolver caches the result and returns it to your computer.

The registrar manages the domain registration and its nameserver delegation. It is not contacted as a shop during every browser lookup. The DNS provider publishes the authoritative answers. These can be the same company, but if you delegated to another provider, editing records at the old registrar's DNS screen may have no effect.

Before editing real records, identify the active nameservers and the provider serving them. Do not change nameservers just because you cannot find the right screen: a move can interrupt website and email services unless the existing zone is preserved.

Read each field before choosing a type

Imagine the active zone is example.com:

In many dashboards, @ means the apex, example.com itself. Entering www creates www.example.com; entering app creates app.example.com. Those are separate names: setting the apex does not automatically configure www or every other subdomain.

Some providers expect a short relative name; others accept a full hostname. Check the preview of the resulting name so you do not accidentally create www.example.com.example.com. @ is a dashboard shorthand, not a character visitors type into the address bar.

A records: a name gets an IPv4 address

An A record answers with an IPv4 address: four numbers from 0 to 255 separated by dots. An AAAA record answers with an IPv6 address. Neither type takes a URL, a folder path or another hostname as its value.

Type: A
Name: @
Value: 192.0.2.10
TTL: 300

Read that aloud: “For the name example.com, publish the IPv4 address 192.0.2.10, cacheable for 300 seconds.” It does not configure www.example.com. A value like https://192.0.2.10/products is wrong because an A record needs only the IPv4 address. 300.1.2.3 is invalid because an octet exceeds 255.

Multiple A records can be intentional for a service, so do not delete extras blindly. But an old address accidentally left beside the new one can send some visitors to the old destination. If there is also an AAAA record, IPv6-capable visitors may use it: an outdated AAAA answer can cause failures even when the A record looks right. Match the host's requested configuration instead of inventing an address from a tutorial or a lookup.

CNAME records: one name aliases another

A CNAME says “this hostname is an alias of that hostname.” The resolver then looks up the target to find its address. It does not permanently copy the target's current IP into your zone.

Type: CNAME
Name: www
Target: demo.host.example
TTL: 300

The fictional lookup is www.example.com → demo.host.example → an A or AAAA answer. Use a hostname as the target, not 192.0.2.10 and not https://demo.host.example/. A DNS lookup may print a final dot, as in demo.host.example.; that dot marks an absolute DNS name. Follow your dashboard's expected input format.

A CNAME cannot coexist with ordinary A, AAAA or TXT records at the same name. A TXT record at _verify.example.com does not conflict with a CNAME at www.example.com because they are different names. Avoid alias loops such as www → app → www: neither name leads to an address.

The apex rule and provider exceptions

A standard CNAME cannot be used at the zone apex because the apex must also have other DNS records, including SOA and NS. For the academy exercise, use an A record at @ and a CNAME at www. Some providers offer ALIAS/ANAME records or CNAME flattening at the apex; these are provider-specific ways to produce address answers, not permission to put a standard CNAME anywhere. For a real website, follow the host's instructions and the DNS provider's supported method.

An alias is not a redirect

A CNAME does not change the address displayed in the browser. If www aliases another hostname, the visitor still requested www.example.com. The deployment host must recognise that hostname and have an appropriate HTTPS certificate. Redirecting www to the apex, or the apex to www, is a separate HTTP/hosting setting. DNS also cannot route /shop to one server and /blog to another: those are paths, not hostnames.

TXT records: publish exact text

A TXT record provides text for another service to read. A host may ask you to prove domain control by publishing a token at a particular name. Email systems also use TXT for purposes such as SPF and DKIM, but those records have their own formats; do not replace them with a website verification token.

Type: TXT
Name: _verify
Value: sf-verify=practice-only
TTL: 300

This publishes text at _verify.example.com. It does not point visitors at the website. Copy the requested name and entire value exactly, including prefixes, punctuation and case. Do not invent the real token or assume every host uses _verify. The academy simulator recognises the sf-verify= prefix; a real provider will supply its own name and token.

Lookup tools often display TXT strings inside quotation marks; that does not mean you should manually add quote characters in a dashboard. Follow the provider's field instructions. Several TXT records at one name can be legitimate; preserve unrelated records. A TXT verification token is intended to be publicly readable DNS data, not a place for API keys, passwords or private account credentials.

TTL: caching, not a countdown until success

With TTL 300, a resolver that fetched an answer at 10:00 may reuse it until about 10:05. If you change the record at 10:01, that resolver may still return its cached old answer for the remaining time. Other resolvers that have not cached it may already see the new answer.

Changing an existing TTL from 3600 to 300 does not shorten a copy that was already cached for 3600 seconds. Lowering TTL in advance can help a planned move; it cannot instantly flush everyone else's caches. Missing-name answers can also be cached, and nameserver changes have their own caches. “Propagation” is not a single switch that flips for the whole world at once.

Keep a stable correct record while checking. Repeatedly deleting and recreating it usually adds uncertainty rather than speeding anything up. A host may also need time to verify ownership and issue an HTTPS certificate after DNS is correct.

Worked practice: fill in three records

In a notebook or the academy DNS simulator, translate this fictional request into records:

• Send the apex to the IPv4 address 192.0.2.10.
• Make www an alias of demo.host.example.
• Publish sf-verify=practice-only at the apex to prove control.

The A row gives the apex its address; the CNAME row aliases www to the deployment name; the TXT row publishes ownership evidence at the apex. Each does a different job.

Notice that this request places TXT at @, whereas the earlier TXT example placed it at _verify. Both are valid locations in general; the requested name decides which is correct. A and TXT can coexist at the apex. A and CNAME cannot coexist at www. Explain each row before entering it, and record the previous values before editing a real zone.

Now diagnose these mistakes: an A target containing https://, a CNAME target containing an IPv4 address, a TXT token missing its prefix, and a Name field that creates www.example.com.example.com. For each, say which field is wrong and what kind of value it should contain. Do not “fix” a real zone with the fictional answers.

Read-only lookup practice on Windows and Mac

You can inspect public DNS without changing it. Use the same actual domain in each lookup, and remember that public sites may use different record types from our fictional exercise. example.com is safe for read-only practice, but it will not return the fictional records above.

On Windows, run these in PowerShell or the VS Code terminal:

nslookup -type=A example.com
nslookup -type=CNAME www.example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com

On Mac, use these in Terminal or the VS Code terminal:

dig example.com A
dig www.example.com CNAME
dig example.com TXT
dig example.com NS

In nslookup, the first “Server” and “Address” identify the resolver answering your question, not necessarily your website's address. Read the answer below that section. “Non-authoritative answer” commonly means you asked a recursive resolver; it is not automatically an error.

In dig's ANSWER SECTION, a typical A row has the shape example.com. 300 IN A 192.0.2.10: name, remaining TTL, class, type, value. That row is fictional, not the answer your command must produce. dig example.com A +short gives compact address output; omit +short when you need status and TTL. A TXT answer shows text, while a CNAME answer shows the alias target. No CNAME answer can simply mean the name uses A/AAAA instead.

NS answers help identify the authoritative nameservers. For deeper checking, dig @ns1.provider.example example.com A shows the form for asking a particular authoritative server directly; replace the fictional server with one returned by your domain's NS lookup. Do not confuse this @server command syntax with the apex shorthand in a DNS dashboard.

Diagnose the layer before editing

If your provider proxies web traffic, public A answers may be proxy addresses rather than the origin target you entered. Inspect the provider's configuration and follow the host's proxy guidance instead of overwriting records merely because a lookup differs. Avoid changing proxy settings on a working service without understanding the consequences.

Ready for the domain practical?

Before Quest 1.5, you should be able to choose A for IPv4, CNAME for a hostname alias and TXT for a verification string; explain @ versus www; and enter the simulator's requested values rather than a copied live service's values. The next lesson walks through connecting the deployment.

For a real connection, preserve unrelated MX, TXT, NS and other existing records, change only the requested website/verification entries, and check the host's confirmation. Test the apex and www separately in a browser after checking DNS, including any intended redirect and HTTPS. These practice steps strengthen your understanding; they do not add new unlock conditions or XP requirements.