Pods do not resolve CNAMES correctly

[ThomasBuchinger]

For some reason Pods are unable to resolve CNAMEs, but they can resolve A records.

• Happens in Workload Pods and CoreDNS Pods
• nslookup is able to resolve CNAMEs correctly
• /etc/resolv.conf config looks ok to me
• Different variations vault, vault.buc.sh or vault.buc.sh. (note the dot at the end ) behave identically

nslookup vault.buc.sh
# Works and returns the cname

nslookup evergreen.buc.sh
# Works and returns the IP address

getent hosts evergreen.buc.sh
# Works and returns the IP address

getent hosts vault.buc.sh
# Fails

curl https://vault.buc.sh
# Fails, unable to resolve hostname 

[ThomasBuchinger]

Worked around the problem by creating a A record for vault for now

[ThomasBuchinger]

This problem is caused by a PiHole specific configuration:

• Addresses like pi.hole pihole and/or anyting containing the hostname (e.g. evergreen.buc.sh) resolve to the "Local IPv4" address
• PiHole got confused which IP address is the primary one and defaulted to using 0.0.0.0
• evergreen.buc.sh had an explicit A-Record, therefore it was working. Resolving CNAMEs returned the placeholder IP of 0.0.0.0

Solution: Set LOCAL_IPV4 environment variable, telling PiHole which IP address it should use as the Primary IPv4 Address

[ThomasBuchinger]

Keeping this issue open, because there is still an issue with the WiFi Router advertising itself as a DNS server via IPv6.

IPv6 devices (e.g. smartphones) prefer the WiFi Routers DNS server over PiHole