Architecture
      Back to home
      1. Help Center
      2. VirnetX Matrix®
      3. Architecture

      VirnetX Secure DNS and Zero-Trust Architecture in VirnetX Matrix™

      This is a technical description of the VirnetX SDNS technology and how it creates a foundation for a zero trust architecture found in VirnetX Matrix.

      Background on Domain Name System (DNS)

      The domain name system (DNS) protocol was developed in the early 1980s when the ARPA Internet was first created (https://www.rfc-editor.org/rfc/rfc882). When the Internet was first created, it was between a small number of government and academic research facilities and because all participants in the network were trusted, security was not a major consideration in its design.

      The network routes requests based on a unique numeric address for each device/endpoint called Internet Protocol or IP addresses, an example of an IP version 4 (or IPv4) address is 10.10.10.10. An IPv4 address is 4 numbers between 0 and 255 separated by dots. Of course, users of the Internet don’t easily remember long numbers, so when a user wants to reach an endpoint on the Internet, they enter a unique name associated with the endpoint (such as virnetx.com). The DNS protocol translates the name to a numeric IP address. Later, IPv6 was created which has much longer numeric addresses because we’re running out of IPv4 addresses, but for compatibility all important services are still reachable with IPv4 addresses.

      A few key attributes of original DNS design which are features of the DNS today include:

      • The requester of the DNS answer can be anonymous,
      • Generally, all anonymous users can get the IP address associated with a name, and get the same DNS answer in most configurations,
      • Because the IP address determines how traffic is routed, it tells with some accuracy the location of the endpoint, so if anyone can get that IP address from the name, anyone can attack that specific endpoint. These attacks can include denial of service (DoS) attacks, attacks to gain information about your service, scanning the IP address for signatures that reveal the specific applications and operating system variants running at the IP address, and finally attacks to exploit vulnerabilities in the OS/application running at that IP address.

      Secure Domain Name Service (SDNS)

      The VirnetX SDNS technology is an improved DNS system which has advantages over the original DNS design. The VirnetX SDNS technology has the following attributes:

      • All requestors of SDNS must be cryptographically authenticated,
      • To receive a DNS response other than name not found, the requestor must be in the security policy of the requested endpoint (this security policy is defined by the owner of the endpoint).
      • As part of responding with an IP address, the VirnetX SDNS technology dynamically puts in place a VPN tunnel between the requestor and responder hosts and responds to the DNS request with a unique dynamic secure IP address which automatically routes traffic through an end-to-end encrypted VPN tunnel to the host at the target name.
      • In the 1990’s an improvement to the original DNS design was created called DNSSEC (or DNS security). VirnetX SDNS is different from DNSSEC. DNSSEC cryptographically protects the DNS answers to prevent DNS cache poisoning attacks. VirnetX SDNS has the same features as DNSSEC (cryptographically protecting DNS answers), but goes beyond DNSSEC to also require cryptographic authentication (no anonymous requestors), and to put a secure communications channel in place based on the defined security policy as a part of responding the DNS request.

      Almost all network applications and VPN servers protecting network application services require an open listening port on the firewall (usually a demarcation point between public and private networks) to facilitate a network socket connection into that network application service that is typically running on the private network.

      A unique feature of the VirnetX SDNS technology is that no open ports are required for an application protected by VirnetX SDNS. Both the requestor and responder endpoints can be on private networks behind network address translation (NAT) firewalls \ gateway \ and routers, and the VirnetX SDNS technology will still dynamically create a secure tunnel between the endpoints and return a secure IP address for communication over that VPN tunnel.

      The way that the VirnetX SDNS technology accomplishes the VPN connection without any open ports is it uses the authenticated network connection to the SDNS service to facilitate the STUN (session traversal utilities for NAT) and TURN (traversal using relay around NAT) protocols to connect the VPN when no direct network socket connection seems possible.

      The encryption channel of the VPN is always end-to-end between the two endpoints; however, the network connection is either direct using STUN if possible or through a network relay which reflects the traffic without decryption. Once the VPN is in place and the unknowable secure IP which routes traffic through the VPN is returned to the requesting application, the requesting application can then connect a network socket through the VPN to the requested endpoint (and only inside the VPN is that listening port visible).

      VirnetX’s SDNS technology provides a very powerful network security mechanism that secures applications without modifying the applications. By simply installing and configuring the VirnetX SDNS technology on each endpoint and configuring the application to use secure domain names, the application gains a network security layer and becomes invisible on the Internet to third-party attackers.

      Figure 1 depicts the VirnetX SDNS Technology implemented by VirnetX Matrix. The secured applications' DNS lookups are seen by the VirnetX One Client. If the request is for a secure domain name, the connect/DNS lookup request is forwarded to the VirnetX One ZTNA Service. The requester is securely authenticated to the VirnetX One ZTNA service. If the requestor is in the security policy of the requested Secure Domain Name, a dynamic VPN is put in place between the requester and responder using STUN/TURN if required, and the secure IP address is returned, which will route the traffic through the VPN. This secure IP address is returned to the requesting app, which will then route all its traffic through the VPN. 

      ArchitectureFigure 1- Architecture of VirnetX SDNS Technology and VPN Formation

      Steps for SDNS resolution 

      The following lists the steps for SDNS resolution.  

      1. A DNS lookup is initiated on the user’s device from a client app such as a browser, terminal client, or background service.
      2. The DNS lookup by the client app is locally intercepted by the VirnetX One client. The method used to intercept the DNS request depends on the operating system.
      3. The DNS lookup is compared against the cached security policy of the device to determine if the DNS lookup is for a secure destination or for a traditional DNS destination. Certain gTLD extensions can only be secure destinations such as *.scom.
      4. If the DNS lookup is for a traditional domain name, the request is forwarded to the devices configured DNS service and the resolved response is sent back to the requesting client.
      5. If the DNS lookup is for a secure destination behind a VirnetX Matrix server, the lookup is forwarded to the VirnetX One ZTNA service over a mutual authenticated TLS TCP socket.
      6. If the VirnetX One Client has permission to access the secure destination at the VirnetX Matrix server, and the disposition of the requesting device meets the security criteria for allowing access, the VirnetX One ZTNA service facilitates the establishment of a VPN between the two devices and returns a dynamically generated secure IP address to the requesting device. Both the VirnetX One Client and VirnetX Matrix Server maintain a persistent connection with the VirnetX One ZTNA Service via a mutually authenticated TLS TCP socket to communicate. This channel is used for both DNS requests and establishing VPNs.

      The VirnetX One Client on the requesting device returns the secure IP to the client app after the VPN is in place as a response to the original DNS lookup. VirnetX SDNS supports CNAME records that can be used as an alias between a DNS record and a SDNS record. For example:

      web.virnetx.com --> server.web.virnetx.scom

      This allows administrators to easily secure an existing application or service without changing the user experience or setup. In the example above, authorized users can visit, https://web.virnetx.com and behind the scenes it will be secured by VirnetX SDNS.  During the application setup process, administrators can easily setup a CNAME record for each application or service they are securing.

      Virtual Private Network (VPN)

      Steps for VPN Formation
      During the SDNS resolution process, a peer-to-peer, split-tunnel VPN is automatically established between the VirnetX One Client and VirnetX Matrix Server.  The split tunnel VPN only contains traffic for the secure IP address and only the ports/IP destinations required for the app.  Any other web or application traffic is not routed through the VPN. 

      As part of the SDNS process (Step 6), if the VirnetX One Client has permission to access the secure destination at the VirnetX Matrix server, and the disposition of the requesting device meets the security criteria for allowing access, the VirnetX One ZTNA service facilitates the automatic establishment of a VPN between the two devices. Both the VirnetX One Client and VirnetX Matrix Server maintain a persistent connection with the VirnetX One ZTNA Service via a mutually authenticated TLS TCP socket to communicate. This channel is used for both DNS requests and establishing VPNs.
      1. The VirnetX Matrix Server validates the connection request by independently cryptographically confirming the identity of the requester and comparing that identity to its local copy of the security policy which contains a list of the users with access to specific applications protected by the VirnetX Matrix server.
      2. The VirnetX Matrix Server uses STUN characterizations to establish network channel (relay/non-relay) between itself and the VirnetX One Client.
      3. The VirnetX Matrix Server forwards a Connection OK Reply to the VirnetX One Client.
      4. The VirnetX One Client and the VirnetX Matrix Server perform key exchange and establish a VPN channel via the established connection (direct or relay).
      5. The VirnetX Matrix Server returns the dynamically selected secure IP for the VPN endpoint through the VirnetX One ZTNA service to the VirnetX One Client.

      Direct Connections vs Relay Connections

      There are three different types of connections:

      1. Direct UDP - Encrypted data routed through a peer-to-peer VPN directly between the client and the VirnetX Matrix Server.
      2. Relay UDP - Encrypted data is routed through the VirnetX Relay Service in order to make a network connection between the client and the VirnetX Matrix Server.
      3. Relay TCP - Encrypted data is routed through the VirnetX Relay Service in order to make a network connection between the client and the VirnetX Matrix Server.

      Direct UDP is the default and ideal connection that yields the highest throughput and lowest latency.

      STUN, TURN and Tunnel Path Selection

      The VirnetX One Platform uses an enhanced version of Session Traversal Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) for selecting VPN tunnel protocol and packet routing. STUN is the classic method used to identify and characterize the firewall’s network address translation (NAT) behavior for out-going User Datagram Protocol (UDP) packet port translations. Depending upon the predictability of this behavior, there are methods within the discovery process broadly referred to as TURN for establishing a direct UDP channel between two end points, each behind its own firewall. In the case where one or both firewalls do not provide the requisite port translation predictability, the connection channel between the two end points requires the use of a relay.

      The VirnetX One Platform streamlines the STUN/TURN discovery process by using STUN interrogations before connections are requested. The discovered firewall characterization is shared with the other end point so that the channel protocol and routing can be determined without any additional discovery. This characterization is updated whenever a platform changes its network environment. Discovery predetermines the ability to use direct UDP, relayed UDP or relayed TCP.

      Both the VirnetX One Client and VirnetX Matrix Server establish a persistent connection with the VirnetX One ZTNA Service via a mutually authenticated TLS (mTLS) TCP socket to communicate. This channel is used for both DNS requests and establishing VPNs.

      Implementing Zero Trust with VirnetX SDNS Technology in the VirnetX Matrix Product

      Zero Trust

      The Zero Trust architecture is well defined in the NIST 800-207 publication (see https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf).   The key tenets of zero trust are defined in section 2.1:

      • All data source and computing services are considered resources.
      • All communications are secured regardless of network location.
      • Access to individual enterprise resources is granted on a per-session basis.
      • Access to resources is determined by dynamic policy – including the observable state of client identity, application/service, and requesting asset – and may include other behavioral and environmental attributes.
      • The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
      • All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
      • The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

      Section 2.2 goes on to define zero-trust at the network level in more detail:

      • The entire enterprise private network is not considered an implicit trust zone.
      • Devices on the network may not be owned or configurable by the enterprise.
      • No resource is inherently trusted.
      • Not all enterprise resources are on enterprise-owned infrastructure.
      • Remote enterprise subjects and assets cannot fully trust their local network connections.
      • Assets and workflows moving between enterprise and non-enterprise infrastructure should have a consistent security policy and posture.

      Now that you understand the VirnetX SDNS technology and Zero Trust principles let’s discuss how the VirnetX Matrix utilizes VirnetX SDNS to implement Zero Trust Networking:

      • VirnetX Matrix secures all network communications behind Secure Domain Names regardless of the network location.
      • All usage of VirnetX Matrix requires authentication of the endpoint devices and users of those devices.
      • VirnetX Matrix allows organizations to define rich security policies for granting access to secured applications.
      • In addition to putting a dynamic encrypted tunnel in place for all communications to a secured application. The organization admin specifically limits the network ports available to the accessing devices providing a high degree of network segmentation to only what is needed for access to a specific application (User & Device Isolation)
      • VirnetX Matrix has features that allow the organization's network administration to monitor endpoint devices and network utilization to ensure the integrity and security posture of assets.
      • VirnetX Matrix collects information on devices and network communications to improve the security posture.
      • Because VirnetX Matrix encrypts end-to-end all communications from clients to servers regardless of their location on the network, there is implicitly no trust in the underlying local network or any network or underlying infrastructure.
      • VirnetX Matrix integrates SDNS with Zero Trust principles (the most basic underlying protocol which starts all communication on the Internet).

      How Does VirnetX Matrix Implement SDNS Zero Trust to Keep You Safe

      Let’s discuss external network threats. We’ve all received automated auto-dialer marketing phone calls. A similar approach is used by hackers to automate discovery of known vulnerabilities on servers. Applications running on HTTP (TCP port 80) or HTTPS (TCP port 443) will commonly see repeated attempts to exploit known vulnerabilities, shell shock, Log4Shell (and many others). SSH servers running (TCP 22 or another non-standard port) and RDP servers (TCP port 3389) will see attempts to log in with common usernames/passwords.

      When VirnetX Matrix is placed in front of these apps, the listening IP addresses and ports are no longer reachable from the Internet by third parties. They can only be reached by VirnetX Matrix authenticated users through a VPN tunnel. So, these applications become “invisible” on the Internet and are not attackable by automated attacks.

      A more dangerous attack is an adversary who is not running a robot attack, but is specifically targeting your application knowing the domain name associated with your application. In this case the adversary will receive the response “name not found” when they attempt to get the IPv4 address associated with your application. They don’t know if your application is available on the Internet or where it is hosted, in fact they see no evidence that the application even exists.

      With external attacks blocked the attackers only way to attack your application is to compromise one of your legitimate users and attack the application through their authenticated device. In this case VirnetX Matrix is tracking user device and network communications attributes to also block the compromised insider attack of the application.

      Where Can You Deploy VirnetX Matrix SDNS Zero Trust

      Most organizations have applications that fit into three categories:

      1. Publicly Available Applications: Your organization needs to have publicly available on the Internet for reaching new customers (i.e., your organization’s public website).
      2. 3rd party SaaS Applications (Microsoft 365, Google Workspace, DropBox, SalesForce, etc.)
      3. Self-Hosted Applications that are either on premise or on your own Virtual Private Cloud (VPC).

      VirnetX secures category number 3, Self-Hosted Applications. Examples of common applications VirnetX protects include:

      1. Private File Servers
      2. Private Web Servers \ Application Servers
      3. Database Servers
      4. SSH (Secure Shell)
      5. RDP (Remote Desktop)
      6. VNC (Virtual Network Server)
      7. DevOps Systems (Environments used by developers to develop, test and deploy software products)
      8. Internal Messaging Servers (Chat, SMS)
      9. Mail \ Groupware Servers (POP3/IMAP/SMTP/Exchange Server)
      10. Security Camera Concentrators
      11. Bastion Hosts (Hardened Command and Control Systems)

      VirnetX One and VirnetX Matrix are an important layer for all applications that are considered highly sensitive and require additional protection from your security team. VirnetX does not eliminate the need for baseline security tools such as endpoint device protection, security patch management, identity management, application firewalls, and security incident event management (SIEM) that protect all your networks. VirnetX integrates seamlessly into your existing security infrastructure and enables the highest possible level of security for your most sensitive applications.