CoreDNS HNS Endpoint IP is not updated on pod restart

[ValeriiVozniuk]

trafficstars

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? :)