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.

Automatic DNS from Hostnames

You can configure any DNS zone to create DNS records based on system hostnames, which can be useful if you need to make traditionally internal DNS names resolve to Enclave IP addresses.

To do this, navigate to the Zone Properties tab for a DNS zone, and assign one or more tags under Automatic DNS from Hostname:

When a system is enrolled with a hostname that matches one of the listed tags, a DNS record will be created in the zone with the system's hostname as the record name, giving the system a name of <systemhostname>.<zonename>.

Any manually-defined records in the zone will take precedence over automatically-generated records with the same name. You can use this behaviour to reserve DNS names to (for example) avoid an enrolled system automatically acquiring a name it should not have.

You cannot edit DNS records automatically generated from the hostname, but you can override them (from the entry's context menu), creating a manual record that takes precedence. Deleting this manual record restores the automatically generated record.

Tip

If you've assigned a tag to a zone, but not all your tagged devices are showing up in the zone, check their hostname. Only system hostnames consisting of the characters A-Z, a-z, 0-9, and hyphens will be added to the zone. Hostnames with special characters will be ignored (rather than us attempting to sanitise the names). This is particularly common with mobile devices, that may not have a traditional hostname.

Custom DNS records

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

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

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.

You can add your own custom zones with any suffix, to help match against existing zones you may have in your infrastructure, and organise your 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.