HSCN domain naming standards and guidance

The proposed name must be available.

The NHS Digital DNS Team ([email protected]) can advise if a proposed name is available. Not all allocated names can be queried in DNS. This is because some names are reserved, but not created in DNS until needed.

Your proposed name must clearly describe your organisation or the NHS service you’re providing. Think about users of the name and make sure the name is not too long or complicated.

Your proposed name must:

• be between 3 and 63 characters long
• contain only alphanumeric characters (0-9 and a-z) and the ‘-‘ (dash) symbol
• not be the same or substantially similar to an existing .nhs.uk domain name
• not use ‘&’ (ampersands) or ‘_’ (underscores)
• not include abbreviations like ltd, plc and gov
• not include a postcode

You could use the full name of your organisation, NHS service or an appropriate suffix. For GP surgeries, domain names should reflect the official name of the surgery.

‘*’ or wildcard names should not be used anywhere.

If appropriate, your proposed name should be relevant to the area your organisation or the NHS service you’re providing serves.

You might wish to avoid components of your names that are subject to machinery of government  changes. This allows an organisation to potentially continue using a name when a structural change is made by the government.

For example, names suffixed with 'pct' (for primary care trust) were made defunct by the 2013 move to clinical commissioning groups (CCGs), leaving 1071 defunct 'pct' DNS Domains requiring migration to new domains and removal. This issue creates unnecessary additional work in migration of email and web services and clean-up of the DNS database, that could be avoided.

If you apply for a generic word or combination of generic words for a nhs.uk name, the NHS Digital DNS Team will consider it on its merits and may refer the request to other authorities. Central NHS or government organisations may have a claim on generic words used as names, and may claim them without reference to the current user. For example: deepcleaning.nhs.uk.

The NHS Digital DNS Team recommend that you make use of generic words as sub-domains of your domain name. For example: flu.twcsa.nhs.uk.

Your proposed name must be unique. If your proposed name is substantially the same as another nhs.uk name, you must choose another name.

Where the proposed name relates to sub-domain of nhs.uk, or a record in the apex domain, the name must be unique across the whole of the NHS.

Where the proposed name is a resource record in a sub-domain, the name need be unique only within that sub-domain.

The NHS Digital DNS Team ([email protected]) can advise if a proposed name is available.

If you use an acronym, initialism, or abbreviation this must be descriptive, unique and clear to avoid user confusion. You can use commonly-used abbreviations and abbreviations that are well-known to your users.

Names must not:

• host a website with persistent errors or security issues
• redirect entirely to a non-public sector domain like .co.uk, .org.uk, .info or .com
• pose an immediate security threat or interfere with the secure and stable operation of the nhs.uk domain or the NHS.UK ecosystem
• infringe on the intellectual property rights of another individual or entity
• advertise products, commodities or services of private individuals, firms or corporations
• breach NHS brand guidelines 
• be used for party political purposes
• violate any UK laws, regulations or policies
• violate the privacy or publicity rights of another individual or entity

The NHS Digital DNS team reserves the right to remove any DNS zones and associated DNS records on the nhs.uk Nameservers (NS) if it feels that the domain name in question is contravening any of our standards, or poses a security or safety risk. For further advice and guidance, please contact [email protected].

Records in the apex domains are used exclusively for national programmes and services serving the whole NHS. For example:

• mail.nhs.net
• infrastructure.nhs.uk
• api.nhs.uk
• screening.nhs.uk

These records are typically requested and operated by central government organisations or NHS Digital.

Records in the apex domains must be reviewed regularly, and removed immediately they are no longer required.

Unused records in the apex domains will be removed without notice.

Organisations permitted to request a sub-domain name within the apex domain namespaces are:

• Department of Health and Social Care (DHSC) agencies and public bodies
• national organisations wholly owned by the Secretary of State for Health
• NHS trusts and foundation trusts
• clinical commissioning groups (CCGs)
• commissioning support units (CSUs)
• GP surgeries/clinics
• independent sector treatment centres (ISTCs)
• NHS healthcare services

Organisations not permitted to request a sub-domain name within the apex domain namespaces are:

• local health campaigns
• consultations
• single trusts leading on a national level, such as for a rare disease - these should develop content on their corporate website
• individuals (including elected representatives)
• associations representing public sector staff
• public sector pension funds
• social enterprises/community interest companies
• fundraising charities, voluntary and privately-owned organisations, including charitable arms of NHS trusts
• companies and organisations registered at Companies House
• public, privately-owned or charitable organisations undertaking work or programmes both targeting and within the NHS
• internet management and network-related companies, including internet service providers (ISPs) and hosting companies
• British overseas territories and international organisations

It is the responsibility of the trusted domain name administrator within an organisation to renew their claim to each sub-domain each year, and in doing so, ensure that their contact details, and those of the technical contacts are complete and accurate. Failure to do this will result in loss of control of sub-domains, and may result in domain names being suspended.

Sub-domains of the apex domains must be reviewed regularly, and removed immediately they are no longer required.

