Understanding the Nettica DNS Microservice

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.

Nettica VPN Service DNS Microservice

Host names you enter into our admin become the host names that resolve using the microservice. In the above example, tunnel.us-west will resolve to 10.10.10.1.

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 propagate to the client in near real-time. The DNS service itself is an authoritative proxy server, that is, it is authoritative for the hosts it knows about, and proxies the results from the specified fallback servers. This allows you to include our DNS in your infrastructure without fear of DNS leaks.

Nettica Agent

The DNS microservice is part of the Nettica Agent service. It listens on all configured VPN networks configured for Nettica DNS. 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 a powerful feature.

What is a DNS leak? It’s when an internal host name is sent 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.

Besides DNS leaks, another potential concern is machine fingerprinting. There is a surprising amount of background traffic occurring on an idle machine. For example:

This example is just the queries involved in browsing 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. And 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 show you these queries in the Nettica Agent. Besides increasing awareness of fingerprinting, often times it can help diagnose serious problems such as a virus infection or connectivity issues.

Naming Strategies

We offer some amazing capabilities when it comes to DNS. You can access public hostnames using their internal nettica VPN 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.

Nettica VPNs are very lightweight. A single organization may have multiple VPNs. 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. Or suffix host names with the cloud provider, such as .aws, .azure, .google, etc. It’s entirely up to you.

DNS Queries

The DNS microservice listens on port 53 on the device’s VPN IP address. Setting the Nettica DNS toggle 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. Queries for internal names not registered in Nettica DNS (typos, etc) will be blocked, as we will answer authoritatively that they do not exist. As queries are received, they are propagated to the Nettica Agent using a loopback port the agent is listening on for all of its notifications.

We also differentiate between our DNS, internal resolvers, and external/global resolvers. We take priority, but if we cannot answer a query and it’s an internal name, we will pass it to the internal resolver before blocking it for the global resolver.

Search Domains

The network name you specify when creating a Nettica network will automatically become an unregistered search domain. This blocks typos for names registered in Nettica DNS (to prevent a leak). You can still specify a search domain in the DNS field to allow those queries to go to your internal resolver. If you do not have an internal resolver, then do not specify any search domains. Typically, it isn’t necessary to specify a search domain, as the system will automatically direct those queries to the proper resolver for resolution.

Additional Reading

Nettica Overview and Architecture