DNS in Banyan

How DNS works within Banyan architecture

  • Updated on Aug 26, 2022
  • 5 minutes to read
  • Contributors

DNS Overview

Domain Name System (DNS) is a database that maps IP addresses to human-readable domain names. Its original purpose was simple: to help locate resources on the public internet. Over the years, its use has expanded considerably in both scale and complexity.

In this doc, we’ll lay out and explain the DNS architecture in Banyan, showing how it works within the context of Banyan’s use cases and deployment models.

Background

Deployment Models

Banyan supports two deployment models:

Domains
  • Registered domains in Banyan have been set up in public DNS to route to Banyan’s Access Tiers. This is required for published services, unless your org opts to tunnel DNS requests to your private DNS server.
  • Private domains are those that are configured to be resolved by your Private DNS. DNS requests for these domains are tunneled through to your network. This is commonly configured when using Service Tunnel.

DNS Resolution Flows for Service Tunnel

Service Tunnel is a VPN-as-a-Service built on WireGuard (an open source, modern VPN) that incorporates zero trust principles. Service Tunnel requires no DNS updates, as clients’ DNS queries tunnel through the Banyan Access Tiers and use private DNS for resolution.

In the diagram above, a client is trying to reach a private web server inside of a private network.

Note: bnn.local is configured as a private domain that indicates it should be resolved via private DNS.

  1. The client searches for a private web server on an organization’s private network (nginx.bnn.local). The Banyan app running on the client is aware of the organization’s private domains and has set local routes for the DNS request to be sent to the Access Tier.

  2. The Access Tier validates user and device trust and then sends the DNS request to the private DNS server for resolution.
    • Note If there is a published service for the resource being accessed, the Access Tier will automatically trigger the published service flow.
  3. The private DNS server returns the private IP address (10.0.1.2) of the web server.

  4. The Access Tier then initiates communication to the web server (nginx.bnn.local), tunneling traffic from the client.

In the diagram above, a client is trying to reach a private web server inside of a private network.

Note: bnn.local is configured as a private domain that indicates it should be resolved via private DNS.

  1. The client searches for a private web server on an org’s private network (nginx.bnn.local). The Banyan app running on the client is aware of the org’s private domains and has set local routes for the DNS request to be sent to the closest Access Tier in Banyan’s Global Edge Network.

  2. The Access Tier validates user and device trust, and then it passes the client’s request to the appropriate Connector. The Connector sends the DNS request to the private DNS server for resolution.
    • Note If there is a published service for the resource being accessed, the Access Tier will automatically trigger the published service flow.
  3. The private DNS server returns the private IP address (10.0.1.2) of the web server.

  4. The Connector then initiates communication with the web server (nginx.bnn.local), tunneling traffic from the client.

DNS Resolution Flows for Published Services

Published Services in Banyan, such as Hosted Websites and Infrastructure, allow for granular definition and assignment of access to private resources, in a least-privileged manner. In this approach, private resources are cloaked and “published” on the internet via public DNS. The published service is set up to route to Banyan’s Access Tiers for policy enforcement. This approach allows for seamless access by authorized users and devices, but it protects against access from non-authorized users.

A public wildcard DNS record is required unless orgs opt to tunnel DNS requests to their private DNS server.

In the diagram above, a client is searching for a web server in a private network.

Note: *.banyan.com is a Banyan registered domain with a public wildcard DNS record that routes URLs on that domain to the org’s Self-Hosted Edge Network.

  1. The client searches for a published web service (nginx.banyan.com).

  2. Since nginx.banyan.com is a published service, a public DNS server resolves the query and returns the public IP address of the org’s Access Tier (35.10.2.18).

  3. The client then reaches the Access Tier over the internet.

  4. The Access Tier is aware of the private domain of the published service (nginx.bnn.local) and queries the private DNS server.

  5. The private DNS server returns the private IP address (10.0.1.2) of the published service.

  6. The Access Tier reverse proxies the connection, granting the client access to the web server (nginx.bnn.local) only after validating user and device trust.

In the diagram above, a client wants to reach a private web server.

Note: *.banyan.com is a Banyan registered domain with a public wildcard DNS record that routes URLs on that domain to the Banyan Global Edge Network.

  1. The client searches for a published web service (nginx.banyan.com).

  2. Since nginx.banyan.com is a published service, a public DNS server resolves the query and returns the public IP address of the closest Access Tier (35.10.2.18) in Banyan’s Global Edge Network.

  3. The client then reaches the Access Tier over the Internet. The Access Tier validates user and device trust and then passes the client’s request to the appropriate Connector.

  4. The Connector is aware of the private domain of the published service (nginx.bnn.local) and queries the private DNS server.

  5. The private DNS server returns the private IP address (10.0.1.2) of the published service.

  6. The connection is reverse proxied through the Connector, granting the client access to the web server (nginx.bnn.local) only after validating user and device trust.

Can’t find what you’re looking for?

We’re happy to help. Contact our team.