This article explains how to configure DNS Proxy with the honour-pbf option to intelligently steer DNS queries based on SD-WAN policy decisions.

This is useful when DNS queries for:

  • External domains
  • Specific SaaS domains (for example: Office365, Salesforce, Dropbox)

need to follow the same SD-WAN path selection logic used for application traffic.

The goal is to ensure DNS queries are forwarded over the optimal path determined by SD-WAN policy (PBF), rather than being statically tied to a single SNAT egress path.


Overview

A DNS Proxy profile provides split DNS functionality.

Typically, DNS Proxy is configured to:

  • Forward internal enterprise domains to an internal DNS server (for example, behind HQ)
  • Forward external/public domains to public DNS resolvers (for example, Google DNS 8.8.8.8, OpenDNS)

By default, the path used to send the DNS query is determined by the SNAT pool associated with the DNS Proxy resolver.


Default Behavior

If the SNAT pool is associated with a specific WAN interface (for example, LBO1), DNS queries can only be sent through that interface.

This means:

  • DNS path selection is static
  • SD-WAN policy is not consulted
  • DNS may not follow the same optimal path as application traffic


What honour-pbf Does

When honour-pbf is enabled in the DNS Proxy policy, the DNS Proxy performs an SD-WAN policy lookup before forwarding the DNS query.

This allows the DNS query to follow the same Policy-Based Forwarding (PBF) logic as application traffic.


Result

DNS Proxy can now:

  • Inspect the DNS query
  • Match the domain
  • Consult SD-WAN policy
  • Determine the preferred path
  • Forward the DNS query over the correct WAN path

This ensures DNS queries for SaaS applications (such as Office365, Salesforce, Dropbox) are sent over the same preferred path that application traffic will later use.


Why This Matters

In traditional DNS steering, the DNS query and the application session are handled independently.

This can create sub-optimal traffic behavior.


Example Problem

For Salesforce traffic:

  • DNS query may be sent over HUB/CBO
  • Actual HTTP/HTTPS session may be sent over LBO1 or LBO2

This can result in:

  • Non-optimal DNS resolution
  • Incorrect CDN endpoint selection
  • Increased latency
  • Poor SaaS performance


Strict DNS Path Affinity

To solve this, enable Strict DNS Path Affinity.

Strict DNS Path Affinity ensures that:

  • DNS query path selection
  • Subsequent HTTP/HTTPS session path selection remain consistent.


How It Works

When enabled, Versa creates cache entries that bind:

  • Client
  • Resolved destination
  • Path used for DNS query

Subsequent application sessions are then pinned to the same path.

This ensures:

  • DNS and application traffic follow the same path
  • Optimal SaaS edge selection
  • Improved user experience


Use Case

DNS Proxy with honour-pbf enabled should:

  • Redirect DNS queries for: 
    • Office365
    • Salesforce
    • Dropbox
  • Match those domains against SD-WAN policy
  • Determine the preferred path
  • Forward the DNS query accordingly

Traffic Steering Requirements


Office365 and Salesforce

  • Primary paths: Internet1 and Internet2
  • Behavior: Load-balanced across both links
  • Failover path: HUB1/CBO

Dropbox

  • Primary path: Internet2
  • Secondary path: Internet1
  • Tertiary path: HUB1/CBO

Configuration

Step 1: Enable Application Detection and Application Steering

Enable:

  • Application Detection
  • Application Steering

Under Session Pinning, enable:

  • Domain App Cache

This enables Strict DNS Path Affinity.


What This Does

Versa creates Client Route Cache (CRC) entries to preserve DNS-to-application path affinity.

Example:

  • Client1 sends DNS query → destination resolved → DNS sent via Path1
  • Client2 sends DNS query → destination resolved → DNS sent via Path2

Subsequent HTTP/HTTPS sessions matching the CRC entry will use the same path.

 

Benefit

This ensures:

  • DNS query
  • Subsequent application session

are sent over the same WAN path.


