DNS: conditional forwarding (BIND 9.13)

Eisenfaust

Well-Known Member
Hallo,

mein Szenario ist folgendes. Im Büro betreibe ich hinter einem NAT Router einen eigenen DNS (BIND 9.13.2 auf FreeBSD CURRENT). Im LAN befindet sich auch eine TK Anlage auf Asterisk Basis (15.5.0). Unser (noch) Telephonanbieter, Telefonica/O2, geziemt sich spärlich mit Informationen, wenn es um die Anbindung eigener TK Systeme an deren Netz geht. Bis letzte Woche Mittwoch oder Donnerstag war die TK Anlage voll funktionstüchtig, nach einem Update des OS auf CURRENT r336314 und Asterisk von 15.4.X auf die aktuelle Version 15.5.0 gibt es Probleme:

Telefonica löst den Anmeldeproxy für SIP nur innerhalb des eigenen Netzes auf, einer der DNS ist 62.109.121.1. So erfolgt die Anfrage

host sip.alice-voip.de 62.109.121.1

Using domain server:
Name: 62.109.121.1
Address: 62.109.121.1#53
Aliases:

sip.alice-voip.de has address 195.71.31.3

mit Erfolg, aus anderen Netzen nicht.

Aus Gründen, die ich hier nicht diskutieren möchte, benutze ich zur regulären Namensauflösung andere DNS anstelle der von Telefonica/O2 bereitgestellten. Um die Namensauflösung unseres internen Firmen-LAN zu bewerkstelligen, gibt es einen DNS Server, wie eingangs beschrieben. Dieser DNS Server ist "master" für die hausinternen Domänen. Im generellen Teil der named.conf sind als "forwares" die Wunschserver aufgeführt, die wir kontaktieren wollen, wenn allgemeine Anfragen gestellt werden:

options {
...
forwarder { 1.1.1.1; 9.9.9.9; };
...
};

Nun würde ich gerne - was bislang (scheinbar) auch funktionierte - Anfragen intern als DNS master selbst beantworten, Anfragen an die Domäne "alice-voip.de" an den Telefonica/O2 DNS delegieren und das, was übrig bleibt, den "forwarders" überlassen. Der Zonen-Teil sieht, wie man unschwer erahnen kann, dann so aus:

zone "alice-voip.de." IN {
type forward;
forward only;
forwarders { 62.109.121.1; };
};
};

zone "buero.intern." IN {
type master;
file "/irgend/eine/zonen-datei.db";
forwarders {};
};

Irgendetwas aber ist nun nicht korrekt in dieser Skizze, denn frage ich unseren DNS (/etc/resolv.conf enthaelt nur die IPs unserer DNS) nach

host sip.alice-voip.de

erhalte ich

Host sip.alice-voip.de not found: 3(NXDOMAIN)

Tja, und weil der Asterisk ebenfalls diese Anfrage generiert, scheitert die SIP Autorisierung.

Einen Downgrade auf die CURRENT Version vom Mittwoch sowie Asterisk 15.4.X habe ich noch nicht durchgespielt; ich bin der Ansicht, daß das Problem einzig und alleine mit der Namensauflösung zu tun hat, denn unsere Alternativleitung zu sipgate.de arbeitet, wie sollte man es bei sipgate.de auch anders erwarten, vorzüglich. Bis am Freitag arbeitete auch die Telefonica/O2 Anbindung problemlos.

Ich suche ersteinmal die Fehler/Probleme bei uns/mir. Daß die bedingte Weiterleitung von Anfragen nicht so funktioniert, wie ich mir das ausgedacht habe, macht mich etwas stutzig. Ich versuche zwar fleißig Logs via geeigneter Channel Konfigurationen mitzuschneiden, allerdings bin ich auf diesem Gebiet unbeleckt und die Anfragen an unseren DNS Server sehen "normal" aus, wenn auch negativ. Vielleicht kann mir jemand einen Tipp geben wie ich eine ventuelle Kommunikation zum Telefonica/O2 Server loggen kann. Eventuell hat O2 etwas verändert.

Danke im voraus.
};
 
Oh weh ... die Antwort kann ich mir selber geben.

BIND 9.13.2 (jüngst von 9.13.1 auf 9.13.2 angehoben) ist die Ursache! Ich bin auf 9.12.2 (dns/bind912) zurück und siehe da, alles arbeitet wieder wie es sein soll.
 
Dein Problem nennt sich wohl BIND (Buggy Internet Name Daemon). In den letzten paar Jahren sind ein paar brauchbare Alternativen entstanden. Gibt es einen guten Grund warum du dir noch BIND antust? Meistens ist man mit der Kombination aus Unbound und NSD besser bedient.
 
Mit anderen DNS bin ich nie zurecht gekommen und ich bin ein Gewohnheitstierchen - bis vor nicht allzulanger Zeit hatte FreeBSD den BIND mit an Bord.

Das Problem ist leider mir selber zuzuschreiben; FreeBSD Ports führt den BIND 9.13.X derzeit nicht mehr unter dem Etikett "Entwicklung", hierfür wurde wohl der Ports dns/bind9-devel etabliert. Das suggierierte mir, daß BIND 9.13 eine stabile version sei.

Bei näherem Hinsehen aber mußte ich erfahren, daß die ungeraden Minor-Revisionsnummern instabile (Feature-)Versionen sind. Erst 9.14 wird als "stabil" eingestuft. Und mit dem Update von bind 9.13.1 auf 9.13.2 passierte genau das, was die Doku auch sagt.

Beim BIND kann man ähnlich wie bei sendmail argumentieren: viele Bugs. Allerdings: viele bekannte Bugs! Das ist bei neueren DNS nicht immer so.

;-)
 
Zurück
Oben