xds: Don't allow hostnames in address field #12123
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gRFC A27 specifies they must be IPv4 or IPv6 addresses. Certainly doing a DNS lookup hidden inside the config object is asking for trouble. The tests were accidentally doing a lot of failing DNS requests greatly slowing them down. On my desktop, which made the problem most obvious with five search paths in /etc/resolv.conf, :grpc-xds:test decreased from 66s to 29s. The majority of that is XdsDependencyManagerTest which went from 33s to .1s, as it generated a UUID for the in-process transport each test and then used it as a hostname, which defeated Java's DNS (negative) cache. The slowness was noticed because XdsDependencyManagerTest should have run quickly as a single thread without I/O, but was particularly slow on my desktop. The cleanup caused me to audit serverName and the weird places it went. I think some of them were tricks for XdsClientFallbackTest to squirrel away something distinguishing, although reusing the serverName is asking for confusion as is including the tricks in "shared" utilities. XdsClientFallbackTest does have some non-trivial changes, but this seems to fix some pre-existing bugs in the tests.
| try { | ||
| parsedAddress = InetAddresses.forString(socketAddress.getAddress()); | ||
| } catch (IllegalArgumentException ex) { | ||
| throw new ResourceInvalidException("Address is not an IP", ex); |
There was a problem hiding this comment.
Let's add a negative test in GrpcXdsClientImplDataTest with a non I.p. address in the Endpoint resource proto.
kannanjgithub
approved these changes
Jun 5, 2025
|
I don't mind merging this stuff myself. And I would have fixed the commit message that github created. |
AgraVator
pushed a commit
to AgraVator/grpc-java
that referenced
this pull request
Jun 23, 2025
* xds: Don't allow hostnames in address field gRFC A27 specifies they must be IPv4 or IPv6 addresses. Certainly doing a DNS lookup hidden inside the config object is asking for trouble. The tests were accidentally doing a lot of failing DNS requests greatly slowing them down. On my desktop, which made the problem most obvious with five search paths in /etc/resolv.conf, :grpc-xds:test decreased from 66s to 29s. The majority of that is XdsDependencyManagerTest which went from 33s to .1s, as it generated a UUID for the in-process transport each test and then used it as a hostname, which defeated Java's DNS (negative) cache. The slowness was noticed because XdsDependencyManagerTest should have run quickly as a single thread without I/O, but was particularly slow on my desktop. The cleanup caused me to audit serverName and the weird places it went. I think some of them were tricks for XdsClientFallbackTest to squirrel away something distinguishing, although reusing the serverName is asking for confusion as is including the tricks in "shared" utilities. XdsClientFallbackTest does have some non-trivial changes, but this seems to fix some pre-existing bugs in the tests. * Add failing hostname unit test
jdcormie
pushed a commit
to jdcormie/grpc-java
that referenced
this pull request
Jun 27, 2025
* xds: Don't allow hostnames in address field gRFC A27 specifies they must be IPv4 or IPv6 addresses. Certainly doing a DNS lookup hidden inside the config object is asking for trouble. The tests were accidentally doing a lot of failing DNS requests greatly slowing them down. On my desktop, which made the problem most obvious with five search paths in /etc/resolv.conf, :grpc-xds:test decreased from 66s to 29s. The majority of that is XdsDependencyManagerTest which went from 33s to .1s, as it generated a UUID for the in-process transport each test and then used it as a hostname, which defeated Java's DNS (negative) cache. The slowness was noticed because XdsDependencyManagerTest should have run quickly as a single thread without I/O, but was particularly slow on my desktop. The cleanup caused me to audit serverName and the weird places it went. I think some of them were tricks for XdsClientFallbackTest to squirrel away something distinguishing, although reusing the serverName is asking for confusion as is including the tricks in "shared" utilities. XdsClientFallbackTest does have some non-trivial changes, but this seems to fix some pre-existing bugs in the tests. * Add failing hostname unit test
svc-squareup-copybara
pushed a commit
to cashapp/misk
that referenced
this pull request
Jul 29, 2025
| Package | Type | Package file | Manager | Update | Change | |---|---|---|---|---|---| | [io.grpc:grpc-stub](https://github.com/grpc/grpc-java) | dependencies | misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0` | | [io.grpc:grpc-protobuf](https://github.com/grpc/grpc-java) | dependencies | misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0` | | [io.grpc:grpc-netty](https://github.com/grpc/grpc-java) | dependencies | misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0` | | [io.grpc:protoc-gen-grpc-java](https://github.com/grpc/grpc-java) | dependencies | misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0` | | [io.grpc:grpc-bom](https://github.com/grpc/grpc-java) | dependencies | misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0` | | [io.grpc:grpc-api](https://github.com/grpc/grpc-java) | dependencies | misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0` | | [com.google.cloud:google-cloud-logging](https://github.com/googleapis/java-logging) | dependencies | misk/gradle/libs.versions.toml | gradle | patch | `3.23.0` -> `3.23.1` | | [software.amazon.awssdk:aws-core](https://aws.amazon.com/sdkforjava) | dependencies | misk/gradle/libs.versions.toml | gradle | patch | `2.32.9` -> `2.32.10` | | [software.amazon.awssdk:bom](https://aws.amazon.com/sdkforjava) | dependencies | misk/gradle/libs.versions.toml | gradle | patch | `2.32.9` -> `2.32.10` | | [software.amazon.awssdk:auth](https://aws.amazon.com/sdkforjava) | dependencies | misk/gradle/libs.versions.toml | gradle | patch | `2.32.9` -> `2.32.10` | --- ### Release Notes <details> <summary>grpc/grpc-java (io.grpc:grpc-stub)</summary> ### [`v1.74.0`](https://github.com/grpc/grpc-java/releases/tag/v1.74.0) ##### Behavior Changes - compiler: Default to `@generated=omit` ([`f8700a1`](grpc/grpc-java@f8700a13a)). This omits `javax.annotation.Generated` from the generated code and makes the `org.apache.tomcat:annotations-api` compile-only dependency unnecessary (README and examples changes forthcoming; we delayed those changes until the release landed). You can use the option `@generated=javax` for the previous behavior, but please also file an issue so we can develop alternatives - compiler: generate blocking v2 unary calls that throw StatusException ([#​12126](grpc/grpc-java#12126)) ([`a16d655`](grpc/grpc-java@a16d65591)). Previously, the new blocking stub API was identical to the older blocking stub for unary RPCs and used the unchecked `StatusRuntimeException`. However, feedback demonstrated it was confusing to mix that with the checked `StatusException` in `BlockingClientCall`. Now the new blocking stub uses StatusException throughout. grpc-java continues to support the old generated code, but the version of protoc-gen-grpc-java will dictate which API you see. If you support multiple generated code versions, you can use the older blocking v1 stub for unary RPCs ##### Bug Fixes - netty: Fix a race that caused RPCs to hang on start when a GOAWAY was received while the RPCs’ headers were being written to the OS ([`b04c673`](grpc/grpc-java@b04c673fd), [`15c7573`](grpc/grpc-java@15c757398)). This was a very old race, not a recent regression. All streams should now properly fail instead of hanging, although in some cases they may be transparently retried - util: OutlierDetection should use nanoTime, not currentTimeMillis ([#​12110](grpc/grpc-java#12110)) ([`1c43098`](grpc/grpc-java@1c4309899)). Previously, changes in the wall time would impact its accounting - xds: Don't allow hostnames in address field in EDS ([#​12123](grpc/grpc-java#12123)) ([`482dc5c`](grpc/grpc-java@482dc5c1c)). Only IP addresses were handled properly, and only IP addresses should be handled per gRFC A27 - xds: In resource handling, call onError() for RDS and EDS NACKs ([#​12122](grpc/grpc-java#12122)) ([`efe9ccc`](grpc/grpc-java@efe9ccc22)). Previously the resource was NACKed, but gRPC would continue waiting for the resource until a timeout was reached and claim the control plane didn’t send the resource. Now it will fail quickly with an informative error - xds: Implement equals in RingHashConfig ([`a5eaa66`](grpc/grpc-java@a5eaa66cc)). Previously all configuration refreshes were considered a new config, which had the potential for causing unexpected inefficiency problems. This was noticed by new code for gRFC A74 xDS Config Tears that is not yet enabled, so there are no known problems that this caused - LBs should avoid calling LBs after lb.shutdown() ([`1df2a33`](grpc/grpc-java@1df2a3305)). This fixed pick\_first and ring\_hash behavior that could cause rare and “random” races in parent load balancers like a `NullPointerException` in `ClusterImplLoadBalancer.createSubchannel()`, which had a ring\_hash child. This is most likely to help xDS, as it heavily uses hierarchical LB policies ##### Improvements - util: Deliver addresses in a random order to shuffle connection creation ordering ([`f07eb47`](grpc/grpc-java@f07eb47ca)). Previously, connections were created in-order (but non-blocking), so in a fast network the first address could be more likely to connect first given a "microsecond" headstart. That first connection then receives all the buffered RPCs, which could cause temporary, but repeated, load imbalances of the same backend when all clients receive the same list of addresses in the same order. This has been seen in practice, but it is unclear how often it happens. Shuffling has the potential to improve load distribution of new clients when using round\_robin, weighted\_round\_robin, and least\_request, which connect simultaneously to multiple addresses - core: Use lazy message formatting in checkState ([#​12144](grpc/grpc-java#12144)) ([`26bd0ee`](grpc/grpc-java@26bd0eee4)). This avoids the potential of unnecessarily formatting an exception as a string when a subchannel fails to connect - bazel: Migrate java\_grpc\_library to use DefaultInfo ([#​12148](grpc/grpc-java#12148)) ([`6f69363`](grpc/grpc-java@6f69363d9)). This adds compatibility for `--incompatible_disable_target_default_provider_fields` - binder: Rationalize [@​ThreadSafe-ty](https://github.com/ThreadSafe-ty) inside BinderTransport ([#​12130](grpc/grpc-java#12130)) ([`c206428`](grpc/grpc-java@c20642874)) - binder: Cancel checkAuthorization() request if still pending upon termination ([#​12167](grpc/grpc-java#12167)) ([`30d40a6`](grpc/grpc-java@30d40a617)) ##### Dependencies - compiler: Upgrade Protobuf C++ to 22.5 ([#​11961](grpc/grpc-java#11961)) ([`46485c8`](grpc/grpc-java@46485c8b6)). This is used by the pre-built protoc-gen-grpc-java plugin on Maven Central. This should have no visible benefit, but gets us closer to upgrading to Protobuf 27 which added edition 2023 support - release: Migrate artifacts publishing changed from legacy OSSRH to Central Portal ([#​12156](grpc/grpc-java#12156)) ([`f99b2aa`](grpc/grpc-java@f99b2aaef)). We aren’t aware of any visible changes to the results on Maven Central </details> <details> <summary>googleapis/java-logging (com.google.cloud:google-cloud-logging)</summary> ### [`v3.23.1`](https://github.com/googleapis/java-logging/blob/HEAD/CHANGELOG.md#3231-2025-07-28) ##### Bug Fixes - **deps:** Update the Java code generator (gapic-generator-java) to 2.60.2 ([6a268f8](googleapis/java-logging@6a268f8)) ##### Dependencies - Update dependency com.google.cloud:sdk-platform-java-config to v3.50.2 ([#​1834](googleapis/java-logging#1834)) ([2e46f6e](googleapis/java-logging@2e46f6e)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - "after 6pm every weekday,before 2am every weekday" in timezone Australia/Melbourne, Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Never, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). GitOrigin-RevId: 135372e1ea07a30d50a7ad0c0665cc322791152a
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
gRFC A27 specifies they must be IPv4 or IPv6 addresses. Certainly doing a DNS lookup hidden inside the config object is asking for trouble.
The tests were accidentally doing a lot of failing DNS requests greatly slowing them down. On my desktop, which made the problem most obvious with five search paths in /etc/resolv.conf, :grpc-xds:test decreased from 66s to 29s. The majority of that is XdsDependencyManagerTest which went from 33s to .1s, as it generated a UUID for the in-process transport each test and then used it as a hostname, which defeated Java's DNS (negative) cache. The slowness was noticed because XdsDependencyManagerTest should have run quickly as a single thread without I/O, but was particularly slow on my desktop.
The cleanup caused me to audit serverName and the weird places it went. I think some of them were tricks for XdsClientFallbackTest to squirrel away something distinguishing, although reusing the serverName is asking for confusion as is including the tricks in "shared" utilities. XdsClientFallbackTest does have some non-trivial changes, but this seems to fix some pre-existing bugs in the tests.