Bind not resolving ONE external web address

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 @ 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).

Thank you for your thoughts.

Greetings - Martin


did you restart cache?
systemctl restart nscd

If this is not the issue, do:
root@ucs:~# univention-directory-listener-ctrl status
and let us know the result.

Oh, and: is the name you are asking for an internal name? And please post exact commands you used to test.


The translation did not exactly reflect what I was trying to say. So I edited the text in the original post.

Again: I restarted the cache as suggested. No change. And it is only one machine doing this, the other works as expected.

This is the result of the status command (on the machine which doesn’t work):

Current Notifier ID on "userver.msbe.local"

Last Notifier ID processed by local Listener:

Last transaction processed:
 5980 zoneName=msbe.local,cn=dns,dc=msbe,dc=local m

3       bind    /usr/lib/univention-directory-listener/system/
3       cups-pdf        /usr/lib/univention-directory-listener/system/
3       cups-printers   /usr/lib/univention-directory-listener/system/
3       dhcp    /usr/lib/univention-directory-listener/system/
3       dovecot /usr/lib/univention-directory-listener/system/
3       dovecot-shared-folder   /usr/lib/univention-directory-listener/system/
3       faillog /usr/lib/univention-directory-listener/system/
3       gencertificate  /usr/lib/univention-directory-listener/system/
3       hosteddomains   /usr/lib/univention-directory-listener/system/
3       keytab-member   /usr/lib/univention-directory-listener/system/
3       keytab  /usr/lib/univention-directory-listener/system/
3       ldap_extension  /usr/lib/univention-directory-listener/system/
3       ldap_server     /usr/lib/univention-directory-listener/system/
3       license_uuid    /usr/lib/univention-directory-listener/system/
3       nagios-client   /usr/lib/univention-directory-listener/system/
3       nagios-server   /usr/lib/univention-directory-listener/system/
3       nfs-homes       /usr/lib/univention-directory-listener/system/
3       nfs-shares      /usr/lib/univention-directory-listener/system/
3       nscd_update     /usr/lib/univention-directory-listener/system/
3       nss     /usr/lib/univention-directory-listener/system/
3       pkgdb-watch     /usr/lib/univention-directory-listener/system/
3       portal_category /usr/lib/univention-directory-listener/system/
3       portal_entry    /usr/lib/univention-directory-listener/system/
3       portal  /usr/lib/univention-directory-listener/system/
3       quota   /usr/lib/univention-directory-listener/system/
3       s4-connector    /usr/lib/univention-directory-listener/system/
3       samba4-idmap    /usr/lib/univention-directory-listener/system/
3       samba-shares    /usr/lib/univention-directory-listener/system/
3       udm_extension   /usr/lib/univention-directory-listener/system/
3       umc-service-providers   /usr/lib/univention-directory-listener/system/
3       univention-saml-idp-config      /usr/lib/univention-directory-listener/system/
3       univention-saml-servers /usr/lib/univention-directory-listener/system/
3       univention-saml-simplesamlphp-configuration     /usr/lib/univention-directory-listener/system/
3       well-known-sid-name-mapping     /usr/lib/univention-directory-listener/system/

What does this tell you ?

Thanks - Martin

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 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, only the cache of the name server running on 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.

1 Like

Moritz, thanks for your explanation.

Now, if I dig the web address on the failing system I get:


; <<>> DiG 9.10.3-P4-Univention <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23615
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;          IN      A

;; AUTHORITY SECTION:       3600    IN      SOA     userver.msbe.local. root.msbe.local. 2 28800 7200 604800 3600

;; Query time: 1 msec
;; WHEN: Thu Mar 14 15:56:00 CET 2019
;; MSG SIZE  rcvd: 108

I replaced the real address with xyz. Does this answer tell us, why BIND would not ask the forwarder ?

Thanks, Martin

Looks like you created the domain 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, 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, and we could use for our UCS domain).

Well - I am pretty sure that I did not do that. And: the xyz is completely different to the msbe.local which is the local only domain name.

UMC does not show anything unusual in the DNS section IMHO:


Any idea where else to look for some weird entries ?

Thanks - Martin

This part of the answer from dig shows that the server userver.msbe.local is supposed to be the authoritative server for the domain

It’s possible the domain isn’t present in OpenLDAP anymore but still present in the Samba4 LDAP. Please post the output of:

ucr get dns/backend
univention-s4search --cross-ncs objectclass=dnszone dn | ldapsearch-wrapper

Okay, here’s the output:

ucr get dns/backend


univention-s4search --cross-ncs objectclass=dnszone dn | ldapsearch-wrapper
# record 1

# record 2

# record 3
dn: DC=RootDNSServers,CN=MicrosoftDNS,DC=DomainDnsZones,DC=msbe,DC=local

# record 4
dn: DC=msbe.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=msbe,DC=local

# record 5
dn: DC=_msdcs.msbe.local,CN=MicrosoftDNS,DC=ForestDnsZones,DC=msbe,DC=local

# record 6
dn: DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=msbe,DC=local

# returned 6 records
# 6 entries
# 0 referrals

How the f*ck did that record #2 entry get in there ?
And how can I get rid of it ?

Thanks - Martin

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:

ldbdel -H /var/lib/samba/private/sam.ldb --cross-ncs --recursive ",CN=MicrosoftDNS,DC=DomainDnsZones,DC=msbe,DC=local"

But before you do that, please create at least a backup of the sub-tree:

ldbsearch --cross-ncs -H /var/lib/samba/private/sam.ldb -b ",CN=MicrosoftDNS,DC=DomainDnsZones,DC=msbe,DC=local" > ""


You may also be able to delete from Microsoft RSAT Tools - DNS Management - think this would be better way - also to see additional entries there


Well, no there was no AD takeover :grimacing:, but

That deleted the unwanted entry. After another restart BIND now works as expected.

Thank you very much for your time.

Best wishes to you - Martin