Pods do not resolve CNAMES correctly

ThomasBuchinger / prod-gitops

0 stars 0 forks source link

Pods do not resolve CNAMES correctly #3

Open ThomasBuchinger opened 1 year ago

ThomasBuchinger commented 1 year ago

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 commented 1 year ago

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

ThomasBuchinger commented 1 year ago

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 commented 1 year ago

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