Utilize ExternalDNS as well as ExternalIP

[nanasi880]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

ExternalDNS is not referenced as the address of the game server.
https://github.com/googleforgames/agones/blob/v1.10.0/pkg/gameservers/gameservers.go#L42-L57

In a situation where the game server is located in an IPv4 network and the game client is located in an IPv6 network, if you are able to use ExternalDNS, NAT64 will do the translation correctly and you will be able to communicate.

Currently, only ExternalIP is referenced, so you will get raw IPv4 addresses, and you will have to translate them manually.

The most typical case of a game client deployed in an IPv6 network is an Apple/iOS device.
They require the game application to work properly even on iOS devices deployed in IPv6 networks.

Describe the solution you'd like
A clear and concise description of what you want to happen.

ExternalDNS is the preferred reference.
Or, provide an option to browse ExternalDNS preferentially.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

The application can get information about the node directly and use it.
However, that would reduce the appeal of Agones by half.

Additional context
Add any other context or screenshots about the feature request here.

https://developer.apple.com/support/ipv6/

[markmandel]

Sounds like a reasonable idea to me - try ExternalDNS first, then go to ExternalIP, and then go back to InternalIP next? (or maybe InternalDNS first? That would probably make more sense, right?)

Only thing would be that this should be put behind a feature flag, so we can slowly roll the functionality through.

[nanasi880]

Yes, you're right, it sounds more reasonable to fall back to InternalDNS first, then InternalIP.
InternalIP is for environments like Minikube, and maybe InternalDNS is not necessary, but if you skip just InternalDNS, users will be unnecessarily surprised by its behavior.

As is obvious from the conversation so far, we think it makes the most sense to do the search in the following order.

1. ExternalDNS
2. ExternalIP
3. InternalDNS
4. InternalIP

Another idea is to copy all []NodeAddress, which can provide more flexibility of choice to the application, but instead the impact of the change is more widespread.
#957

I fully agree with the idea of controlling with feature flag.

[markmandel]

Another idea is to copy all []NodeAddress

This feels to me like a bigger change, as it would impact GameServer -> GameServerAllocation -> Multi Cluster Allocation as well (although it would be just an addition)

I would posit that update to logic outlined above is a smaller amount of work, and since we can test it behind a feature flag, we can get feedback on it and see if it provides enough for users / breaks any patterns of usage without the larger work -- if it works as required, then that is a faster way to get to a working solution.

WDYT?

[nanasi880]

Yes, I agree with you.

Do you think you can take the time to deal with this?
I am new to contributing to Agones, but may be able to create a patch.
However, I haven't figured out a good way to test this content automatically.

[markmandel]

We'd love to have you come contribute! 👋

We could add a unit test here to automatically test this out:
https://github.com/googleforgames/agones/blob/master/pkg/gameservers/gameservers_test.go#L44-L79

Although we would want to extend it to cover a new feature gate.

If you are interested, please pop into #development on Slack if you want some direction/help on getting started developing against Agones - would love to give you a hand!

[nanasi880]

I have created a PR on this.
#1928