DNS Bug

Hallo,

ich habe eine Problem mit dem DNS. Trage ich einen sinnvollen Forwarder ein bekomme ich DNS-Timeouts bei externer Namensauflösung. Das selbe passiert wenn ich keinen Forwarder eintrage. Ich habe mir mal die bei mir verwendete named.conf.samba4 angeschaut. und finde (bei aktivem Forwarder) folgenden Eintrag:

zone "." {
	type forward;
	forwarders {
		192.168.2.254;
	};
};

Diese Configurationsmethode ist mir gänzlich unbekannt. Kommentiere ich das aus und trage den Forwarder wie üblich unter “optiions” ein gibt es keine Timeouts:

options {
        tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";
	allow-query { any; };
	allow-transfer { any; };
	listen-on-v6 { any; };
	forwarders { 192.168.2.254; };
};

Ein Kollege hat mich dann auf die Idee gebracht es mal so auszuprobieren:

zone "." {
	forward only ;
	type forward;
	forwarders {
		192.168.2.254;
	};
};

Auch das behebt das Problem mit den Timeouts. Nur die default UCS-Config macht die Probleme.

Ich halte das für einen Bug.

Folgender Patch behebt das Problem:

*** /etc/univention/templates/files/etc/bind/named.conf.samba4.orig	2013-08-29 15:17:07.384000389 +0200
--- /etc/univention/templates/files/etc/bind/named.conf.samba4	2013-08-29 15:17:29.036000393 +0200
***************
*** 39,44 ****
--- 39,45 ----
  	print '# Ignoring any setting of dns/fakeroot.'
  	print 'zone "." {'
+ 	print '\tforward only;'
  	print '\ttype forward;'
  	print '\tforwarders {'
  	if configRegistry['dns/forwarder1']:
  		print '\t\t%s;' % configRegistry['dns/forwarder1']

Matthias

Hallo,

welche UCS Version wird verwendet?

ucr search ^version

Welche bind- Version ist installiert?

dpkg -l | grep bind

Was sagt:

univention-check-templates

Fehlermeldungen beim Start vom bind im syslog?

Bei mir sieht die Config gleich aus und funktioniert ohne Probleme.

Alles up to date:

root@srv01:/# ucr search ^version
version/erratalevel: 177
 Errata patchlevel of the UCS version

version/patchlevel: 1
 Patchlevel of the UCS version

version/releasename: Findorff
 Codename for UCS releases

version/security-patchlevel: <empty>
 Security patchlevel of the UCS version

version/version: 3.1
 Major version of UCS

root@srv01:/# dpkg -l | grep bind
ii  bind9                                           1:9.8.0.P4-1.102.201307290920                     Internet Domain Name Server
ii  bind9-host                                      1:9.8.0.P4-1.102.201307290920                     Version of 'host' bundled with BIND 9.X
ii  bind9utils                                      1:9.8.0.P4-1.102.201307290920                     Utilities for BIND
ii  libbind9-80                                     1:9.8.0.P4-1.102.201307290920                     BIND9 Shared Library used by BIND
ii  univention-bind                                 7.0.14-1.189.201303070958                         UCS - DNS server
root@srv01:/# univention-check-templates
root@srv01:/# 

(gekürzt auf das was ich für sinnvoll halte)

Ich verstehe das Verhalten auch nicht. Ich kann nur sagen: Hier ist es so. Im alten Server der heute abgelöst wird steht gar kein Forwarder und es geht auch. Mir ist nicht klar, was an dem UCS-Setup so besonders sein soll.

Im Syslog steht nix zielführendes, nur so das übliche was so ein Bind im Betrieb so loggt.

Hallo,

zunächst zur allgemeinen Klarstellung:
Die externe Namensauflösung funktioniert entweder über die eingetragenen Forwarder oder unter Nutzung der DNS Rootserver. Letztere sind aktiv, wenn “dns/fakeroot” auf “false” steht und kein Forwarder aktiv ist (siehe [bug]3129[/bug]).

Der von Ihnen vorgeschlagene Patch besteht nur aus der zusätzlichen Option “forward only ;”
Ich habe dazu Folgendes gefunden:

Im Moment kann ich nicht sehen, wie “forward only” unter normalen Umständen das Zeitverhalten der Abfragen verbessern soll, wenn sowieso der Forwarder als Erster gefragt wird.

Da da Problem auch bei mir nicht reproduzierbar ist, würde ich in diesem Fall eher auf ein Umgebungsabhängiges Problem tippen. Unter Umständen wäre es sinnvoll, mit “time dig …” die Antwortzeiten der beteilgten Server zu prüfen.

Viele Grüße,
Dirk Ahrnke

Mastodon