DNS Helper

Interface

Every DNS panel shows you the same handful of ideas, a name, a type, a value, and a TTL, but hardly any two panels call them exactly the same thing. That's not a sign anyone is doing it wrong, it's just a lack of a shared convention. Pick your own panel below, and the example table underneath will use its actual field names.

The apex: empty field, @, or the domain itself

The apex is the domain on its own, with no subdomain in front of it, for example dnshelper.eu rather than www.dnshelper.eu. Different panels represent it in different ways, and all of them mean exactly the same thing:

• An empty name field, left blank on purpose.
• The single character @, the zone file's own shorthand for "this zone's own apex".
• The bare domain name typed out in full, repeated even though it's also the domain the record already belongs to.

One subdomain deserves a mention here too: www. It's a subdomain like any other, DNS doesn't treat that particular name any differently from mail or shop, but it's unusual in practice, because it's normally set up to point at exactly the same place as the apex itself. Most other subdomains exist precisely to point somewhere different from the apex, that's the whole reason to create them, www is the one that's expected to match it instead.

Documentation from large platforms, Google Workspace and Microsoft 365 among them, almost always writes the apex as @, simply because it's the one universal, panel-agnostic way to write it down. That doesn't mean your own panel actually accepts typing @: some do, some want the field left empty, some want the bare domain name typed out in full instead. Which one you're looking at is decided by the screen in front of you, not by the instructions you're following, so check your own panel rather than assuming @ will work just because a guide told you to type it.

If your panel is built on PowerDNS, which a good number of providers run underneath their own interface, expect to see the full domain name written out in read-only overviews, that's PowerDNS's own default display, not a choice your specific provider made.

A star in the name field: wildcards, and why this site avoids them

A * in the name field makes a wildcard record: it answers for every name under the domain that has no record of its own. A wildcard A record on * means shop.example.com, wwww.example.com and any other name anyone types will resolve, to the same address.

This site recommends against it. A name that does not exist should fail with the answer that says so, NXDOMAIN, so a typo in a link or a mail address shows up as an error instead of quietly landing on your server, and so a forgotten subdomain does not keep answering for years. Every example on this site is built without wildcards for that reason, and the CAA page shows how to refuse wildcard certificates as well. Two cases where a wildcard is fine, and covered on their own pages: the empty DKIM key on *._domainkey for a domain that never signs mail (DKIM), and a report-collecting domain authorising every sender at once with *._report._dmarc (DMARC). Both say no, or yes, to everyone on purpose, which is different from making every name resolve.

Capital letters: a habit for names, a hazard in TXT records

DNS itself doesn't care about capital letters in a name, names are case-insensitive by design. That's exactly why there's no reason to ever use one in the name field, or in a hostname you type yourself: nothing is gained, and a stray capital only makes a record harder to scan or compare later. Lowercase, consistently, is the simplest habit to keep.

Some providers make that habit slightly annoying to follow. Google's own MX record instructions, for one, hand you values written entirely in capitals (ASPMX.L.GOOGLE.COM. and the like), presumably for readability on their side. That value is a hostname, so it works exactly the same either way. Pasting it as it arrives is fine, and so is retyping it in lowercase if you want the zone to look consistent, it's a question of tidiness, not of whether the record works.

There is one practical reason to lowercase a hostname anyway. The web interface of a DNS editor is a separate piece of software from DNS itself, usually built by someone else, and some of them check what you type more strictly than DNS ever would. If a panel throws an error after you pasted a hostname in capitals, retype it in lowercase and try again: DNS doesn't mind either way, but the form sometimes does.

The TXT record is where capital letters genuinely matter. What sits inside one is data, not a name, and data can be case-sensitive. A DKIM key is base64, where an uppercase and a lowercase letter are different characters and changing one breaks the key, and the DKIM specification also requires its version tag to match as an exact string, v=DKIM1. DMARC's specification writes its version tag in capitals too, v=DMARC1. SPF is more forgiving about case, and the verification tokens a service hands you are simply opaque strings. Lowercasing any of those to be tidy is exactly how a working record gets broken. That includes retrying in lowercase when a panel rejects a TXT value: the lowercase retry above is for hostnames only. If a panel refuses the content of a TXT record, the cause is more likely a stray space, a missing quote or a badly split long value (see DKIM), and lowercasing it would only add a second problem.

So the habit is a narrow one: lowercase the names you choose, and paste whatever goes inside a TXT record exactly as you were given it. A, AAAA, CNAME, NS and MX contain only names, addresses and the odd number, and capital letters never decide whether they work. Other records on this site carry data fields as well, CAA, TLSA and SVCB / HTTPS among them, so the rule for those is the same as for TXT: if a value isn't simply a hostname or an address, paste it as it arrived.

TTL: always seconds, even when the panel hides that

TTL stands for Time To Live. It tells a resolver how long it's allowed to keep using a cached answer before it has to ask the authoritative server again. A short TTL means a change reaches visitors faster, at the cost of the authoritative server being asked more often; a long TTL means fewer questions asked, at the cost of a slower rollout whenever something does change.

Inside the record itself, whatever your panel shows you, a TTL is always a number of seconds: 300 seconds is five minutes, 3600 is an hour, 86400 is a day. Some panels are upfront about that and just give you a plain number field, as in the example table above. Others swap in a friendlier-looking picker of minutes, hours or days instead. Either way, it still gets converted to and stored as seconds underneath.

The one genuinely counterintuitive part: lowering a TTL doesn't take effect the moment you save it. A resolver that already cached your record cached it together with whatever TTL was in effect at that time, and it keeps using that cached copy, old TTL included, until that old TTL runs out.

Concretely, say your TTL is currently 3600 seconds (an hour), and you're planning a change you'll want to test quickly once it's live:

1. Lower the TTL itself first, to something short like 120 seconds (two minutes). This change is still governed by the old TTL, so resolvers keep honouring the old one-hour value for up to an hour regardless.
2. Wait out that full hour, the old TTL's own duration, before touching anything else. Once that old one-hour cache period has elapsed, new lookups should normally see the shorter TTL.
3. Now make the actual change. With a TTL of 120 seconds in effect, resolvers that honour it will normally refresh the record within two minutes, so you can start testing almost immediately.

Skipping that hour of waiting is one of the most common reasons a DNS change seems to work for some visitors and not others: it did work, the slow ones are simply still serving an old, cached answer with time left to run. Once you're done testing, there's nothing wrong with raising the TTL back to its usual value, it doesn't need to stay short permanently.