Bind not resolving ONE external web address

UCS - Univention Corporate Server
,
#1

The following scenario. Two UCS installations, both configured identically for DNS:

image

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

Thank you for your thoughts.

Greetings - Martin

#2

Hi,

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.

/CV

#3

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"
 5980

Last Notifier ID processed by local Listener:
 5980

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

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

What does this tell you ?

Thanks - Martin

#4

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.

1 Like
#5

Moritz, thanks for your explanation.

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

dig www.xyz.de

; <<>> DiG 9.10.3-P4-Univention <<>> www.xyz.de
;; 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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.xyz.de.          IN      A

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

;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; 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

#6

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

#7

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:

grafik

Any idea where else to look for some weird entries ?

Thanks - Martin

#8

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

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
#9

Okay, here’s the output:

ucr get dns/backend
samba4

and

univention-s4search --cross-ncs objectclass=dnszone dn | ldapsearch-wrapper
# record 1
dn: DC=0.168.192.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=msbe,DC=local

# record 2
dn: DC=XYZ.de,CN=MicrosoftDNS,DC=DomainDnsZones,DC=msbe,DC=local

# 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

#10

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 "DC=XYZ.de,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 "DC=XYZ.de,CN=MicrosoftDNS,DC=DomainDnsZones,DC=msbe,DC=local" > "DC=XYZ.de.ldif"
#11

Hi,

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

rg
Christian

#12

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

Mastodon