The following scenario. Two UCS installations, both configured identically for DNS:
On one system one particular web address can be pinged, on the other the following message shows up immediately:
The name or service is not known
A dig @8.8.8.8 FQDN is provides the correct IP address on both systems. So I rule the DNS forwarder out as the culprit …
What else could be the reason ? rndc flush or /etc/init.d/bind9 restart did not help. An even after flushing the DNS cache the error message pops up immediately (not after a few seconds as expected).
Restarting nscd and doing rndc flush flush two different caches. The first one flushes the cache used by libc for all kinds of name resolution (e.g. user/group names but also host names if you use the resolve functions of libc, e.g. gethostbyname — as happens when you call ping some.ho.st). The second one flushes the cache of the Bind name server.
On UCS both caches are active and used. Therefore rndc flush does not suffice.
It’s important to know which caches are used by the programs you use for testing. Programs that create DNS packets themselves and send them directly to a name server such as host, dig, delv or nslookup do not use the C library’s resolver functions and are therefore not affected by the cache provided by nscd. If you do e.g. host some.ho.st 127.0.0.1, only the cache of the name server running on 127.0.0.1 is queried.
Other programs such as ping, ssh, curl or wget do use the C library for name resolution. In that case the request is first handled by the cache provided by nscd, and only if that lookup fails does the nameserver configured via /etc/resolv.conf come into play.
Looks like you created the domain xyz.de in the UMC on the server where the lookup isn’t working. This means that the UCS server considers itself to be the authoritative source of information. When he sees a query for whatever.xyz.de, it’ll only look to its own internal database (Samba4 or OpenLDAP). If there’s no entry for whatever, it’ll answer in the negative.
That’s how DNS works.
If you’re using the same domain name internally for a UCS domain as well as externally for publicy-resolvable names — don’t do that. It’s very, very bad practice leading to a lot of problems such as this one. It’s OK to use a sub-domain of a publicy-resolvable domain for UCS, though (e.g. our own publicy-resolvable domain is linet-services.de, and we could use int.bs.linet-services.de for our UCS domain).
Not sure how it got there (was this UCS domain created by an AD takeover, perchance?), but as it doesn’t seem to be present in the OpenLDAP, you can get rid of it with ldbdel: