VOS FQDN-type Address object options explained
Version 1.0 Author: Andrey BazovkinIntroduction
VOS provides option for using FQDNs in Address objects, which then can be used in match criteria in different policies.
Below in this article each FQDN subtype option will be explained in details, together with possible use scenarios.
Information in this article is applicable to Versa Director/VOS version 21.2.3 and later.
FQDN Address objects types overview
FQDN-type address objects can be used the same way as IP address objects as match criteria in different policies, for example, SD-WAN or NGFW policies. Address object configuration window in Versa Director provides single type for FQDN address objects:
However depending on the value in ‘FQDN’ field, there are following subtypes of FQDN-type address objects:
1. Regular – contains precise FQDN (like domain.com), which uniquely identifies certain domain. Once configured as address object, VOS will try to resolve this FQDN using DNS servers in all available VRs, whatever configured in Others->System->Domain Name Servers section. If used as match criteria, resolved IP address(es) are used in fact, so flow match is possible from the first packet. If different DNS servers are used on VOS and on endhosts, FQDN->IP resolution may provide different results. Doesn’t require DNS proxy, however if used in conjunction with DNS Proxy, VOS will precisely know to which IP this FQDN was resolved to the endhost.
2. Regex – contains regex pattern of FQDN, so potentially may match indefinite number of domains (like domain.com and all its subdomains). Because of this it’s not possible to resolve it in advance using system DNS setting, and instead DNS Proxy needs to be enabled on VOS, so VOS can learn all IP addresses for FQDNs matching the regex pattern. If used as match criteria, resolved IP address(es) are used in fact, so flow match is possible from the first packet.
Notes on enabling DNS proxy for Regex FQDN-type address objects
• DNS Proxy needs to be enabled on VOS, so it can learn all IP addresses for FQDNs matching the regex pattern
• FQDNs to be learnt need to match pattern of DNS Redirection rule with Proxy profile assigned. Other FQDNs can be skipped there (or used with “None” action in Redirection rule). Example: if needed to breakout traffic destined to FQDN domain1.com locally, DNS Redirection rule needs to be configured, which will match domain1.com as Query in “DNS Header match” tab, and use DNS Proxy profile with some Internet DNS server for it. In this case remaining DNS queries will remain untouched and go to DNS servers configured on endhost.
• Internal company DNS traffic can be skipped from DNS Redirection rules at all, if no FQDN-based actions are required for internal traffic.
• Please, see Appendix#2 in this article for more details on DNS Proxy configuration.
FQDN-type address objects vs. URL matching
FQDN-type address objects are in fact interpreted by VOS as IP addresses, to which they were resolved, in match criteria. So if FQDN1 resolves to IP1, and FQDN2 resolves to the same IP1, then both FQDN1 and FQDN2 will always be matched together irrespective which one is put in match criteria.
If precise URL matching is required, URL-based match should be used instead of FQDN matching, or alternatively FQDN matching can be complemented with URL filtering.URL matching has following differences compared to FQDN matching:
• Applicable for http/https protocols only. For https connections URL matching is possible only on SNI (hostname) field (the same as for FQDN), while full URL match is possible only with decryption enabled.
• It’s not possible to retrieve even hostname for QUIC-based sessions at all, so QUIC protocol needs to be blocked in order to force clients and servers to fallback to normal https.
• First packet match is not possible – tcp connection needs to be fully established first to start http/https exchange. Eventual SD-WAN rule with URL category match may not be applied to the first session, so if there is no alternate routing-based path, connection may fail to be established at all. However this limitation can be overcome, by for example, using FQDN matching in SD-WAN policy and URL filtering in NGFW policy.
• URL matching itself doesn’t require DNS Proxy or DNS Server configuration on VOS.
Appendix#1. Regex examples for FQDN patterns
(.*\.|^)domain.com – it will match domain.com and any its subdomains
(.*\.|^)domain.(org|net|com) – it will match domain.org, domain.net, domain.com and any their subdomains ^www.domain.com – it will match precisely www.domain.com
Some syntax explanations:
^ – beginning of the line
. – any character, .* – any character any times (incl. 0 times)
\ – escape character, so to get a dot you need to use \., to get a slash you need to use \/
(a|b) – a or b
Appendix#2. DNS Proxy configuration overview for FQDN-type address objects
As mentioned in Section#2 of this article, VOS requires DNS Proxy to be able to resolve IPs for Regex FQDN-type address objects to use them in match criteria. DNS Proxy can also be used together with Regular FQDN-type address objects – this will ensure that VOS has the same resolution for them as endhosts. Detailed information on how to configure DNS Proxy on VOS can be found in the corresponding article on Versa Documentation portal Below are quick summary steps on what needs to be done (at minimum) to configure DNS Proxy for FQDN-type address objects resolution:1. Configure SNAT Pool, which will be used to send requests to DNS Server (Objects -> SNAT Pool):
2. Configure DNS Proxy Profile (Networking -> DNS -> Proxy Profiles) with resolver containing DNS server(s), which you want to use for DNS request redirection:
3. Configure DNS Redirection Policy (Networking -> DNS -> Policies) with rules matching FQDNs, whose IPs need to be learnt by VOS. For this in match criteria select “DNS Header match”, opcode – Query, and list regex for desired FQDNs:
