Answers: <p><a href="https://devops.stackexchange.com/users/12708/ibuildthecloud">ibuildthecloud9</a> gave me the right hint. Since the github issue doesn't describe how to midify the dns, I figured it out and want to document it here in case someone need to change it, too. It's stored in the configmap <code>coredns</code> as <code>Corefile</code>:</p>
  
  <pre><code>proxy . 1.1.1.1
  </code></pre>
  
  <p>You need to replace this by your dns server (192.168.0.19 in my case). It could be done manually using <code>kubectl edit cm -n kube-system coredns</code>. In case you also want to automate this process: </p>
  
  <pre><code>kubectl get cm -n kube-system coredns -o yaml | sed "s/proxy . 1.1.1.1/proxy . 192.168.0.19/g" &gt; coredns-fixed.yml
  </code></pre>
  
  <p>Now you'll have the fixed yaml file, which got loaded by </p>
  
  <pre><code>kubectl apply -f coredns-fixed.yml
  </code></pre>
  
  <h2>Test it</h2>
  
  <p>Create <code>busybox.yml</code></p>
  
  <pre><code>apiVersion: v1
  kind: Pod
  metadata:
      name: busybox
  spec:
      containers:
      # for arm
      #- image: hypriot/armhf-busybox
      - image: busybox
        command:
            - sleep
            - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always
  </code></pre>
  
  <p>Create the pod: <code>kubectl create -f busybox.yml</code>
  And try to ping a host resolved by your dns: </p>
  
  <pre><code>~$ kubectl exec -it busybox -- ping -c1 server2.fritz.box
  PING server2.fritz.box (192.168.0.37): 56 data bytes
  64 bytes from 192.168.0.37: seq=0 ttl=61 time=0.386 ms
  </code></pre>
  
  <p><strong>Before</strong> applying our dns (so 1.1.1.1 was used, which belongs to Cloudflare) this throws the following resolving error: </p>
  
  <pre><code>*~$ kubectl exec -it busybox -- ping -c1 server2.fritz.box
  ping: bad address 'server2.fritz.box'*
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-03T10:26:59.300Z
Answers: 2019-03-03T10:26:59.300Z
Answers: Lion
Answers: <p>I believe this is an current bug in k3s that upstream DNS is hardcoded to 1.1.1.1.  this should be resolved shortly <a href="https://github.com/rancher/k3s/issues/53" rel="nofollow noreferrer">https://github.com/rancher/k3s/issues/53</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-03T07:27:51.813Z
Answers: 2019-03-03T07:27:51.813Z
Answers: ibuildthecloud
Body: <p>I have a dns server running at 192.168.0.19 for custom domains like .fritz.box. Having a single node cluster on k3s, Rancher was installed using a subdomain server2.fritz.box using this command: </p>
  
  <pre><code>    helm install rancher-latest/rancher \
        --name rancher \
        --namespace cattle-system \
        --set hostname=server2.fritz.box
  </code></pre>
  
  <p>Rancher itself shows that some services are not avaliable and the logs from cattle say server2.fritz.box is not avaliable. Since Kubernetes has its own dns system, I looked <a href="https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/" rel="nofollow noreferrer">at the documentation</a> and it seems that I need to set my .19 dns server so that Kubernetes knows how to resolve .fritz.box domains. Some questions also have similar problems like <a href="https://stackoverflow.com/questions/41448095/kube-dns-does-not-resolve-external-hosts-on-kubeadm-bare-metal-cluster">https://stackoverflow.com/questions/41448095/kube-dns-does-not-resolve-external-hosts-on-kubeadm-bare-metal-cluster</a></p>
  
  <p>So I created the following yaml:</p>
  
  <pre><code># https://github.com/kubernetes/kops/issues/4986
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: kube-dns
    namespace: kube-system
  data:
    stubDomains: |
      {"fritz.box": ["192.168.0.19"]}
    upstreamNameservers: |
      ["192.168.0.19"]
  </code></pre>
  
  <p>Loaded with <code>kubectl apply -f dns.yml</code>. Now created a busybox test pod:</p>
  
  <pre><code>~$ kubectl exec -it busybox -- ping server2.fritz.box
  ping: bad address 'server2.fritz.box'
  </code></pre>
  
  <p>Why is this not working? 
  And what must be done to resolve a custom dns server in Kubernetes?</p>
  
