GLOSSARY (SHORT & FACTUAL)

This glossary is intended as a beginner's reference, not as a full legal definition for every individual case. Details always depend on the TLD/registry, the contract, the history, and the parties involved. For a deeper, professional look, see our guides, for example Domain Transfer and Secure Trading.

Auth Code / EPP Code

Authorisation code that is often required for registrar transfers. Without a valid entry/status, no (further) transfer can begin. See: Transfer Guide

Registrar

The service where a domain is actually managed (ordering, customer data, transfer processes) – in line with the rules of the respective registry/TLD.

Registry

The top administrative level for a TLD, which sets guidelines, policies and technical registry rules, among other things (very roughly: "who operationally stands behind .de, .com, .net …" – organised differently depending on the TLD).

Registrant (Owner/Registered Holder)

In the Whois/registrar context, often the person/organisation to whom the domain is actually assigned; visibility varies depending on data handling/redaction.

TLD (Top Level Domain)

An extension such as .de, .com and so on. TLDs have different rules, procedures, prices, and protection and recovery policies. Broadly: gTLD (many "generic" TLDs) versus ccTLD (country-specific, e.g. .de) – these should not be treated as equivalent across the board in terms of policy.

WHOIS / RDAP

Lookup services for viewing certain domain metadata (where available/public). Because of privacy redaction, often only parts are visible.

EPP (Extensible Provisioning Protocol)

A technical standard in the registrar/registry context (behind many of the processes that run on an "Auth Code" model, among others).

Nameserver (DNS)

The servers that resolve domains into IP addresses/records. DNS is independent of "email mailboxes", but is closely tied in practice to availability, migrations, and provider logic.

Transfer Lock (Registrar Lock)

A protective setting that (depending on the TLD) makes transfers harder until it is properly released. Not a "bug", but often a security feature.

Redemption/Grace Phases (broadly)

Specific (TLD/registry) periods during which a domain effectively "sits" differently than during the normal active cycle. Duration and options depend heavily on the TLD. No blanket statement is possible.

RGP (Redemption Grace Period, broadly)

Often associated with gTLD-/ICANN-related models: a phase in which a previously registered domain is effectively stuck in a different (more expensive/riskier) status – the details and available actions depend on the registry/registrar/TLD. Not a universal one-to-one clone of ccTLD/DENIC/registry processes – always context-specific in practice.

ICANN Transfer Policies (gTLD, broadly)

In the gTLD/ICANN environment there are regulatorily motivated transfer and lock patterns (commonly: "newly registered/transferred, then 60 days, then …" – for the exact rules, check against the currently valid policy/registrar context). Not to be applied wholesale to every TLD; ccTLDs in particular are governed differently.

The 60-Day Rule / Transfers (often quoted, often misunderstood)

A pattern frequently mentioned in forums/Slacks is the restriction that immediately after (certain) events no further transfer is possible. The details are policy- and registrar-dependent – it "feels like a bug", but in practice it is often security and anti-abuse logic. Don't confuse this with "I just want to change DNS" – that's a different matter.

IXFR / AXFR (Zone Transfer, roughly technical)

Mechanisms by which DNS zone data can be reconciled on the server side (depending on the setup; not relevant in every consumer context, but important for anyone dealing with a "secondary/primary nameserver setup"). Rarely day-to-day business for a domain owner, but useful for putting "DNS drama" stories into perspective.

DNSSEC (broadly)

A security layer intended (in simplified terms) to more strongly assure that answers to DNS queries genuinely match your intended chain. Not every domain/environment uses it; run incorrectly, it can visibly "slow things down"/block them until it is set up properly. Not a must for every campaign – but important in regulated/high-security setups.

SPF, DKIM, DMARC (Email, broadly in the domain context)

Policies anchored in DNS that help reduce abuse and mark mail as more credible. Many "domain is here, but the mail is gone" cases are actually a matter of DNS/auth/migration craft, not primarily an ownership "transfer problem". Background: Email/DNS before the actual transfer.

MX, TXT, CNAME, A/AAAA (DNS, broadly)

A/AAAA point to hosts, CNAME redirects/aliases, MX routes email, TXT carries verification and policy strings, among other things. In practice, domains live within a web of such decisions, not in a single setting.

Private Registration / Whois Privacy (broadly)

Many providers hide sensitive data (depending on the TLD), showing proxy/redaction instead where applicable. Important for real identification in disputes, but not automatically "proof of dishonesty".

Premium Domain / Aftermarket (Market, broadly)

The secondary market for names that are already registered, often with completely different pricing logic than fresh registrations. Valuation is a matter of context, not a simple spreadsheet exercise – see Valuation and Secure Trading.

Typosquatting (broadly)

Registering easily confused spellings in order to divert brands/traffic. Can be economically and legally relevant – assessed case by case.

UDRP/URS (broadly, not a substitute for legal advice)

Dispute-resolution and procedurally relevant scenarios around trademark- and name-conflict-sensitive domains; the details are highly formalised and cannot be summed up in a single sentence.