Bug 1991067: [on-prem] Set coredns bufsize to 512

KNI CoreDNS does not resolve hostnames if the nameservers in the forwarders provide a DNS reponse > 512 bytes

So name resolution to github.com from application pod fails if the forward section of Corefile had an upstream DNS which provides a DNS response > 512

The response size you get while dig to github.com using upstream namserver 10.11.142.1  is 602 whereas using namserver 10.11.5.19 it is 55

The limit for UDP DNS messages is 512 bytes long. Well behaved DNS servers are supposed to truncate the message and set the truncated bit. See RFC 1035 section 4.2.1.

https://datatracker.ietf.org/doc/html/rfc1035#section-4.2.1

https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.4

The difference in the dig to github.com is the response size. For  10.11.142.1 it is 602 > 512 and for 10.11.5.19 it is 55 < 512

CoreDNS will compress messages that exceed 512 bytes, unless the client allows a larger maximum size by sending the corresponding edns0 option in the request.

dig in particular sends a buffer size > 512 by default. I think the exact number depends on the dig version or perhaps the environment... on my OCP nodes it defaults to 4096 - I think this is most common.

[miheer@localhost ~]$ oc debug node/mykrbid-vcd8j-worker-0-hlkmf
Starting pod/mykrbid-vcd8j-worker-0-hlkmf-debug ...
To use host binaries, run `chroot /host`
Pod IP: 192.168.0.94
If you don't see a command prompt, try pressing enter.
sh-4.4#
sh-4.4# sysctl -a | grep  rmem
net.core.rmem_default = 212992
net.core.rmem_max = 212992
net.ipv4.tcp_rmem = 4096	87380	6291456
net.ipv4.udp_rmem_min = 4096

So, we should be setting 512 as bufsize for KNI coredns to avoid this issue.

templates/common/on-prem/files/coredns-corefile.yaml

@@ -4,6 +4,7 @@ contents:
   inline: |
     . {
         errors
+        bufsize 512
         health :18080
         forward . {{`{{- range $upstream := .DNSUpstreams}} {{$upstream}}{{- end}}`}} {
             policy sequential