bind9 fügt FQDN bei Slave-zone nicht an

[feckelm]

Hallo,

ich habe folgendes Problem: seit einiger Zeit (evtl. seit irgendeinem Update oder Upgrade) probiert der bind die in der /etc/resov.conf angegebenen Domains nicht mehr in seiner Suche aus.

Meine Infrastuktur ist folgender maßen:

2 Standorte per VPN verbunden.

Standort A
192.168.10.x
Domain: standorta.firma.de
es läuft ein Jessie

Standort B
192.168.20.x
Domain: standortb.firma.de
es läuft ein Jessie

die beiden Server A&B sind jeweils Master für ihre eigene Zone und bekommen vom anderen automatisch die Zonendateien als Slave.

Wenn ich nun von meinem Laptop ein nslookup zu einem lokalen Rechner mache löst er ordentlich auf, zu einem Rechner am anderen Standort kommt die Meldung "Rechner123 wurde von "DNS-Server" nicht gefunden: Non-existent Domain."
Probiere ich das am DNS-Server direkt klappt es.

Die Auflösung funktioniert also eigentlich richtig, nur Anfragen von "extern" werden nicht richtig ausgeführt.
Es ging ja schon mal.

Vielleicht hatte hier ja schon mal jemand ein ähnliches Problem oder die passenden Suchbegriffe.

Danke schon mal
Frank

[eggy]

Irgendwelche acls im Weg? Aus geposteten config Dateien liest sich mehr raus als aus unserer Forenglaskugel.

[feckelm]

Moin,

ja das die configs fehlen war mir schon klar

hier die named.conf.options:

options {
<------>directory "/var/cache/bind";
<------>auth-nxdomain no; # conform to RFC1035
<------>listen-on-v6 { any; };
<------>managed-keys-directory "/etc/bind";
<------>allow-notify { 192.168.10.5; };
<------>allow-transfer { 192.168.10.5; };
<------>notify yes;
<------>allow-query-cache { any; };
<------>allow-query { any; };
<------>allow-recursion { any; };
<------>cleaning-interval 720;
<------>empty-zones-enable yes;
};

hier die named.conf.local:

key dns-dhcp-key {
algorithm HMAC-MD5;
secret geheim123;
};

zone "standorta.firma.de" {
type slave;
file "/var/cache/bind/slave/db.standorta";
masters { 192.168.10.5; };
masterfile-format text;
notify yes;
};

zone "10.168.192.in-addr.arpa" {
type slave;
file "/var/cache/bind/slave/db.192.168.10";
masters { 192.168.10.5; };
masterfile-format text;
notify yes;
};

zone "standortb.firma.de" {
allow-update { key dns-dhcp-key; };
type master;
file "/var/cache/bind/db.standortb";
notify yes;
};

zone "20.168.192.in-addr.arpa" {
allow-update { key dns-dhcp-key; };
type master;
file "/var/cache/bind/db.192.168.20";
notify yes;
};

hier die db.192.168.20:

