DNS

DNS is the mechanism by which a name, e.g. myserver.enclave is resolved to an IP Address; in our case, an Enclave IP Address (e.g. 100.84.10.20).

The Enclave DNS feature provides built-in DNS support for Enclave and allows you to define your own DNS names from a single central location in the portal or via our APIs.

On each Enclave System, the installed agent runs a local authoritative DNS nameserver (also known as a stub resolver), bound to the local Enclave Virtual Adapter, that provides DNS services.

Automatically assigned names

When a System is enrolled, it is assigned a short, unique, System ID. This System ID is displayed in the System's detail view in the portal, in the Windows tray application, and when you run enclave status from the command line.

All systems are automatically assigned a name based on their System ID, {systemId}.id.enclave. So, as an example, if a system has the id 488Q, it will always have the DNS name 488q.id.enclave.

Custom DNS records

To create a custom DNS record, go to your DNS settings in the portal.

Info

Organisations on our Business Plan can create additional custom DNS Zones in addition to the default enclave zone. See the section below on custom DNS zones for more info.

To create a new DNS record, click "Create New Record"; then specify the hostname you want. You will get a preview of the fully-qualified domain name (FQDN) as you type.

Hostnames can only contain alphanumeric characters (A-Z,0-9), hyphens, and a period character to separate sections of the name.

Tip

You can also enter the special '@' character on its own to create an apex record (an A record with the name of the zone) or the special '*' character to create a DNS wildcard record.

There are two ways to specify which systems should be resolved for a given DNS name.

The first is using Tags. You can specify a list of tags for the hostname. Any system with one of the specified tags will be resolvable from the name you defined.

The second is by specifying exactly the systems you wish to resolve with that name.

In general, we suggest attaching DNS names by tag if you can, because it is less brittle, and easy to replace the System that provides a given application or service without updating the DNS record.

A single DNS record can resolve to a one or more Tags, one or more System, or a combination of the two.

The Detail pane of each System in your Organisation provides a full list of all names currently applied to each system, as well as an indication as to how that system inherited the DNS name (i.e. via a Tag or a System assignment).

DNS server query order

DNS resolution in Enclave happens based on a fan-out approach. When attempting to resolve a DNS hostname, the operating system will first question the Enclave DNS stub resolver. If the stub resolver knows the answer it will reply, else it will respond with a SRVFAIL message, causing the operating system to present the same question to other available resolvers in a fan-out pattern.

In Windows, each network interface can be configured with distinct DNS resolvers, so it's sometimes difficult to understand which DNS server the operating system will query first in order to resolve hostnames.

In Windows 10, Server 2016 and later the query order is defined by the interface metric as described in this knowledge base article. In previous versions of the Microsoft operating system, query order was defined by adjusting the Network Protocol Bindings order in control panel.

DNS-based load balancing

If more than one system has a given name assigned to it, either directly, or because of a tag, then implicit DNS load balancing kicks in.

If a System resolves a name with multiple systems assigned to it, it will randomly resolve to one of the systems it is connected to with that name.

That last point about being connected to the system is important, because it means you can also set up geographically segmented networks that resolve a different System IP Address based on the policies in place for the System, all from the same DNS name.

Record cache and expiry

DNS changes made in the portal are propagated immediately to every impacted system, so unlike traditional DNS resolvers, Enclave records don't specify a time to live value (actually they do, but the TTL is 0). Anything which queries the Enclave stub resolver is encouraged to immatediately expire the response rather than cache it, including the operating system. Therefore the propagation time for any changes to DNS entries in the portal is governed entirely by the latency between the Platform and connected agents, which is usually measurable in milliseconds.

Custom zones

Note

This feature is only available to paid customers.

Every organisation has a default enclave zone pre-defined, to which you can add as many DNS records as you wish, but they will all have the .enclave suffix on your names.

Organisations on our Business Plan (see pricing) can also create any number of custom zones, with any TLD they wish.

You can use this feature to help organise your DNS names, or create names that match certificates issued for existing publicly-managed names.

Split-DNS

In some scenarios, you may wish to create a split-DNS configuration using Enclave with an existing, public zone. For example, consider the fictional company https://contoso.com/. The public DNS resolvers for this top-level domain already exist, but an administrator may wish to publish a hostname in this zone that points to an Enclave IP address, for example intranet.contoso.com.

By creating the zone contoso.com and creating a record inside that zone named intranet, an administrator may create a DNS entry known only to enrolled Enclave systems and not published in, affecting or conflicting with public DNS records.

Note

A System will only gain knowledge of an Enclave DNS entry if there's an active policy connecting it to one (or more) of the target system(s) to which the DNS record resolves. For example consider two systems, a user and a Postgres database server. The user can only resolve db.enclave if there's a policy connecting that user to the Postgres database server, and the Enclave DNS record db.enclave is set to resolve to the Postgres database server.

When the operating system attempts to resolve the name intranet.contoso.com it will first question the local stub DNS resolver run by the Enclave agent. As this name was configured in the Portal, the stub resolver will answer the question and the name will be resolved.

If the operating system, or other software, attempts to resolve a hostname that is not configured in the Enclave portal, the local stub resolver will still receive the question, but answer with a SRVFAIL causing the operating system to fan-out and present the question to a wider set of name resolvers configured on the operating system.

See DNS server query order for more information.

Renaming a zone

You can rename a custom zone after creating it. This will update the FQDN (fully-qualified domain name) of all records inside the zone to respect the new FQDN.

Changing a zone's name will immediately change all of the DNS names on that zone from the perspective of client systems, so make sure you understand what systems might need to be reconfigured after the change.

Warning

You will not be able to rename a zone if the new name results in record FQDN clashes with names in an existing zone.