fix(networking): Add absolute FQDNs (trailing dot) to VirtualHost domains by ankushagarwal · Pull Request #56008 · istio/istio

ankushagarwal · 2025-04-18T16:37:50Z

Description:

This PR fixes an issue where Istio's outbound route configuration (RouteConfiguration) did not include the absolute/fully qualified domain name (FQDN) variant (e.g., my-service.my-ns.svc.cluster.local.) in the domains list for VirtualHost entries.

Updated the TestGenerateVirtualHostDomains test to verify new functionality

Problem:

When clients make requests using the absolute FQDN (with the trailing dot) in the Host header, Envoy would fail to match this against the specific VirtualHost domains generated by Istio. This caused such requests to fall back to the wildcard (*) virtual host, typically resulting in routing to the PassthroughCluster or BlackHoleCluster instead of the intended service cluster and associated Istio policies (like VirtualServices, DestinationRules).

Example scenario from issue report:

curl http://foo.bar.svc.cluster.local/ -> Correctly matches outbound|80||foo.bar.svc.cluster.local
curl http://foo.bar.svc.cluster.local./ -> Incorrectly matches PassthroughCluster

Solution:

The generateVirtualHostDomains function in pilot/pkg/networking/core/route.go has been modified to explicitly add the absolute FQDN variant (hostname + ".") to the list of generated domains for each service hostname and alias, provided the name is not an IP address.

Fixes #56007

…ains **Description:** This PR fixes an issue where Istio's outbound route configuration (`RouteConfiguration`) did not include the absolute/fully qualified domain name (FQDN) variant (e.g., `my-service.my-ns.svc.cluster.local.`) in the `domains` list for `VirtualHost` entries. Updated the TestGenerateVirtualHostDomains test to verify new functionality **Problem:** When clients make requests using the absolute FQDN (with the trailing dot) in the `Host` header, Envoy would fail to match this against the specific `VirtualHost` domains generated by Istio. This caused such requests to fall back to the wildcard (`*`) virtual host, typically resulting in routing to the `PassthroughCluster` or `BlackHoleCluster` instead of the intended service cluster and associated Istio policies (like VirtualServices, DestinationRules). Example scenario from issue report: - `curl http://foo.bar.svc.cluster.local/` -> Correctly matches `outbound|80||foo.bar.svc.cluster.local` - `curl http://foo.bar.svc.cluster.local./` -> Incorrectly matches `PassthroughCluster` **Solution:** The `generateVirtualHostDomains` function in `pilot/pkg/networking/core/route.go` has been modified to explicitly add the absolute FQDN variant (`hostname + "."`) to the list of generated domains for each service hostname and alias, provided the name is not an IP address.

linux-foundation-easycla · 2025-04-18T16:37:54Z

The committers listed above are authorized under a signed CLA.

✅ login: ankushagarwal / name: Ankush Agarwal (4770e24, fe373b5, 76b477b, 0bb24c4, 7eabec6)

istio-policy-bot · 2025-04-18T16:37:55Z

😊 Welcome @ankushagarwal! This is either your first contribution to the Istio istio repo, or it's been
a while since you've been here.

You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

istio-testing · 2025-04-18T16:38:02Z

Hi @ankushagarwal. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

keithmattix · 2025-04-18T16:44:19Z

/ok-to-test

keithmattix · 2025-04-18T16:48:25Z

Looks like this is certainly legal according to the RFC: https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2. I'm curious why we haven't allowed this in the past; I'll let @ramaraochavali @hzxuzhonghu or @howardjohn explain this fence for me :)

howardjohn

This makes sense to me. I cannot think of what this would break but I suppose its possible there is some edge case not considered... may be best put an on-by-default feature flag around this just in case?

cc @ramaraochavali

howardjohn · 2025-04-18T19:04:08Z

