Static coreDNS pods created through OCP IPI installation uses host networking, as a result the coreDNS process binds to 53 TCP/UDP ports on an IP address on the host system. 

[root@worker-0 ~]# netstat -ntlup |grep ":53 "
tcp6       0      0 :::53                   :::*                    LISTEN      9489/coredns
udp6       0      0 :::53                   :::*                                9489/coredns
 
$ oc get po -n openshift-kni-infra
NAME                  READY   STATUS    RESTARTS      AGE
coredns-master-0      2/2     Running   2             54d
coredns-master-1      2/2     Running   2             54d
coredns-master-2      2/2     Running   3 (54d ago)   54d
coredns-worker-0      2/2     Running   6             54d
coredns-worker-1      2/2     Running   8             54d
coredns-worker-2      2/2     Running   2             54d

Again the  system’s IP address is added to the first list in the /etc/resolv.conf file for DNS resolution. By default CoreDNS pods are enabled to answer recursive DNS query, this means DNS requests that are not managed locally in the coreDNS POD, will be forwarded to the upstream DNS server. 

Since CoreDNS answers recursive DNS query, in some customer’s environment it is considered as a security risk or security vulnerability  - “DNS Server Recursive Query Cache Poisoning Weakness”

I believe in IPI deployment,  there is no need for a separate coreDNS deployment in the *kni-infra projects. If we stop deploying the coreDNS PODS, in `{*}kni-infra projects`, it will resolve this vulnerability. 

Another way is to implement CoreDNS ACL to prevent DNS queries from other subnets.