CoreDNS HNS Endpoint IP is not updated on pod restart

[ValeriiVozniuk]

Describe the bug
When CoreDNS pod on Linux node restarts and receives a new cluster IP, endpoints/endpointslices in Kubertenes are updated with new pod IP, but on Windows worker HNS Endpoint still holds the old IP address. Kubernetes restart on Windows doesn't help, need to delete all stuff and re-join node to cluster again.

To Reproduce

1. Deploy a cluster with 3 Linux master nodes.
2. Join 1 Windows worker node.
3. Start sample workload on Windows node (used mcr.microsoft.com/dotnet/framework/samples:aspnetapp)
4. Exec into Windows pod with cmd, type nslookup, observe working output

Default Server:  kube-dns.kube-system.svc.cluster.local
Address:  10.43.0.10

5. Exit Windows pod, get pods list from kube-system namespace with -o wide, note CoreDNS pod ip.
6. Delete CoreDNS pod, wait for new to start, check its IP address.
7. Exec again into Windows pod, type nslookup, observe timeout errors

DNS request timed out.
    timeout was 2 seconds.
Default Server:  UnKnown
Address:  10.43.0.10

8. Type server <new_coredns_pod_ip>, and after timeout try to resolve any dns name (for example c.cc), you would see that connectivity is working.
9. RDP into Windows server, start Powershell, run

hnsdiag list all | findstr 10.43.0.10

you will see the output like this

ce87ca71-adfd-4334-a5ce-760eae297bef |  10.43.0.10      | 6f995c07-0b4a-4cfb-ba6e-c62dd48a554d
302522f6-f540-4120-881c-b7a2eeecf0f6 |  10.43.0.10      | 6f995c07-0b4a-4cfb-ba6e-c62dd48a554d
ddd666f5-c1e9-4fe1-af6b-da97be5cdb29 |  10.43.0.10      | 6f995c07-0b4a-4cfb-ba6e-c62dd48a554d

10. Run

get-hnsendpoint 6f995c07-0b4a-4cfb-ba6e-c62dd48a554d

and in output IPAddress would be old CoreDNS pod IP address, not the new one.

Expected behavior
HNS Endpoint would be updated with new IP address after CoreDNS pod restart

Kubernetes (please complete the following information):

• Windows Server version: 2019 (10.0.17763.6293)
• Kubernetes Version: 1.28 - 1.31.1
• CNI: flannel

Additional context
The deployment is done with k3s all in one binary, which could make some influence here, but the issue looks like in Kubernetes itself.
The one thing I didn't test is what would happen if I would update HNS Endpoint with the new pod IP, but unfortunately I didn't find a way to perform such update. Any ideas? :)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ValeriiVozniuk]

/remove-lifecycle stale