Students do not each need a purchased domain: the standard model gives every student a subdomain — a name like studentid.university-teaching-domain.ac.uk carved from a domain the institution already owns — created automatically with their account, secured with SSL, and costing nothing extra. DNS is the machinery underneath: the records that point names at servers (A records to addresses, CNAMEs to other names, nameservers delegating who answers). Students who later connect a personally-owned domain can, where the deployment allows it — and every name's fate at course end should be decided by policy, not by whoever notices the renewal notice.
Does every student need a domain name?
No — and defaulting to purchased domains for coursework would be cost and administration without teaching benefit. Every student needs an address for their site; a subdomain under an institutional domain provides one automatically, free, tidy and clearly academic. Purchased domains enter the picture only where a student wants one personally (a portfolio on their own name, say) — a fine ambition the deployment can accommodate, not a requirement of teaching.
The distinction to teach: a domain is a piece of rented namespace (registered annually, owned by someone), while a subdomain is a name created within namespace someone already controls — instant, free and as functional as any other name on the web. Coursework wants the second; careers sometimes want the first.
What is a subdomain, and what is a temporary URL?
A subdomain is a name one level below an existing domain: if the institution controls a teaching domain, it can mint names beneath it — one per student, one per group project — each pointing wherever it chooses. Subdomains are not second-class addresses: they carry SSL, appear in search results and behave exactly like any other hostname; the web is full of production services on subdomains.
A temporary URL is the weaker cousin some hosting platforms provide: an auto-generated address (often numeric or provider-branded) that works before proper naming is set up. Fine as plumbing, poor as a student's public address — institution-branded subdomains beat them on memorability, professionalism and trust, which is why a well-run deployment gives every account its real name from day one rather than leaving students on placeholder URLs.
How should student sites be named?
By a written scheme decided before the first account, because renaming an estate later breaks every link students have shared. Good schemes are: derived from stable identity (student ID or institutional username — names change, IDs do not), predictable (staff can infer any student's URL), collision-free by construction (IDs are unique; surnames are not), and publicly presentable (these URLs go on portfolios and marking sheets). Group projects get their own parallel scheme (team or project names under the same teaching domain).
Two policy notes worth writing down with the scheme: profanity-and-impersonation filtering for any scheme that includes chosen strings, and the reuse question — whether a departed student's name is ever reissued (safer not to, within a reasonable horizon: cached links and indexed pages outlive accounts). Whether a deployment uses subdomains, full domains or both is part of institutional setup, agreed during scoping.
Should student sites use university-owned domains?
Institution-owned teaching domains, yes — with a deliberate choice about which. Many institutions use a dedicated teaching domain (distinct from the primary university domain) for student hosting: it keeps hundreds of student sites visually distinct from official university pages while remaining clearly institution-branded — students get credibility, the university keeps its main domain's reputation and cookie scope separate from coursework experiments. Others host student subdomains under their main domain; the trade-off is brand adjacency versus blast radius.
Either way the domain is institutional property under institutional control — registered, renewed and DNS-managed by the university or its provider — which is exactly what makes the naming automatic and the end-of-course behaviour governable. What student sites should never depend on is a domain some individual registered personally: staff-owned or student-owned namespace under coursework is an outage (or a dispute) on a renewal timer.
Can students connect their own domains?
Where the deployment supports it, yes — and for portfolio-minded students it is a genuinely valuable option: a personally-registered domain pointed at their student hosting gives them a professional address they keep after graduation, even as the hosting behind it eventually changes. The mechanics are ordinary DNS: the student registers a domain with any registrar, then points it at their hosting (typically via the records in the next section), and the platform serves their site under both names.
Set the expectations in policy: the student owns and pays for their domain (the university should not become a registrar-by-accident), support covers the hosting side of the connection rather than the registrar's interface, and at course end the domain simply gets pointed elsewhere — which is precisely the portability lesson worth teaching. The portfolios guide covers the graduation handover this enables.
Read next: Hosting student portfolios and client web projects
What DNS records actually matter here?
Four record types cover almost everything student hosting touches, and knowing them is legitimate curriculum as well as administration:
Two behaviours worth teaching alongside the table: DNS changes propagate — caches mean a changed record takes time to be seen everywhere, which is why 'it works for me and not for you' is a normal transitional state, not a fault; and wildcard records exist — one record can answer for every student subdomain at once, which is how estates avoid managing hundreds of individual entries.
| Record | What it does | Where it appears here |
|---|---|---|
| A record | Points a name at an IPv4 address — 'this name lives at this server' | The teaching domain (and student subdomains) resolving to the hosting platform |
| AAAA record | The same, for IPv6 addresses | Alongside A records where the platform serves IPv6 |
| CNAME record | Points a name at another name — 'this is an alias of that' | A student's own domain aliasing their institutional subdomain |
| Nameserver (NS) records | Delegate who answers DNS for a domain or subtree | The institution (or provider) answering for the teaching domain |
How does HTTPS work across student sites?
Every student site should be served over HTTPS, and on a well-run estate that is automatic: certificates are issued and renewed at platform level for the student subdomains, so the padlock is simply how the web looks from a student's first published page. On Education Host student hosting, domain-validated SSL is included across institution-branded student subdomains — students never handle certificates, which is the correct amount of certificate handling for a web-design cohort.
The teachable layer sits on top: what the certificate asserts (this connection is encrypted and this name is validated — not that the site's content is trustworthy), why browsers punish plain HTTP, and what mixed content means when their page loads an insecure asset. Students connecting their own domains get the one extra lesson: the certificate must cover the new name too, which the platform handles where custom domains are supported.
What happens to names and addresses when a course ends?
The name follows the account's lifecycle, and saying so in advance prevents the sad-email genre. When an account is suspended and later archived, its subdomain stops serving; links shared during the course (in portfolios, on marking sheets, in search results) will break at whatever point policy says the site comes down — which is one of the strongest arguments for the notice-and-download windows the retention guide requires. Where policy keeps sites visible through a marking or appeals period, the name keeps serving read-only content until then.
Personally-owned domains are the graceful exit: a student who connected their own name simply re-points it at wherever their work lives next, and nothing they printed on a CV ever breaks. Institutional subdomains cannot promise that permanence — they are teaching infrastructure — so the guidance to finalists writes itself: put the portfolio you care about behind a name you own, before you leave.
Read next: What happens to student websites after a course ends?
How does naming work on Education Host student hosting?
Student accounts are provisioned with institution-branded names automatically — the domain or subdomain model depending on institutional setup, agreed during scoping — with domain-validated SSL included across student subdomains, so every account arrives with its real, secured address and no per-student DNS administration. Naming schemes follow the institution's policy, group projects get their own names under the same structures, and the platform's lifecycle controls govern when names stop serving, in step with account suspension and archival.
DNS for the teaching estate is part of the managed service, which keeps the records table above as curriculum rather than workload for your team.