Empty sub-domains will be automatically removed without notice, although the name will remain registered to the original owning organisation, subject to NHS Digital Domain and Record Naming standards and guidance.

Records in sub-domains must be reviewed regularly and removed immediately when they are no longer required.

Unused records in sub-domains will be removed without notice.

NHS Digital will review all existing off-infrastructure delegations and re-patriate those deemed to fail security, eligibility or naming tests.

The devolved administrations are automatically granted off-infrastructure delegations for sub-domains related to the devolved health services. For example, scot.nhs.uk.

All other requests will be subject to review, which will include evaluation of security implications, clinical safety, evidence of robust management processes and technical constraints.

Off-infrastructure delegations must be reviewed regularly, and removed immediately they are no longer required, or when the third-party provider stops responding to queries.

Unused off-infrastructure delegations will be removed without notice.

Off-infrastructure delegations present 4 primary ongoing security and clinical safety risks:

1. They can be hi-jacked by malign entities, who will then use the compromised resource to pretend to be an NHS provider.
2. They can be easily misconfigured and cause denial of service to the apex domain.
3. They place reliance on potentially unvetted third-parties for security, clinical safety and NHS brand-integrity. 
4. They can be easily misconfigured and permit anonymous remote download of the entire delegation. 

Evidence of continued mitigation of these risks will be required from the owning organisation.

Secondary off-infrastructure delegations are not permitted under any circumstances.

A secondary off-infrastructure delegation exists where a sub-domain is delegated off-infrastructure, and then a child of that sub-domain is further delegated elsewhere.

Secondary off-infrastructure delegations present 5 primary ongoing security and clinical safety risks:

1. They can be hi-jacked by malign entities, who will then use the compromised resource to pretend to be an NHS provider.
2. They can be easily misconfigured and cause denial of service to the apex domain.
3. They place reliance on potentially unvetted third-parties for security, clinical safety and NHS brand-integrity.
4. They can be easily misconfigured and permit anonymous remote download of the entire delegation.
5. They are virtually invisible to administrators of the apex domain.

The NHS Digital DNS team reserves the right to re-patriate any off-infrastructure delegation if it feels that the off-infrastructure delegation in question is contravening any of our standards, or poses a security or safety risk. For further advice and guidance, please contact [email protected].

NHS Digital provide resource to support, maintain and update a free DNS management service, for the benefit, security and safety of the whole NHS.

CNAME - Canonical name record

MX - Mail exchange record

SRV - Service locator record

PTR - Pointer record

CAA - Certification Authority Authorization record

DNAME - Delegation name record

DS - Delegation signer record

URI - Uniform Resource Identifier record

TXT - Text record

The devolved administrations are automatically granted requests for records with off-infrastructure targets within sub-domains related to the devolved health services.

Requests for records with off-infrastructure targets will be subject to review, which will include evaluation of security implications, clinical safety, evidence of robust management processes and technical constraints.

Records with off-infrastructure targets will not be permitted in the apex domains.

Records with off-infrastructure targets must be reviewed regularly, and removed immediately they are no longer required, or when the third-party provider stops responding to queries.

Unused off-infrastructure delegations will be removed without notice.

Records that direct traffic elsewhere present 3 primary ongoing security and clinical safety risks when those targets are off-infrastructure:

1. They can be hi-jacked by malign entities, who will then use the compromised resource to pretend to be an NHS provider. 
2. They can be easily misconfigured and cause denial of service to the apex domain.
3. They place reliance on potentially unvetted third-parties for security, clinical safety and NHS brand-integrity.

Evidence of continued mitigation of these risks will be required from the owning organisation.

The following standards apply:

1. Off-infrastructure targets should be avoided wherever possible.
2. Where used, it is the owning organisation’s responsibility to ensure that off-infrastructure targets do not become orphaned, or taken-over by unauthorised entities.
3. Organisations using off-infrastructure targets (such as to contract content supply to a third party) are responsible for requesting the removal of off-infrastructure targets when the service is no longer being supplied.
4. Organisations using off-infrastructure targets are responsible for ensuring that supplier comply with NHS Digital security policies.
5. Off-infrastructure targets will be monitored and targets at apparent risk of take-over will be automatically deleted without notice.
6. Evidence of continued adherence to these standards will be required from the owning organisation.

Secondary off-infrastructure targets (such as where the target record is itself a pointer hosted elsewhere) are not permitted under any circumstances.

The NHS Digital DNS team reserves the right to remove any record on the nhs.uk Nameservers with an off-infrastructure target if it feels that the record in question is contravening any of our standards, or poses a security or safety risk. For further advice and guidance, please contact [email protected].

ARPA zone necessarily remain under the control of NHS Digital.

ARPA zones will be reviewed regularly and removed immediately when they are no longer required.

Empty ARPA zones will be automatically removed without notice.

PTR records must be reviewed regularly, and removed immediately they are no longer required, or when the target is no longer resolvable.

Unused PTR records will be removed without notice.