pilot/pkg/networking/core/httproute.go

 	for _, s := range all {
+		// Check if 's' is an IP address. We don't add trailing dots to IPs.
+		isIP := net.ParseIP(s) != nil
+		// Add the absolute FQDN variant (with trailing dot) if it's not an IP address.


nit: does this make sense under GenerateAltVirtualHosts since its basically an alt host?

I think it makes sense to move there

ramaraochavali · 2025-04-19T09:31:43Z

LGTM. Add feature flag with default true

…st expected results

ankushagarwal · 2025-04-19T14:52:34Z

Thank you for the feedback @ramaraochavali and @howardjohn - moved to GenerateAltVirtualHosts and added a default true feature flag - PILOT_ENABLE_ABSOLUTE_FQDN_VHOST_DOMAIN

sridhargaddam

Please add a release note.

sridhargaddam · 2025-04-19T16:38:47Z

pilot/pkg/features/pilot.go

+		"If set to true, Istio will add the absolute FQDN variant (e.g., my-service.my-ns.svc.cluster.local.) "+
+			"to the domains list for VirtualHost entries. Defaults to true, enabling the addition.",


Since the default value is true, lets modify the description to...

Suggested change

"If set to true, Istio will add the absolute FQDN variant (e.g., my-service.my-ns.svc.cluster.local.) "+

"to the domains list for VirtualHost entries. Defaults to true, enabling the addition.",

"If set to false, Istio will not add the absolute FQDN variant (e.g., my-service.my-ns.svc.cluster.local.) to the domains list for VirtualHost entries.",

istio-testing · 2025-04-20T15:04:42Z

@ankushagarwal: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
integ-ambient-mc_istio	`7eabec6`	link	false	`/test integ-ambient-mc`

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

ankushagarwal · 2025-04-20T15:05:22Z

Added release notes, fixed lint, updated the description of the flag

sridhargaddam

Thank you @ankushagarwal

…ains (istio#56008) * fix(networking): Add absolute FQDNs (trailing dot) to VirtualHost domains **Description:** This PR fixes an issue where Istio's outbound route configuration (`RouteConfiguration`) did not include the absolute/fully qualified domain name (FQDN) variant (e.g., `my-service.my-ns.svc.cluster.local.`) in the `domains` list for `VirtualHost` entries. Updated the TestGenerateVirtualHostDomains test to verify new functionality **Problem:** When clients make requests using the absolute FQDN (with the trailing dot) in the `Host` header, Envoy would fail to match this against the specific `VirtualHost` domains generated by Istio. This caused such requests to fall back to the wildcard (`*`) virtual host, typically resulting in routing to the `PassthroughCluster` or `BlackHoleCluster` instead of the intended service cluster and associated Istio policies (like VirtualServices, DestinationRules). Example scenario from issue report: - `curl http://foo.bar.svc.cluster.local/` -> Correctly matches `outbound|80||foo.bar.svc.cluster.local` - `curl http://foo.bar.svc.cluster.local./` -> Incorrectly matches `PassthroughCluster` **Solution:** The `generateVirtualHostDomains` function in `pilot/pkg/networking/core/route.go` has been modified to explicitly add the absolute FQDN variant (`hostname + "."`) to the list of generated domains for each service hostname and alias, provided the name is not an IP address. * Move the fqdn dot suffix logic to GenerateAltVirtualHosts, reorder test expected results * Add PILOT_ENABLE_ABSOLUTE_FQDN_VHOST_DOMAIN feature flag * Update tests * [release-notes] Add release note, fix lint

* upstream/master: remove 1.23 compatibility profile (istio#56023) Create ambient multinetwork flag (istio#55991) krt: make krt and kube client indexes named (istio#55999) Automator: update proxy@master in istio/istio@master (istio#56026) fix istio-revision-tag-default MutatingWebhookConfigurations is not created during installation (istio#56004) doc: fix typo in accesslog test (istio#55117) fix(networking): Add absolute FQDNs (trailing dot) to VirtualHost domains (istio#56008)

…12644) ## Summary `matchHostName` in `RoutingUtils` and `XdsNameResolver` currently rejects hostnames and patterns with a trailing dot (`.`) via `checkArgument`. A trailing dot denotes a **Fully Qualified Domain Name (FQDN)** as defined in [RFC 1034 Section 3.1](https://www.rfc-editor.org/rfc/rfc1034#section-3.1), and is a valid, well-defined representation of an absolute domain name. Rejecting it is inconsistent with the RFC. This change removes the trailing-dot rejection and adds normalization to strip the trailing dot before matching, making `example.com.` and `example.com` match equivalently. ## Background Per [RFC 1034 Section 3.1](https://www.rfc-editor.org/rfc/rfc1034#section-3.1): > "If the name ends with a dot, it is an absolute name ... For example, `poneria.ISI.EDU.`" A trailing dot simply indicates that the name is rooted at the DNS root and is semantically equivalent to the same name without the trailing dot. Treating it as invalid prevents legitimate FQDNs from being used as hostnames or virtual host domain patterns in xDS routing configuration. ## Motivation This was discovered when using gRPC Proxyless Service Mesh on a Kubernetes cluster with Istio. The issue surfaced after upgrading Istio from 1.26.8 to 1.28.3. The Istio change [istio/istio#56008](istio/istio#56008) began sending FQDN-style domain names (with trailing dots) in xDS route configuration, which caused grpc-java to throw an `IllegalArgumentException` in `matchHostName`: ```text java.lang.IllegalArgumentException: Invalid pattern/domain name at com.google.common.base.Preconditions.checkArgument(Preconditions.java:143) ``` The root cause is that grpc-java's `matchHostName` was not RFC-compliant in rejecting trailing dots — the Istio upgrade merely made it visible. The fix here is to bring grpc-java into compliance with RFC 1034, independent of any specific Istio version. ## Changes - `xds/src/main/java/io/grpc/xds/RoutingUtils.java`: Removed trailing-dot rejection and added FQDN normalization in `matchHostName`. - `xds/src/main/java/io/grpc/xds/XdsNameResolver.java`: Same as above. - `xds/src/test/java/io/grpc/xds/XdsNameResolverTest.java`: Added `matchHostName_trailingDot` test covering exact match, prefix wildcard, and suffix wildcard with trailing dot combinations. ## References - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - [istio/istio#56008](istio/istio#56008) – Istio change that began sending FQDN domain names in xDS configuration

…rpc#12644) ## Summary `matchHostName` in `RoutingUtils` and `XdsNameResolver` currently rejects hostnames and patterns with a trailing dot (`.`) via `checkArgument`. A trailing dot denotes a **Fully Qualified Domain Name (FQDN)** as defined in [RFC 1034 Section 3.1](https://www.rfc-editor.org/rfc/rfc1034#section-3.1), and is a valid, well-defined representation of an absolute domain name. Rejecting it is inconsistent with the RFC. This change removes the trailing-dot rejection and adds normalization to strip the trailing dot before matching, making `example.com.` and `example.com` match equivalently. ## Background Per [RFC 1034 Section 3.1](https://www.rfc-editor.org/rfc/rfc1034#section-3.1): > "If the name ends with a dot, it is an absolute name ... For example, `poneria.ISI.EDU.`" A trailing dot simply indicates that the name is rooted at the DNS root and is semantically equivalent to the same name without the trailing dot. Treating it as invalid prevents legitimate FQDNs from being used as hostnames or virtual host domain patterns in xDS routing configuration. ## Motivation This was discovered when using gRPC Proxyless Service Mesh on a Kubernetes cluster with Istio. The issue surfaced after upgrading Istio from 1.26.8 to 1.28.3. The Istio change [istio/istio#56008](istio/istio#56008) began sending FQDN-style domain names (with trailing dots) in xDS route configuration, which caused grpc-java to throw an `IllegalArgumentException` in `matchHostName`: ```text java.lang.IllegalArgumentException: Invalid pattern/domain name at com.google.common.base.Preconditions.checkArgument(Preconditions.java:143) ``` The root cause is that grpc-java's `matchHostName` was not RFC-compliant in rejecting trailing dots — the Istio upgrade merely made it visible. The fix here is to bring grpc-java into compliance with RFC 1034, independent of any specific Istio version. ## Changes - `xds/src/main/java/io/grpc/xds/RoutingUtils.java`: Removed trailing-dot rejection and added FQDN normalization in `matchHostName`. - `xds/src/main/java/io/grpc/xds/XdsNameResolver.java`: Same as above. - `xds/src/test/java/io/grpc/xds/XdsNameResolverTest.java`: Added `matchHostName_trailingDot` test covering exact match, prefix wildcard, and suffix wildcard with trailing dot combinations. ## References - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - [istio/istio#56008](istio/istio#56008) – Istio change that began sending FQDN domain names in xDS configuration

ankushagarwal requested a review from a team as a code owner April 18, 2025 16:37

istio-policy-bot added area/networking release-notes-none Indicates a PR that does not require release notes. labels Apr 18, 2025

istio-testing added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. needs-ok-to-test labels Apr 18, 2025

istio-testing added ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member. and removed needs-ok-to-test labels Apr 18, 2025

howardjohn reviewed Apr 18, 2025

View reviewed changes

ankushagarwal added 2 commits April 19, 2025 07:43

Move the fqdn dot suffix logic to GenerateAltVirtualHosts, reorder te…

4770e24

…st expected results

Add PILOT_ENABLE_ABSOLUTE_FQDN_VHOST_DOMAIN feature flag

0bb24c4

ankushagarwal requested a review from a team as a code owner April 19, 2025 14:50

Update tests

fe373b5

istio-testing added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Apr 19, 2025

sridhargaddam reviewed Apr 19, 2025

View reviewed changes

[release-notes] Add release note, fix lint

7eabec6

sridhargaddam approved these changes Apr 20, 2025

View reviewed changes

ramaraochavali approved these changes Apr 21, 2025

View reviewed changes

istio-testing merged commit ce55506 into istio:master Apr 21, 2025
29 of 30 checks passed

PetitBaguette mentioned this pull request Feb 4, 2026

fix(xds): Allow and normalize trailing dot (FQDN) in matchHostName grpc/grpc-java#12644

Merged

		"If set to true, Istio will add the absolute FQDN variant (e.g., my-service.my-ns.svc.cluster.local.) "+
		"to the domains list for VirtualHost entries. Defaults to true, enabling the addition.",

	"If set to true, Istio will add the absolute FQDN variant (e.g., my-service.my-ns.svc.cluster.local.) "+
	"to the domains list for VirtualHost entries. Defaults to true, enabling the addition.",
	"If set to false, Istio will not add the absolute FQDN variant (e.g., my-service.my-ns.svc.cluster.local.) to the domains list for VirtualHost entries.",

Conversation

ankushagarwal commented Apr 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linux-foundation-easycla bot commented Apr 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

istio-policy-bot commented Apr 18, 2025

Uh oh!

istio-testing commented Apr 18, 2025

Uh oh!

keithmattix commented Apr 18, 2025

Uh oh!

keithmattix commented Apr 18, 2025

Uh oh!

howardjohn left a comment

Choose a reason for hiding this comment

Uh oh!

howardjohn Apr 18, 2025

Choose a reason for hiding this comment

Uh oh!

ramaraochavali Apr 19, 2025

Choose a reason for hiding this comment

Uh oh!

ramaraochavali commented Apr 19, 2025

Uh oh!

ankushagarwal commented Apr 19, 2025

Uh oh!

sridhargaddam left a comment

Choose a reason for hiding this comment

Uh oh!

sridhargaddam Apr 19, 2025

Choose a reason for hiding this comment

Uh oh!

istio-testing commented Apr 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ankushagarwal commented Apr 20, 2025

Uh oh!

sridhargaddam left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

ankushagarwal commented Apr 18, 2025 •

edited

Loading

linux-foundation-easycla bot commented Apr 18, 2025 •

edited

Loading

istio-testing commented Apr 20, 2025 •

edited

Loading