What is a domain label and how can I use it in conjunction with an in-path rule

What are domain label requirement and limitations? How can domain labels be used in conjunction with an in-path rules.

A domain label is an augmentation for further refining an in-path rule by using the domain name field. For example, rather than specifying multiple IP addresses or FQDN in the destination field, you can use *.ABC.com to intercept only destination hosts matching these criteria. A domain label field can also lessen the number of hosts to optimize, or exclude from optimization, in case the field does not match the domain label and the other source or destination fields. The domain label field does not replace the destination IP address parameter. The in-path rule needs to match the destination IP address or host label field, and next match the domain label entry. If the connection matches the source and destination list, the client-side SteelHead begins to process subsequent data packets looking to match the domain in the host field if HTTP or the SNI field in HTTPS.

With a domain label you can selectively perform:
 

• Dual-ended optimization of individual services on an onpremise server running multiple applications.
• Web-proxy optimization of individual domain of HTTP/HTTPS web proxy traffic in single-ended deployment.

Note: Domain Label rules are not compatible with optimized SAAS in-path rules.
Normal SteelHead operation with in-path rules, elect that if you mismatch on the source and/or destination IP/Port (and/or Host Label), then the connection tries to match the subsequent in-path rules in the list. But when a Domain Label is a parameter in the in-path rule and there is a mismatch on the Domain Label field, next in-path rule logic may not necessarily apply.

For example:
 

• If a rule containing a domain label rule, and becomes a mismatch on the domain, then the following rule it is set to match is a cloud-acceleration rule. In this situation SAAS cloud optimization will not take place. It is advised to place SAAS cloud optimization in path rules prior to any domain label rules
• If a fixed-target rule containing a domain label becomes a mismatch on the domain but the following rule it is set to match an autodiscover rule. In this situation, no optimization of that flow will take place. It is advised to construct the fixed target rule to a narrow set of IP addresses you intend to match on instead of a wide subnet scope matching on a multitude of addresses. This is so to limit the exposure of the fixed target rule across a broad scope of addresses.
• If you are configuring a domain label inpath rule and there is a mismatch on the domain field the default (pre-built) optimization rule does not apply. It is required to configure a last resort inpath rule to optimize traffic when a Domain Label rule is configured in any of the inpath rules (create a new catch all optimization rule, even if the default rule is identical to the one you are creating). This is needed to optimize the traffic.
   

Use the following guideline when creating a domain label:
 

• Riverbed recommends that you configure a domain label as the last rule in the listing.
• For optimized traffic, both the client-side and server-side SteelHeads must be running RiOS 9.2 or later.
• Domain labels are not compatible with packet mode optimization.
• Domain label names are alphanumeric.
• Domain label names cannot be more than 64 characters long.
• You can create a maximum of 63 domain labels.
• The default destination ports are 80 and 443 unless manually specified in the in-path rule.
• Domain labels are compatible with IPv4 only.
• Domain labels introduce a new Enhanced Autodiscovery Process (EADX)
• Place an in-path rules using domain label and destination address set to All at the end of the rule list.
• Domain labels are not supported on the source subnet field.
• The web proxy feature is compatible with domain label rule lists. For more information about web proxy, see SteelCentral Controller for SteelHead Deployment Guide.
• Domain labels allow you to specify an Internet domain with wildcards to define a wider group, such as *.ABC.com.
• By default, domain labels support only HTTP-based and HTTPS-based traffic (ports 80 and 443). For HTTP, the domain label feature looks at the Host field in the GET request to find a match with the configured domains. For HTTPS, the domain label looks at the SNI field of the Client Hello.
• SteelHead SaaS optimization is bypassed in the presence of a rule defined with a domain label and destination set to All.

The following table shows domain label usage supportability with various deployment options:

RiOS 9.2