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 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 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 then 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.
DNS Leaks
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. An example of that is “*.168.192.in-addr.arpa”. Those queries happen constantly, whether you’re aware of it or not. We either answer them or block them.
Fingerprinting
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.
In our previous example of RFC-1918 names, the full query includes the internal IP address of the machine making the query, leaked externally. Whoever sees that query can then determine how many machines are behind a given address. And it’s not limited to just the number of machines. 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. 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 then 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 then 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. In the example above it’s “us-west”. This blocks typos of 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 with Nettica, as the machine should automatically direct those queries to the proper resolver for resolution.
Conclusion
With twenty years of experience in DNS, we know our stuff. We’ve spent weeks analyzing network traffic to ensure your privacy is protected. We’ve analyzed the behavior of different operating systems to ensure proper behavior. If there’s a leak in the system, then it’s likely we didn’t get the query to block it. Our expertise in DNS keeps you safe, and the Internet just a little bit safer to use.