DNS Zones
A DNS Zone contains all the DNS records associated with a domain, such as cycle.io
.
Cycle provides a fully managed DNS service as part of the platform. Cycle can create and manage records for a domain, and even provides convenient record types, such as the LINKED record, for directly linking domains/sub-domains to containers or deployments of containers without needing to update or hard-code load balancer IP addresses.
Cycle can also manage sub-domains of a domain, for cases where it isn't desired for the platform to manage the entirety of a domain.
For example, a DNS zone can be created for development.cycle.io
, where cycle.io
would be managed by another DNS service,
and development.cycle.io
would be managed by Cycle. This is called sub-domain delegation.
Hosted Zone
Hosted zones are for domains that will be managed by the platform. Hosted zones can be configured to either manage a root domain, a sub-domain, or multiple sub-domains of that domain (known as delegated sub-domains).
Hosted zones must be verified before they can be used on Cycle.
Managing a Root Domain
To have the platform manage a root domain (i.e. cycle.io
), the domain must have its authoritative nameservers set to the following:
ns1.cycle.io
ns2.cycle.io
ns3.cycle.io
ns4.cycle.io
This is usually done at the registrar where the domain was purchased.
dedicated core
The nameservers above will differ when deploying to a dedicated core.
Managing a Sub-Domain
In cases where it isn't desired or possible to manage the root domain, a hosted zone can be created to manage a sub-domain (i.e. development.cycle.io
).
To do this, set the origin of the zone to the sub-domain, and at the DNS provider create at least two NS records with the the host set to the sub-domain you want Cycle to manage, and the value set to
- ns1.cycle.io
- ns2.cycle.io
- ns3.cycle.io
- ns4.cycle.io
dedicated core
The nameservers above will differ when deploying to a dedicated core.
Sub-Domain Delegation
In some cases, it may be convenient for Cycle to manage multiple sub-domains of a domain at once. To do this, set the origin of the zone to the domain (this can be a root domain or sub-domain), and create the following:
- A TXT record with the host set to
cycle-verify
, and the value set to your hub ID - At least two NS records for every sub-domain that will be managed on Cycle, with the the host set to the sub-domain, and the value set to
- ns1.cycle.io
- ns2.cycle.io
- ns3.cycle.io
- ns4.cycle.io
dedicated core
The nameservers above will differ when deploying to a dedicated core.
Non-Hosted Zone
Non-Hosted zones do not require verification and maintain their authoritative nameservers. These types of zones are used when routing is handled outside of Cycle (such as when using Cloudflare in front of your domain). The records can be created to teach the load balancer how to handle ingress traffic (i.e. which container should the request route to using a LINKED record), but it is up to the user to route traffic to the load balancer, usually by creating A and AAAA records at the DNS manager that point to the public IPs of the load balancer.
Learn how to create a non-hosted zone on Cycle
Which DNS Zone Type Should I Use?
If possible, all zones on Cycle should set up as hosted zones. This provides the greatest experience and allows the platform to fully manage features such as automatic TLS generation/renewal.
In some cases, it may not be possible to have Cycle manage a domain or sub-domain, or it may need to be proxied through a service such as CloudFlare. In this case, a non-hosted zone will work, but it will require more manual effort and will miss out on a lot of the automation provided by Cycle.