coredns: Data is not synced when CoreDNS reconnects to kubernetes api server after protracted disconnection

What happened: For some reason, our project needs to deploy coreDNS away from k8s apiserver , at the same time the network is not reliable. Therefore, we tested whether the event of k8s SVC when the network was disconnected would be detected by CoreDNS after reconnetcion. The result showed that when SVC was deleted during a long period of disconnection from k8s API server, and CoreDNS still had the parsing record of the SVC after reconnection. What you expected to happen: When CoreDNS is disconnected from API server, SVC is deleted. After reconnection, CoreDNS should not have the parsing record of this SVC How to reproduce it (as minimally and precisely as possible): Virtural Machine a : run kubernetes api server Virtural Machine b : run CoreDNS by binary+systemed

• Short time network failure

1. In a, use kubectl to create a svc relating existing pod
2. In b, use dig to resolve svc dig svc.namespace.service.cluster.local @debianIP -p 1053, successfully return svc vip
3. In b, shut down the network of b
4. In a, use kubectl delete svc
5. In a, use kubectl create svc2
6. In b, resume the network of b after 1 min
7. In b, use dig to resolve svc , successfully return none
8. Inb, use dig to resolve svc2, successfully return svc2 vip

• Long time network failure

1. In a, use kubectl to create a svc
2. In b, use dig to resolve svc, successfully return svc vip
3. In b, shut down the network of b
4. In a, use kubectl delete svc
5. In a, use kubectl create svc2
6. In b, resume the network of b after 30 min
7. In b, use dig to resolve svc , still return svc vip
8. In b, use dig to resolve svc2, successfully return svc2 vip Anything else we need to know?: Could this be due to a design flaw in the ListWatch itself?

Environment:

• the version of CoreDNS:
• Corefile:

.:1053 {
        errors
        health {
           lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           endpoint http://10.10.103.98:8080
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 0
        }
        forward . /etc/resolv.conf
        loop
        reload
        loadbalance
    }

• logs, if applicable:
• OS (e.g: cat /etc/os-release):
• Others: