Private DNS: Best Practices

While it is not a requirement, Twingate recommends that your network be configured with Resources accessible via private DNS exclusively because it offers several advantages over using IPs or Public DNS:

  1. Public DNS entries for private Resources (on the private network) creates a potential leak of information that could be leveraged by attackers and is altogether unnecessary.
  2. Accessing Resources by IP address can be error-prone and not user-friendly for End Users.
  3. It is possible to encounter IP overlap (ex: 10.0.1.34 being used for 2 separate resources on 2 separate subnets). Using DNS names instead of IPs removes the ambiguity and allows you to connect to both Resources, even if they are assigned the same private IP.

Setup and Structure

📘

Setting Up a Private DNS

Setting up a private DNS zone is easier now than it's ever been!

Services like AWS Route 53 and Azure DNS eliminate the need to deploy a dedicated DNS server yourself.

For on premises networks, you will usually want to deploy a DNS server on a host on the internal network.

Thinking a bit about your DNS structure before deploying will pay off in the end.

For example, it can be very useful to define DNS zones that map to permissions or roles you'd like to configure in Twingate.

To do this, let's define the following DNS zone: .engineering.yourcompany.com with all engineering systems under it:

host1, host2 and host3 are all part of the DNS zone and can be resolved at host[n].engineering.yourcompany.comhost1, host2 and host3 are all part of the DNS zone and can be resolved at host[n].engineering.yourcompany.com

host1, host2 and host3 are all part of the DNS zone and can be resolved at host[n].engineering.yourcompany.com

With this in mind, you can simply create a single Twingate Resource pointing to the DNS Zone:

And we can now map this Resource to a Twingate Group for Engineering:

📘

Great! With this setup, any new systems added underneath the .engineering.yourcompany.com will automatically give access to the engineering team, saving you trouble configuring these Resources manually.

What You Need To Know About Resource and Connector Placement

📘

Who's In Charge of Domain Name Resolution?

In Twingate, the resolution of FQDNs is done by the Connector (in the same way any host on the same subnet as the Connector would).

If you want to confirm that a Connector will be able to resolve hostX.Y.mycompany.com, simply log into the Connector host and run the following command:

nslookup hostX.Y.mycompany.com

Alternatively, there is an option to use a custom DNS server for the Connector, but it can make configuration a bit more difficult, therefore we recommend leveraging whatever DNS servers are configured on the Connector host.


Did this page help you?