Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNS guidance update #1006

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 45 additions & 15 deletions source/standards/dns-hosting.html.md.erb
Original file line number Diff line number Diff line change
Expand Up @@ -8,26 +8,56 @@ review_in: 12 months

To ensure users can connect to your service, you'll need accurate Domain Name System (DNS) records and a DNS provider to supply your DNS nameservers.

You can find information on choosing where to host your DNS and how to request nameserver delegation at GDS in the [Service Manual][].
For services [hosted on AWS](./hosting.html) you should use [Amazon Route 53][] as a cloud DNS web service.

As part of your DNS strategy and planning you need to ensure:
> Some services dual-host their DNS using [Google Cloud DNS][] for high nameserver availability.
> This adds complexity and risk, so do a careful analysis of how it could affect overall reliability first.

* your DNS record configuration is reproducible (for example, the DNS records are version controlled or autogenerated)
* you consider DNS availability as part of overall service availability.
You can read more about [service domains and DNS][], including how to apply for a domain name for citizen-facing services, in the Service Manual.

For example, `publishing.service.gov.uk` is published to both Amazon Route 53 and Google Cloud DNS to remove vendor as a single point of failure.
This means that even if AWS has a total outage, users can access parts of GOV.UK by using Google Cloud DNS to resolve addresses, and viewing content that is available in the CDN cache.
[Service Manual]: https://www.gov.uk/service-manual/technology/get-a-domain-name#choose-where-youll-host-your-dns
[Amazon Route 53]: https://aws.amazon.com/route53/
[Google Cloud DNS]: https://cloud.google.com/dns/
[service domains and DNS]: https://www.gov.uk/service-manual/technology/get-a-domain-name

Note that if your service availability relies on a single vendor, there is less benefit to deploying DNS to multiple vendors.
## Production and non-production domain names

When you implement your DNS strategy you should consider using:
Your non-production domains should be subdomains of your production domain.

* [Amazon Route 53][] as a cloud DNS web service
* [Google Cloud DNS][] for high nameserver availability
For example, if you service can be found at `myservice.service.gov.uk`, then you might also have Route 53 records for your other environments, such as:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This point's under discussion at the moment. I agree with it, but I don't think it's been properly agreed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to leave this open assuming the discussion isn't gonna take forever, LMK :)


You can read more about [service domains and DNS][] in the Service Manual.
* `staging.myservice.service.gov.uk`
* `dev.myservice.service.gov.uk`

[Service Manual]: https://www.gov.uk/service-manual/technology/get-a-domain-name#choose-where-youll-host-your-dns
[Amazon Route 53]: https://aws.amazon.com/route53/
[Google Cloud DNS]: https://cloud.google.com/dns/
[service domains and DNS]: https://www.gov.uk/service-manual/technology/get-a-domain-name
> In this example it's important to avoid setting cookies for the entire domain `myservice.service.gov.uk`.
> Always follow the
> [OWASP guidance on cookie domains](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#domain-and-path-attributes)
> such as to avoid using the `Domain` cookie attribute.
>
> You can also consider ensuring full separation using the domain hierarchy, for example by putting your production service on `www.myservice.service.gov.uk`.

You can manage all of these records from your production Route 53 configuration pipeline, even though they relate to other environments.

If your service has more complex needs you may alternatively
[delegate](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-routing-traffic-for-subdomains.html)
the zone for a subdomain to an AWS account that relates specifically to that environment.

## Internal GDS services

Internal GDS services must be hosted on subdomains of the `digital.cabinet-office.gov.uk` domain.

> This domain is likely to change as part of GDS moving to DSIT.

Once you have
[configured your Route 53 hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html),
you'll need to use the
[GDS IT Help Desk](https://gdshelpdesk.digital.cabinet-office.gov.uk/helpdesk)
to request delegation of your subdomain - choose:

* IT Requests
* Changes - Request & Support
* DNS

You must follow the [GDS brand guidance][] for services that are accessible by the public but which don't use the GOV.UK brand.

[GDS brand guidance]: https://docs.google.com/document/d/1MXFXP7oMxALiA4t6Gw8XFPksMI-aBjKqO5wCHvnccyo