Note
 CRC entries are created only when DNS Proxy is configured with honour-pbf.


Step 2: Create SNAT Pool

Navigate to:

Configurations → Object & Connectors → Objects → SNAT Pool

Create an SNAT pool for DNS Proxy.

CLI Configuration

set orgs org-services Customer2 objects snat dns-proxy-pool egress-networks [ CUST2 ]
 set orgs org-services Customer2 objects snat dns-proxy-pool routing-instance Customer2-LAN-VR


Step 3: Create DNS Proxy Profile

Navigate to:

Configurations → Networking → DNS → Proxy Profiles

Create a DNS Proxy Profile with:

  • Primary resolver via local breakout (LBO)
  • Secondary resolver via HUB1/CBO

This ensures DNS resolution remains available regardless of path selection.


CLI Configuration

set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external mode fail-over
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver dns-profile-external mode round-robin
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver dns-profile-external servers external address 8.8.8.8
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver dns-profile-external servers external port 53
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver dns-profile-external servers external monitor true
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver dns-profile-external snat-pool dns-proxy-pool
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver ExternalViaHUB site-name CUST2-HUB1
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver ExternalViaHUB mode fail-over
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver ExternalViaHUB servers externalviaHUB address 8.8.8.8
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver ExternalViaHUB servers externalviaHUB port 53
set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver ExternalViaHUB servers externalviaHUB monitor true
 set orgs org-services Customer2 dns-proxy proxy-profiles dns-profile-external resolver ExternalViaHUB snat-pool dns-proxy-pool


Step 4: Create DNS Proxy Redirection Policy

Navigate to:

Configurations → Networking → DNS → Policies

Configure a redirection policy to:

  • Match DNS requests
  • Redirect matching domains
  • Apply DNS Proxy profile
  • Enable honour-pbf


Matching Criteria

Leave DNS Headers Match as default to match all DNS queries, or specify selective domains for redirection.

Important

Enable:

  • Apply Policy Based Forwarding

This is mandatory for DNS Proxy to consult SD-WAN policy before forwarding DNS traffic.

CLI Configuration

set orgs org-services Customer2 dns-proxy redirection-policy Default-Policy rules Rule-External match dns-header-matches opcode query qtype-domain-match match1 domain-name .*.office.com
set orgs org-services Customer2 dns-proxy redirection-policy Default-Policy rules Rule-External match dns-header-matches opcode query qtype-domain-match match2 domain-name .*.salesforce.com
set orgs org-services Customer2 dns-proxy redirection-policy Default-Policy rules Rule-External match dns-header-matches opcode query qtype-domain-match match3 domain-name .*.dropbox.com
set orgs org-services Customer2 dns-proxy redirection-policy Default-Policy rules Rule-External match source user user-type any
set orgs org-services Customer2 dns-proxy redirection-policy Default-Policy rules Rule-External match source zones [ Intf-CUST2-Zone ]
set orgs org-services Customer2 dns-proxy redirection-policy Default-Policy rules Rule-External set action proxy profile dns-profile-external
set orgs org-services Customer2 dns-proxy redirection-policy Default-Policy rules Rule-External set action proxy honour-pbf true
set orgs org-services Customer2 dns-proxy redirection-policy Default-Policy rules Rule-External set lef profile-default false
 set orgs org-services Customer2 dns-proxy redirection-policy Default-Policy rules Rule-External set lef profile Default-Logging-Profile


Step 5: Create SD-WAN Policy

Create SD-WAN policy rules that define application-aware PBF behavior for:

  • Office365
  • Salesforce
  • Dropbox

These SD-WAN rules determine which path DNS queries and application traffic should use.

Example Behavior

  • Office365 / Salesforce → Load balance across LBO1 and LBO2, fail over to HUB1/CBO
  • Dropbox → Prefer LBO2, then LBO1, then HUB1/CBO

Note
 These DNS Proxy configurations also apply to SaaS DIA optimization over LBO and CBO.


Verification

DNS Proxy Profile Status

