The Domain Name System, or DNS, translates host names to IP addresses. It is one of the core components of the Internet. We provide a unique, and most importantly, secure means of managing your VPN’s DNS with the Nettica DNS microservice.
Host names you enter into our admin become the host names that are resolved using the microservice. In the above example,
tunnel.us-west will resolve to
C:\>ping tunnel.us-west Pinging 10.10.10.1 with 32 bytes of data: Reply from 10.10.10.1: bytes=32 time=19ms TTL=64 Reply from 10.10.10.1: bytes=32 time=32ms TTL=64 Ping statistics for 10.10.10.1: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 18ms, Maximum = 32ms, Average = 22ms
DNS updates are propagated to the client in near real-time. The DNS service itself is an authoritative server, that is, it is authoritative for the hosts it knows about, and returns an error otherwise. This allows you to include our DNS in your infrastructure without fear of DNS leaks. Our microservice does not leak DNS queries. That’s because it does not make additional DNS queries that can be leaked upstream. If you’re specifying a public DNS server in your VPN DNS configuration (such as 22.214.171.124), you’re leaking queries.
The DNS microservice is part of the Nettica Agent. It will listen on all configured networks for which Nettica DNS is configured. It will resolve host names as they appear in the Nettica Admin. You can specify whatever you want in the DNS; if you have a WordPress site called “mysupercoolwebsite.com”, and you enter that into the admin, our DNS will resolve the IP for that host to your WireGuard internal IP, giving you extra secure access to your website. That’s what we do.
Note that Windows machines can have problems resolving single-label host names (such as “db” or “laptop”), adding a dot and an extension, such as “.us-west” in the example above, will result is consistent resolution and is recommended. For the die-hards with single-label host names, adding a dot to the end of host name can also force proper resolution, but isn’t particularly recommended, and your mileage may vary.
What is a DNS leak? It is when an internal host name is leaked to a public resolver. A classic example of this is the RFC-1918 root DNS service that exists for no other reason than to fail reverse DNS lookups for private subnets. In addition to internal names being leaked, there is a surprising amount of background traffic occurring. For example:
This example is just the queries involved in going to google.com. Based on the queries your idle machine makes it is very easy to mine and fingerprint (windows, linux, etc) the machines making these queries. It’s not limited to just the type of machine. If you use slack, teams, or just about anything else, or anything that “calls home” for updates can leak information.
We offer some amazing capabilities when it comes to DNS. You can access public hostnames using their network IP address, rather than directly through the public address. That means, for example, you can bypass the CDN hosting your website and work directly against the origin, rather than going through the reverse proxy.
Networks are very lightweight. A single organization may have multiple networks. In addition to a corpnet, there may be networks for sales, marketing, development, etc. You may organize by country/region, or continent. You may want to suffix with the name of the network, such as a network named “relay” with a host named host.relay. You can also suffix host names with the cloud provider, such as .aws, .azure, .google, etc. It’s entirely up to you.
The DNS server listens on port 53 on the host’s network IP address. Setting the Nettica DNS setting in the console simply adds that IP address into the DNS list for the host. Queries will automatically come to this address as it’s registered in the system. Those queries are received. In order to propagate those queries to the Nettica Agent, we use an IPv4 multicast address, which the agent listens for. This means all of the Nettica clients on the same network will broadcast their queries to any running Nettica Agent.