Description of problem:
In FCOS 33, if OKD is created with static IPs via kernel arguments the DNS a domain not created resulting in an /etc/resolv.conf without a search entry. This is handled by systemd-resolved
FCOS 33 uses systemd-246.14-1.fc33
If FCOS 34 this behavior changed and now systems with static IPs via kernel args and no DNS domain have a line search . added like this
nameserver 10.99.111.1
nameserver 10.99.111.2
search .
This was introduced with: systemd/systemd#17201
FCOS 34 uses systemd-248.3-1.fc34 which includes the above 'enhancement'
Unfortunately this seems to causes a problem with OKD cluster DNS resolution as cluster domains no longer seem to work. Adding new element results in issues such as
openshift/okd#694
Get "https://image-registry.openshift-image-registry.svc:5000/v2/": dial tcp: lookup image-registry.openshift-image-registry.svc on 10.10.8.132:53: no such host
Version-Release number of selected component (if applicable):
FCOS 34
How reproducible:
100%
Comment 1Viktar Siarheichyk
2021-06-29 06:33:33 UTC
I encounter such a behavior by simple update of packages. Ready to provide additional information if needed. All resolution in the workstation does not work.
Comment 2Zbigniew Jędrzejewski-Szmek
2021-06-29 10:52:12 UTC
systemd/systemd#17201 was done to maintain consistency between different lookup mechanism.
Even before that change, image-registry.openshift-image-registry.svc would be resolved properly
using nss-dns but not using nss-resolve. As discussed extensively in the bugs, a global search
domain like this doesn't make sense and is dangerous in the general context of machines with more
than one interface. So the upstream / default downstream behaviour is not going to change.
I think the best we can do is provide a better way to opt-in into this who want it.
*** This bug has been marked as a duplicate of bug 1874419 ***