Tags: <kubernetes><configuration-management><helm><dns><rancher>
Title: Kubernetes on k3s can't resolve domains from custom dns server (fritz.box with dnsmasq)
UserDisplayName: Lion
ThreadText: # Kubernetes on k3s can't resolve domains from custom dns server (fritz.box with dnsmasq)
  
  (Asked by: username_0 on 2019-03-03)
  
  I have a dns server running at 192.168.0.19 for custom domains like .fritz.box. Having a single node cluster on k3s, Rancher was installed using a subdomain server2.fritz.box using this command:
  
  ```
      helm install rancher-latest/rancher \
        --name rancher \
        --namespace cattle-system \
        --set hostname=server2.fritz.box
  
  ```
  
  Rancher itself shows that some services are not avaliable and the logs from cattle say server2.fritz.box is not avaliable. Since Kubernetes has its own dns system, I looked [at the documentation](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/) and it seems that I need to set my .19 dns server so that Kubernetes knows how to resolve .fritz.box domains. Some questions also have similar problems like <https://stackoverflow.com/questions/41448095/kube-dns-does-not-resolve-external-hosts-on-kubeadm-bare-metal-cluster>
  
  So I created the following yaml:
  
  ```
  # https://github.com/kubernetes/kops/issues/4986
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: kube-dns
    namespace: kube-system
  data:
    stubDomains: |
      {"fritz.box": ["192.168.0.19"]}
    upstreamNameservers: |
      ["192.168.0.19"]
  
  ```
  
  Loaded with `kubectl apply -f dns.yml`. Now created a busybox test pod:
  
  ```
  ~$ kubectl exec -it busybox -- ping server2.fritz.box
  ping: bad address 'server2.fritz.box'
  
  ```
  
  Why is this not working?
  And what must be done to resolve a custom dns server in Kubernetes?
  
  **Tags:** kubernetes, configuration-management, helm, dns, rancher
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2019-03-03. Score: 5
  
  [ibuildthecloud9](https://devops.stackexchange.com/users/12708/username_1) gave me the right hint. Since the github issue doesn't describe how to midify the dns, I figured it out and want to document it here in case someone need to change it, too. It's stored in the configmap `coredns` as `Corefile`:
  
  ```
  proxy . 1.1.1.1
  
  ```
  
  You need to replace this by your dns server (192.168.0.19 in my case). It could be done manually using `kubectl edit cm -n kube-system coredns`. In case you also want to automate this process:
  
  ```
  kubectl get cm -n kube-system coredns -o yaml | sed "s/proxy . 1.1.1.1/proxy . 192.168.0.19/g" > coredns-fixed.yml
  
  ```
  
  Now you'll have the fixed yaml file, which got loaded by
  
  ```
  kubectl apply -f coredns-fixed.yml
  
  ```
  
  ## Test it
  
  Create `busybox.yml`
  
  ```
  apiVersion: v1
  kind: Pod
  metadata:
      name: busybox
  spec:
      containers:
      # for arm
      #- image: hypriot/armhf-busybox
      - image: busybox
        command:
            - sleep
            - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always
  
  ```
  
  Create the pod: `kubectl create -f busybox.yml`
  And try to ping a host resolved by your dns:
  
  ```
  ~$ kubectl exec -it busybox -- ping -c1 server2.fritz.box
  PING server2.fritz.box (192.168.0.37): 56 data bytes
  64 bytes from 192.168.0.37: seq=0 ttl=61 time=0.386 ms
  
  ```
  
  **Before** applying our dns (so 1.1.1.1 was used, which belongs to Cloudflare) this throws the following resolving error:
  
  ```
  *~$ kubectl exec -it busybox -- ping -c1 server2.fritz.box
  ping: bad address 'server2.fritz.box'*
  
  ```
  
  
  ---
  
  ### Answer by username_1 on 2019-03-03. Score: 4
  
  I believe this is an current bug in k3s that upstream DNS is hardcoded to 1.1.1.1. this should be resolved shortly <https://github.com/rancher/k3s/issues/53>
  
  
  ---
  
  