CoreDNS and SMB mount name resolution

[rogerfn]

Hi everyone,

I'm not sure if this is a bug or something, I need a bit of help here.

I have a custom dns server configuration in CoreDNS that apparently is ignored by the SMB mount. The Pod when it tries to mount the share, cannot resolve the host name xxxx.mycompany.com. All the pods in the cluster can resolve xxxx.mycompany.com. The connection works fine if I use the IP address instead

-------
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  companydns.server: |
    
    mycompany.com:53 {
      errors
      cache 1
      forward . 10.10.1.1 10.10.1.2

    }

[andyzhangx]

what's the dnsPolicy of the csi-smb-node daemonset?

csi-driver-smb/deploy/csi-smb-node.yaml

Line 21 in 2457c6d

dnsPolicy: Default # available values: Default, ClusterFirstWithHostNet, ClusterFirst

And also have you tried restart the coredns daemonset pods?

[rogerfn]

ClusterFirstWithHostNet did the trick actually, thanks for pointing this out

[andyzhangx]

ClusterFirstWithHostNet would fix the issue?

[rogerfn]

Yes, not sure why to be honest. I'm running kubenet and my vnet is using Azure-provided DNS. I had to add a custom CoreDNS to be able to resolve the internal hostnames. My pod doesn't specify hostNetwork.

[andyzhangx]

there are also cases there ClusterFirstWithHostNet would break for on-prem smb server name resolution: #422

[rogerfn]

After few days, I restarted it and it broke and it can't resolve the name anymore with none of the dnsPolicy. I did notice that all the resolv.conf of all the pods points to the kubernetes DNS server ... but the smb node pod points to the azure one 168.63.129.16, ignoring the policy that is passed

[rogerfn]

I used dnsPolicy: None and then manually configured the DNS.. Something like:

dnsPolicy: None 
dnsConfig:
  nameservers: ["10.138.16.10"] # My DNS Service IP
  searches:
  - cluster.local
  - svc.cluster.local
  options:
  - name: ndots
    value: "5"

I think it will be quite good if we have that posibility in the Charts