admin@CUST2-BRANCH1-cli> show orgs org-services Customer2 dns-proxy profile-monitor proxy-profile dns-profile-external
PROFILE NAME RESOLVER NAME SERVER NAME STATUS
--------------------------------------------------------------------
dns-profile-external dns-profile-external external UP
                       ExternalViaHUB        externalviaHUB  UP


DNS Proxy Statistics

admin@CUST2-BRANCH1-cli> show orgs org-services Customer2 dns-proxy statistics proxy-profiles dns-profile-external
FAILED
SESS FAILED FAILED
NO FAILED SESS SESS TOTAL TOTAL TOTAL TOTAL
SUCCESSFUL FAILED DEST SESS NO SERVER PKT BYTES PKT BYTES
PROFILE NAME SESS SESS SERVER NO MEM SNAT FAIL SENT SENT RCVD RCVD
------------------------------------------------------------------------------------------------------
 dns-profile-external  22111       0        0       0       0        0       0      0       0      0


DNS Redirection Policy Statistics

admin@CUST2-BRANCH1-cli> show orgs org-services Customer2 dns-proxy statistics redirection-policy Default-Policy rules Rule-External
TCP UDP
HIT HIT HIT PBF CACHE
RULE NAME COUNT COUNT COUNT HONOURED HIT
-----------------------------------------------------
 Rule-External  22390  0       22390  17905     0

Interpretation

  • HIT COUNT confirms rule matches
  • PBF HONOURED confirms SD-WAN policy lookup was applied
  • This validates that DNS queries are being steered according to SD-WAN policy


Operational Verification

Domain Application Cache (DAC)

DAC entries bind:

  • Domain name
  • Application / URL category

This is used to map DNS domains to applications.


Application Route Cache (ARC)

ARC entries bind:

  • Resolved destination IP
  • Application / URL category

This allows Versa to classify subsequent traffic correctly.


Client Route Cache (CRC)

CRC entries bind:

  • Client
  • Resolved destination
  • Path used for DNS query

CRC is created because Domain App Cache session pinning is enabled.

This ensures:

  • DNS query path
  • HTTP/HTTPS session path

remain identical.


Note
 Office365 and Salesforce sessions should follow the same path indicated in CRC.


Traffic Flow Validation

Office365 and Salesforce

Expected result:

  • Sessions load-balanced across LBO1 and LBO2
  • Failover through HUB1/CBO

This confirms:

  • DNS query honored PBF
  • Application session followed CRC path affinity

 

Dropbox

Expected result:

  • Primary path: LBO2
  • Secondary path: LBO1
  • Tertiary path: HUB1/CBO

This confirms Dropbox traffic follows SD-WAN policy preference.

Note
 CRC entries should reflect the same path used by Dropbox sessions.

Key Takeaways

  • DNS Proxy with honour-pbf allows DNS traffic to follow SD-WAN path selection
  • This removes static DNS forwarding limitations tied to SNAT-only path selection
  • Strict DNS Path Affinity ensures DNS and application sessions follow the same path
  • This improves SaaS performance and ensures optimal edge selection
  • Particularly useful for: 
    • Office365
    • Salesforce
    • Dropbox
    • Other SaaS applications using selective SD-WAN steering

Best Practices

  • Always enable Apply Policy Based Forwarding in DNS redirection policy
  • Enable Domain App Cache under Session Pinning for strict DNS path affinity
  • Ensure DNS resolvers are reachable on all possible SD-WAN-selected paths
  • Use CRC verification to confirm DNS/application path consistency
  • Validate PBF HONOURED counters during troubleshooting

Summary

Enabling DNS Proxy with honour-pbf integrates DNS resolution with SD-WAN path selection logic.

This ensures:

  • DNS queries are SD-WAN aware
  • SaaS traffic uses optimal WAN paths
  • DNS and application traffic maintain path consistency
  • User experience improves through better SaaS routing and resolution

This is the recommended approach for SaaS-aware DNS steering in Versa SD-WAN.