$ORIGIN .
$TTL 43200; 12 hours
20.168.192.in-addr.arpa IN SOA dnsb.standortb.firma.de. root.standortb.firma.de (
102289 ; serial
3600 ; refresh (1 hour)
14400 ; retry (4 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS dnsb.standortb.firma.de.
$ORIGIN 20.168.192.in-addr.arpa.
12 PTR fileserverb.standortb.firma.de.

hier die db.standortb:

$ORIGIN .
$TTL 43200 ; 12 hours
standortb.firma.de IN SOA dnsb. root.standortb.firma.de. (
103349 ; serial
3600 ; refresh (1 hour)
14400 ; retry (4 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS dnsb.
$ORIGIN standortb.firma.de.
fileserverb A 192.168.20.12


hier die slave/db.192.168.10:

$ORIGIN .
$TTL 43200 ; 12 hours
10.168.192.in-addr.arpa IN SOA dnsa.standorta.firma.de. root.standorta.firma.de (
184750 ; serial
28800 ; refresh (8 hours)
14400 ; retry (4 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS dnsa.standorta.firma.de.
$ORIGIN 10.168.192.in-addr.arpa.
11 PTR fileservera.standorta.firma.de.

hier die slave/db.standorta:

$ORIGIN .
$TTL 43200 ; 12 hours
standorta.firma.de IN SOA dnsa. root.standorta.firma.de. (
114002 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
172800 ; minimum (2 days)
)
NS dnsa.
$ORIGIN standorta.firma.de.
fileservera A 192.168.10.11

[feckelm]

habe ich noch etwas vergessen?

[ThorstenS]

ohne mir die Zeit zu nehmen deine config anzuschauen, hab ich zwei Anmerkungen zum troubleshooting:

Ich teste die zonen-Übertragung immer zuerst hiermit:

Code: Alles auswählen

dig +noall +answer +onesoa +multiline @ns.StandortA StandortB axfr

Wenn das klappt, ist keine Firewall im Weg und die Zonentransfers funktionieren (sprich korrekte ACLs). Views hast du wohl nicht, kann man als Fehlerquelle ausschließen.

Dann wäre da noch die /etc/resolv.conf - überwachst du Änderungen daran mit etckepper? Dann würde dir ein „git log -p resolv.conf“ schnell Veränderungen melden.
Oder du holst dir den /etc Ordner aus deinen Sicherungen raus und vergleichst die Änderungen von mir aus auch mit meld.

Können nur die Clients die andere Seite nicht auflösen, oder auch der/die Server nicht? Benutzt vllt. dein squid einen anderen nameserver-Eintrag?
(böser Fehler, hatte ich mal…)

[feckelm]

so, folgende Ergebnisse:

wenn ich Deine dig-Zeile auf meine Umgebung anpasse: am Standort A zeigt er mir den Inhalt der passenden Zonendatei an

Code: Alles auswählen

dig +noall +answer +onesoa + multiline @dnsb.standortb.firma.de standorta.firma.de axfr

angepasst an Standort B auch das richtige Ergebnis.

Der Transfer funktioniert denke ich.
Die Zonendateien sind ja auch im Verzeichnis vorhanden.

Ja Views habe ich nicht.

In der resov.conf steht die serarch-Zeile drin, sonst nichts.

Etckeeper kannte ich bisher noch nicht, sowas hatte ich noch auf meiner todo-Liste, danke für den Tipp.

Die Auflösung ohne FQDN funktioniert nur von den Clients aus nicht, auf den beiden Server aber ohne Probleme.
Squid setze ich nicht ein, fällt also als Fehlerquelle raus, in den IP-Einstellungen der Clients steht der richtige DNS-Server drin, und er wird bei z.B. nslookup auch genutzt.

[ThorstenS]

Wenn es nur auf den Clients nicht funktioniert, dann ist dein DHCP-Server die Fehlerursache - die Clients kennen die entfernte Domain gar nicht.
Für den isc-dhcpd:

Code: Alles auswählen

option domain-search            "StandortA", "StandortB";

Damit der Einstieg in etckeeper einfacher wird, hier meine Aufzeichnungen dazu:

Code: Alles auswählen

aptitude install git etckeeper
cd /etc
etckeeper init
etckeeper commit oder git commit

git diff --color

# allg. Infos: zless /usr/share/doc/etckeeper/README.gz

# die .gitconfig schreiben:
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.logg "log --graph --date=short --format='%h [%cd] %ae: %s'"
git config --global color.ui true
git config --global color.branch auto
git config --global color.diff auto
git config --global color.interactive auto
git config --global color.status auto
git config --global  user.name "Admin"
git config --global  user.email root@$(hostname -f)
git config --global help.autocorrect 3

Oft benutze ich „git logg“, um mir eine Übersicht zu verschaffen und „git log -p .“, um die Dateiänderungen im aktuellen Ordner zu verfolgen.
etckeeper als solches rufe ich nicht auf. Änderungen werden mit „git add $DATEI“ gesammelt und mit „git ci -m "Kommentar"“ eingecheckt.
That`s it.

[feckelm]

mit der option domain-search funktioniert es auch nicht, laut Forum wird diese option nicht an Windows-Clients übertragen und würde mir auch nicht bei Clients helfen die eine feste IP haben die am Client eingetragen ist.

nslookup am client sagt mir weiterhin Non-existent domain - leider

für die etckeeper infos nochmal danke

[ThorstenS]

tja, das ist aber ein Problem der Clients. Solange sie von der anderen sites nichts wissen, kommen die nicht auf die Idee dort zu suchen.
Du mußt die Clients anfassen.

[feckelm]

mhh, hab ich schlecht formuliert...

Code: Alles auswählen

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\ich>nslookup fileservera
Server:  dnsb.standortb.firma.de
Address:  192.168.20.5

*** fileservera wurde von dnsb.standortb.firma.de nicht gefunden: Non-existent domain.

wobei aber

Code: Alles auswählen

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\ich>nslookup fileservera.standorta.firma.de
Server:  dnsb.standortb.firma.de
Address:  192.168.20.5

Name:    fileservera.standorta.firma.de
Address:  192.168.10.11

ordentlich aufgelöst wird.

Das ganze hat ja bisher auch von allen clients aus funktioniert

[eggy]

mit der option domain-search funktioniert es auch nicht, laut Forum wird diese option nicht an Windows-Clients übertragen und würde mir auch nicht bei Clients helfen die eine feste IP haben die am Client eingetragen ist.

Auch bei Windows kannst Du die Suchdomainen eintragen, war irgendwo in den DNS Einstellungen, nennt sich Domainsuffix oder DNS-Suffix. Keine Ahnung wie das in der von Dir bevorzugten Windowsversion gehandhabt wird. Notfalls gehts über die Registry.

[feckelm]

das ich bei Windows die Suchdomain eintragen kann weiß ich, aber das ist nicht meine Lösung für das Problem, das behebt nur das Symptom.

[ThorstenS]

Hat sich vllt. bei der recusrsiven Anfrage Einstellung etwas geändert?

Setz mal testweise recursion auf yes.

[feckelm]

recursion yes ändert nichts ,YES ist aber auch der default Wert

[ThorstenS]

Ok, ich kann mich daran erinnern, dass wir die Option vor einer Weile mal auf die internen Netze und unsere DNS-Server beschränkt haben.
(upsi, das war laut git log schon "Tue Jul 10 06:25:07 2012 +0200" )

Also hilfts nur noch das Logging hochzuschrauben:
http://stackoverflow.com/questions/1115 ... ll-logging

[feckelm]

hier der relevante Ausschnitt:

Code: Alles auswählen

30-Jul-2015 13:22:15.428 queries: info: client 192.168.20.216#49154 (5.20.168.192.in-addr.arpa): query: 5.20.168.192.in-addr.arpa IN PTR + (192.168.20.5)
30-Jul-2015 13:22:15.430 queries: info: client 192.168.20.216#49155 (fileservera.standortb.firma.de): query: fileservera.standortb.firma.de IN A + (192.168.20.5)
30-Jul-2015 13:22:15.430 queries: info: client 192.168.20.216#49156 (fileservera.standortb.firma.de): query: fileservera.standortb.firma.de IN AAAA + (192.168.20.5)
30-Jul-2015 13:22:15.430 queries: info: client 192.168.20.216#49157 (fileservera.firma.de): query: fileservera.firma.de IN A + (192.168.20.5)

er sucht also zuerst in der lokalen subdomain und danach in der domain, aber nicht in der zweiten subdomain.

ein ähnliches Ergebnis bringt auch

Code: Alles auswählen

nslookup -d2 fileservera

[feckelm]

verschieben wir die Lösungssuche auf Montag, ich verlängere morgen erst mal mein Wochenende

[ThorstenS]

ich auch - für 4 Wochen