What is covered in this document?
This document describes the usage and behavior of address objects with regex FQDN patterns. It also covers the DNS request path steering using address objects with FQDNs and regex-FQDNs.
The user should be able to configure an address object with an FQDN pattern (for example ‘*.salesforce.com’), and use it as a match condition in any policy rule (for example, an sdwan policy rule).
How does the current FQDN address object configuration look?
The current implementation of address objects allows to configure a FQDN like –
objects {
addresses {
ggl_addr_1 {
fqdn www.google.com;
}
}
}
What happens when a FQDN address object is configured?
The FQDN address objects are resolved by address manager daemon in ‘all’ the routing instances and the resolved IP addresses are pushed to vsmd (via vstate). The resolved IP addresses for the address object are maintained in internal data structures indexed by “address-name#routing-instance-name” and are associated with the object-id of the address object (which is a part of multi-match RFC lookup).
What changes have been done?
1. Address object can now be configured with regex fqdn and used in policy rule match conditions.
2. The DNS requests matching the fqdn/regex-fqdn will also be subjected to the same sdwan rules as the traffic matching the FQDN address.
How will the configuration for regex fqdn address object look like?
The regex fqdn address object can be configured like -
objects {
addresses {
ggl_addr_regex_1 {
fqdn .*google.com;
}
}
}
What patterns are allowed?
Hyperscan is used for pattern match, so ‘all’ the patterns supported by Hyper scan should work. It is same as the patterns allowed in configuration at other places like user defined url-categories.
We may qualify and recommend some pattern formats to be used by customers.
What all config operations are allowed on address objects?
All the regular config operations are allowed like –
· Addition and deletion.
· Modification to change the fqdn or fqdn pattern
· Modification to change from fqdn to fqdn pattern and vice versa.
· Modification to change address object type from fqdn to any non-fqdn type and vice versa.
What are the configuration requirements?
For the DNS requests and IP addresses from DNS responses to be matched with address-objects, dnsproxy needs to be configured.
Dnsproxy is also required for DNS request path selection using the address objects.
Why do we need to learn the IP addresses the domain names matching the configured address objects are resolving to?
Data path needs to map the session IP address to the identity of the address object that is used in the policy rules. This IP address to object-id mapping is learned by matching the domain-name in the DNS requests with the list of fqdn-patterns configured and caching the IP addresses from the DNS response and associating them with the object-ids of ‘all’ the address objects that match the domain-name.
This mapping is maintained per-worker-thread and per-tenant.
Can regex-fqdn objects be used when path selection for DNS requests is not required?
Yes, dnsproxy will help learn the IPs via DNS resolutions even when it is not configured to invoke SD-WAN/PBF based path selection for DNS requests.
How long are the IP addresses learnt via DNS resolutions kept in data-path?
As per the current implementation, the IP addresses are kept forever.
How many FQDN address objects can an IP address match with?
Maximum 16 fqdn pattern matches are supported.
Does it work for first session?
Yes, always for the first DNS resolution.
And very often for first-packet & first-session for data sessions. The inter thread communication delay in vsmd may cause a case where the data session hits the worker thread before the learnt IPs are processed. This might cause the rule match to be missed for the first session.
Will the DNS requests matching the regular FQDNobjects be snooped to cache the resolved IPs and object-ids?
Yes, regular FQDNs are also treated as a regex, and IPs and object-ids are learnt. This is because the DNS request for the client may be sent to a specific DNS server, which may differ from the one using which address-manager resolves the regular FQDNs.
Which all FQDN and regex FQDN objects will be matched while processing the DNS response?
All the objects that are being referenced by a policy rule in the configuration. Just configuring an address object will not trigger the IP address learning.
Is this change backward compatible?
Yes, except for path steering for DNS requests matching a FQDN address object when dnsproxy is configured to invoke PBF for path steering.
DNS request will now start following the rule based on address object match.