address nits, add query logging section

content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md

@@ -122,7 +122,7 @@ Use `kubectl logs` command to see logs for the DNS containers.
 
 For CoreDNS:
 ```shell
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1)
+for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done
 ```
 
 Here is an example of a healthy CoreDNS log:
@@ -189,26 +189,83 @@ For additional Kubernetes DNS examples, see the
 [cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
 in the Kubernetes GitHub repository.
 
+
+### Are DNS queries being received/processed?
+
+You can verify if queries are being received by CoreDNS by adding the `log` plugin to the CoreDNS configuration (aka Corefile).
+The CoreDNS Corefile is held in a ConfigMap named `coredns`. To edit it, use the command ...
+
+```
+kubectl -n kube-system edit configmap coredns
+```
+
+Then add `log` in the Corefile section per the example below.
+
+```
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: coredns
+  namespace: kube-system
+data:
+  Corefile: |
+    .:53 {
+        log
+        errors
+        health
+        kubernetes cluster.local in-addr.arpa ip6.arpa {
+          pods insecure
+          upstream
+          fallthrough in-addr.arpa ip6.arpa
+        }
+        prometheus :9153
+        proxy . /etc/resolv.conf
+        cache 30
+        loop
+        reload
+        loadbalance
+    }
+
+```
+
+After saving the changes, it may take up to minute or two for Kubernetes to propagate these changes to the CoreDNS pods.
+
+Next, make some queries and view the logs per the sections above in this document. If CoreDNS pods are receiving the queries, you should see them in the logs.
+
+Here is an example of a query in the log.
+
+```
+.:53
+2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0
+2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6
+CoreDNS-1.2.0
+linux/amd64, go1.10.3, 2e322f6
+2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f
+2018/09/07 15:29:04 [INFO] Reloading complete
+172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s
+
+```
+
 ## Known issues
 
-Some Linux distros (e.g. Ubuntu), use a local DNS resolver by default (systemd-resolved).
-Systemd-resolved moves and replaces /etc/resolv.conf with a stub file that can cause a fatal forwarding
-loop when resolving names in upstream servers.  This can be fixed manually by using kubelet's `--resolv-conf` flag
-to point to the correct resolv.conf (With systemd-resolved, this is `/run/systemd/resolve/resolv.conf`).
-kubeadm 1.11 automatically detects systemd-resolved, and adjusts kubelet accordingly.
+Some Linux distributions (e.g. Ubuntu), use a local DNS resolver by default (systemd-resolved).
+Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding
+loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag
+to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`).
+kubeadm 1.11 automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly.
 
-Kubernetes installs do not configure the nodes' resolv.conf files to use the
-cluster DNS by default, because that process is inherently distro-specific.
+Kubernetes installs do not configure the nodes' `resolv.conf` files to use the
+cluster DNS by default, because that process is inherently distribution-specific.
 This should probably be implemented eventually.
 
 Linux's libc is impossibly stuck ([see this bug from
 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just
-3 DNS `nameserver` records and 6 DNS `search` records.  Kubernetes needs to
-consume 1 `nameserver` record and 3 `search` records.  This means that if a
+3 DNS `nameserver` records and 6 DNS `search` records. Kubernetes needs to
+consume 1 `nameserver` record and 3 `search` records. This means that if a
 local installation already uses 3 `nameserver`s or uses more than 3 `search`es,
-some of those settings will be lost.  As a partial workaround, the node can run
+some of those settings will be lost. As a partial workaround, the node can run
 `dnsmasq` which will provide more `nameserver` entries, but not more `search`
-entries.  You can also use kubelet's `--resolv-conf` flag.
+entries. You can also use kubelet's `--resolv-conf` flag.
 
 If you are using Alpine version 3.3 or earlier as your base image, DNS may not
 work properly owing to a known issue with Alpine.