Validate localtargets DNS label length and use a separate label instead of localtargets-<host>

[altieresfreitas]

Today k8gb publishes and queries cross-cluster local records using the pattern:

localtargets-<host>

This can generate an invalid DNS label when the first label of is long enough, because a DNS label cannot exceed 63 characters.

For example, if the application host already has a long first label, prefixing it with localtargets- may exceed the DNS label limit and cause
cross-cluster resolution failures. In practice this can show up as missing remote targets / NODATA when querying neighboring clusters.

Problem

The current format puts localtargets and the first hostname label into the same DNS label, which is not safe for long hostnames:

• Current: localtargets-very-long-app-name.example.com
• First label becomes: localtargets-very-long-app-name
• This may exceed the 63-char DNS label limit

This impacts the internal peer-to-peer discovery flow, where one cluster queries another cluster’s CoreDNS for the generated localtargets record.

Proposal

There are two improvements that would help a lot:

1. Validate generated internal record names before publishing/querying them
   - Detect when the derived localtargets record would violate DNS label rules
   - Surface a clear validation error / event / status message instead of failing later in DNS resolution
2. Change the internal naming scheme from localtargets- to localtargets.
   - This makes localtargets a separate DNS label
   - Example:
   - current: localtargets-my-very-long-host.example.com
   - proposed: localtargets.my-very-long-host.example.com
   - This avoids inflating the first hostname label and is more DNS-friendly

Why this helps

Using localtargets. preserves the original hostname labels and avoids hitting the 63-character limit due to the internal prefixing scheme itself.

Compatibility concern

A direct switch may break mixed-version environments during rollout, because old versions would still publish/query localtargets- while new
versions would use localtargets..

A safer migration path would be:

1. validate the generated name
2. add support for querying both formats
3. optionally publish both formats during transition
4. deprecate the old dashed format later

Expected outcome

• Invalid internal DNS names are caught early and explicitly
• Long application hostnames no longer break cross-cluster discovery because of the localtargets prefix format
• Upgrades can be done safely if both naming schemes are temporarily supported

Context

This was observed while troubleshooting cross-cluster resolution issues where domains stopped resolving remote targets and returned NODATA.
The root cause appears to be the generated internal record name exceeding DNS label length constraints rather than an issue in the final GSLB hostname itself.

[ytsarev]

Thanks a lot for the detailed feedback and proposal. I like localtargets.my-very-long-host.example.com idea. We will need to implement a smooth migration mechanism in this case. I will make sure we discuss it at the next community meeting

CC @elohmrow