DNS Management
on a global anycast network

Changes publish to the anycast network within moments, but resolvers around the world cache records for the length of their TTL, so the old record can linger until that expires. The move before a planned change is to lower the record’s TTL a day ahead, make the change, then raise it again once everything has settled.

Yes, with a short overlap. Recreate your records in Krystal first and lower their TTLs at your current provider, then switch your nameservers. Because both providers answer correctly during the changeover, resolvers move across gradually with no gap in resolution. Once traffic has fully shifted, you can retire the old zone.

Yes. DNS hosting is separate from where a domain is registered, so you can keep the domain at your current registrar and simply point its nameservers at Krystal. From then on, every record is managed here, whoever the registrar is.

For mail to arrive, you need MX records pointing at your mail provider. For it to be trusted and delivered rather than treated as spam, add the TXT records for SPF, DKIM and DMARC that your provider gives you. All of these are standard record types you create in the console or through the API.

Yes. Add NS records for the subdomain pointing at the nameservers that should handle it, and queries for that part of your zone are delegated there while the rest stays with Krystal. It’s the usual approach when a separate system or team runs one section of a domain.

Yes, and it’s the common setup. Create an A or AAAA record pointing at a VM’s address or a load balancer, and your domain resolves straight to your Krystal infrastructure. If an address ever changes, update the record, or automate it through the API so DNS follows your infrastructure as it moves.