DNS-Probleme: Domains nicht auflösbar/erreichbar bei Bind-Resolvern und IPv6
Domainbesitzer und ISPs, die ihre authoritativen Nameserver neuerdings neben IPv4 auch mittels IPv6 anbinden ("dual stack"), sollten einen häufigen Konfigurationsfehler bei DNS-Resolvern mit Bind berücksichtigen -- sonst sind hunderte oder tausende eigene Domains schnell unerreichbar und offline. Das Symptom: Eine ganze Reihe fremder Domains waren angeblich laut DNS-Auflösung für die eigenen DNS-Resolver immer wieder zeitweise nicht auflösbar -- was beispielsweise dazu führte, daß eingehende Mails dieser Domains abgelehnt wurden ("sender domain unknown") oder auch Mails an die betroffenen Zieldomains nicht versandt werden konnten.
Domains eines bestimmten Providers waren immer wieder mal nicht erreichbar
Ein erstes Debugging im Bind-Cache der DNS-Resolver zeigte: Tatsächlich konnte dieser besagte Domains immer wieder mehrere Minuten lang nicht auflösen -- kurz darauf funktionierte es dann wieder problemlos. Wenig später schalteten die eigene DNS-Server die betroffenen Domains wieder auf nicht-auflösbar. Ein ewiges Ping-Pong-Spiel. Merkwürdigerweise waren die Domains auf verschiedenen Resolvern nicht gleichzeitig, sondern willkürlich verteilt erreichbar oder unerreichbar. Auffällig dabei: Alle Domains, bei denen dieses Problem zutage trat, gehörten zu einem einzigen ISP (amüsanterweise einem Kunden von uns, mit dem wir mittlerweile gut befreundet sind). Doch dessen Nameserver waren zu den fraglichen Ausfallzeiten problemlos und nachweisbar erreichbar. Warum die DNS-Resolver das regelmäßig anders sahen, war zunächst sehr rätselhaft.
Ein Blick ins DNS und mit tcpdump läßt eine Ahnung aufkommen
Doch der Blick in die Details offenbahrt weitere Auffälligkeiten, die stutzig werden lassen: Beide Nameserver des ISPs hatten unter ihrem Namen sowohl IPv4-, als auch IPv6-Adressen hinterlegt. Ein tieferes Debugging auf Netzwerkebene zeigte, daß der eigene Bind auch immer wieder versuchte, die fremden Nameserver auch auf IPv6-Ebene zu erreichen, was jedoch in der Firewall für ihn gar nicht freigeschaltet war (hier waren die eigenen DNS-Resolver falsch konfiguriert!). Des Rätsels Lösung: Obwohl die Namen "ns1.example.com" und "ns2.example.com" zu jederzeit problemlos über IPv4 zu erreichen waren, führten die IPv6-Timeouts immer wieder dazu, daß Bind für sich annahm, die beiden Nameserver seien gar nicht zu erreichen, egal mit welchem Protokoll -- und diesen Zustand dann auch minutenlang cachte. Welcher Zustand vorrang hatte (IPv4 = geht, IPv6 = geht nicht) war anscheinend Zufall und führte am Ende genau zum Ping-Pong-Verhalten "geht -- geht nicht -- geht -- geht nicht". In der Folge warum damit dramatischerweise auch alle Domains dieses Providers, die in ihren NS-Records ja immer auf diese zwei fraglichen Nameserver verwiesen, vollständig unerreichbar, da die Auflösungskette zu diesen Domains an der Erreichbarkeit der authoritativen Namesrver scheiterte. Ganze Domains wurden schlagartige in ihrer Sichtbarkeit an- oder ausgeknipst. Das Bind hier nicht in der Lage war sauber auseinander zu halten, mit welchem Protokoll die Server zuverlässig zu erreichen waren, würde ich nach jetzigem Kenntnisstand als Bug in Bind bewerten...
Die eigentliche Ursache: Ein allzu häufiger Konfigurationsfehler beim DNS-Resolver
Eigentliche Ursache war natürlich ein klarer Konfigurationsfehler bei unseren Nameservern, denn wer keinen IPv6-Uplink hat, sollte auch nicht auf IPv6 konfiguriert sein -- leider geschieht das bei vielen Distributionen nur allzu schnell und allzu automatisch und unbemerkt und ein normaler Bind will dann natürlich auch prompt von allen Möglichkeiten Gebrauch machen. Obwohl wir daraufhin IPv6 von den Servern wegkonfiguriert haben meinen wir, auch danach noch Verwirrung bei Bind ob der IPv6-Records festgestellt zu haben. Das dürfte nicht sein, doch haben wir weiterhin Klagen über die Nicht-Erreichbarkeit der IPv6-Records im Bind-Debugging gefunden. Womit Bind ja recht hat -- mangels IPv6 waren die Systeme ja wirklich nicht über IPv6 erreichbar -- er hätte es nur von vornherein nicht auf diesem Weg versuchen dürfen.
Zu 100% haben wir das jedoch dann nicht mehr verifiziert. Stattdessen haben wir recht schnell Bind selbst umkonfiguriert und zwangsweise auf IPv4-Only geschaltet, weil wir weitere Ausfälle nicht mehr auf den produktiven Systemen hervorrufen wollten.
Die Lösung: Bind auf Resolvern mit "-4" als Aufrufparameter starten
Erst als Bind selbst auf den Resolvern durch den Aufrufparameter "-4" zwangsweise auf IPv4-Only geschaltet wurden, hörten alle Auflösungsprobleme schlagartig auf.
- Bei SUSE-Systemen sollte in /etc/sysconfig/named der Eintrag NAMED_ARGS="-4" gesetzt werden.
- Bei Debian-Systemen kann in /etc/defaults/bind der Eintrag OPTIONS="-4" genutzt werden.
Die zunehmende Verbreitung von IPv6-Records auf für Nameserver kann also dafür sorgen, daß man seinen eigenen Bind-Resolver rechtzeitig darauf überprüfen sollte, ob IPv6 parallel genutzt wird und auch tatsächlich funktioniert -- und falls nicht (was der Regelfall sein dürfte) sollte man IPv6 durch den Bind-Aufrufparameter "-4" gleich von vornherein deaktivieren.
DNS-Server nicht vollständig auf IPv6 umstellen!
Betreiber von autoritativen DNS-Servern hingegen sollten sich tunlichst überlegen, ob sie derzeit schon alle Nameserver sowohl mit IPv4 als auch mit IPv6-Adressen ausstatten. Will man seine eigene Connectivity nicht riskieren sollte man besser einen DNS-Resolver stets auf IPv4 belassen. Technisch richtig, aber praktisch suboptimal/riskant:
ns1.example.com. 300 IN A 213.17x.xxx.3 ns1.example.com. 78711 IN AAAA 2001:xxxx::12:30 ns2.example.com. 300 IN A 213.17x.xxx.4 ns2.example.com. 78711 IN AAAA 2001:xxxx::12:40
Besser ist es, für ns2.example.com aus taktischen Gründen auf IPv6 zu verzichten:
ns1.example.com. 300 IN A 213.17x.xxx.3 ns1.example.com. 78711 IN AAAA 2001:xxxx::12:30 ns2.example.com. 300 IN A 213.17x.xxx.4
So können auch "falsch" konfigurierte DNS-Resolver stets zuverlässig auflösen, weil ein möglichens Ping-Pong-Spiel nur auf ns1 stattfinden kann, ns2 aus Sicht der Resolver jedoch immer zuverlässig (über IPv4 only) erreichbar ist und damit auch die darauf liegenden Domains erreichbar bleiben.
Kommentare
5 Antworten zu DNS-Probleme: Domains nicht auflösbar/erreichbar bei Bind-Resolvern und IPv6
Es ist meines Erachtens eine äußerst schlechte Idee, den Betreibern von DNS-Servern zu empfehlen, bei einigen NS-Records keinen AAAA-Record (sondern nur einen A-Record) zu hinterlegen. Schließlich ist IPv6 zum einen die Zukunft und wer zum anderen einen eigenen DNS-Server (und sei es nur für Caching DNS) aufsetzt, sollte meines Erachtens schon etwas von IPv4, IPv6 und DNS verstehen. Alternativ bleibt ja immer noch der fertig konfigurierte und meist gepflegte DNS-Server des eigenen Providers oder im Zweifelsfalle sogar die DNS-Server von Google für die eigene /etc/resolv.conf. Aber will man heutzutage wirklich nur mit "Legacy IP" leben? ;-)
Dazu kommt, dass der Vorschlag, BIND mit "-4" zu starten, auch nicht alle Probleme löst: Gerade ältere Systeme haben eine seltsam verhaltende (oder von der Linux-Distribution gar kaputt gepatchte) libresolv-Bibliothek, die für weitere lustige Effekte sorgen kann. Und nicht zu vergessen ist, dass auch BIND mit "-4" gestartet natürlich eventuelle AAAA-Records der Domains zurückliefert, mit welchen so manche Software leider immer noch nicht klar kommt und neue nette Probleme produziert - eine Filter-Möglichkeit für AAAA-Records kommt aber in BIND 9.10.
Der "Bug" auf den im Blog-Beitrag angespielt wird, ist ein Verhalten, dass es gemäß RFC 3484 sowieso gar nicht erst geben sollte, da: "[...] But if the node has assigned only a link-local IPv6 address and a global IPv4 address, then IPv4 is the best choice for communication. [...]".
Daher: Kann es sein, dass der BIND aus dem Beispiel einfach etwas älter ist? Mit einem derzeit halbwegs aktuellen BIND 9.8.x oder gar 9.9.x kann ich die Problematik nicht mehr reproduzieren, mit älteren BIND-Versionen hingegen schon...
Um abschließend die Liste im Blog-Eintrag zu ergänzen: Bei Red Hat und Fedora gibt es die Datei /etc/sysconfig/named, in welcher man den Eintrag OPTIONS="-4" setzen kann. Aber wie bereits zuvor angedeutet, löst das nicht zwangsläufig alle Probleme. Denn was ist mit der ganzen restlichen IPv6-untauglichen/-halbtauglichen Software auf einem (älteren) System?
Natürlich kann/muß/sollte mittelfristig das "-4" wieder weg, sobald IPv6 auch soweit verbreitet ist, daß nicht ständig überall Konfigurationsfehler entstehen. Das muß sich halt erst einreiten. Momentan ist es aber nunmal so, daß ein ISP, der "voll auf IPv6 fährt" am Ende mit seinen Diensten und Kunden halt relevant nicht-erreichbar ist -- und das ist tödlich, auch wenn er "Recht" hat und es "richtig" macht.
Daß ein IPv4-Resolver auch AAAA-Records zurückliefert ist klar -- und ja auch gut so. Schließlich müssen "echte" IPv6-Systeme auch mit IPv4-Resolvern arbeiten können müssen. Daß es ganz analoge "Nicht-Erreichbarkeitsprobleme" dann bei anderen Diensten ist, ist auch klar -- Postfix-Mailserver könnten ganz analog zu diesem Problem hier versuchen, die Gegenstelle per IPv6 zu erreichen, die Firewall blockt das dann, die Mails rennen in einen Timeout und werden nach einigen Tagen gebounct. Darum sollte man in solchen Setups natürlich auch Mailserver nicht mit IPv6 konfigurieren, wenn es gar keinen IPv6-Upstream gibt -- oder man stellt Postfix ganz analog zu Bind mittels "inet_protocols = ipv4" auf IPv4-Zwang um. Aber wie gesagt: Diese ganzen Probleme treten immer auf, egal ob Bind mit IPv4 oder IPv6 läuft, solange der nicht filtert.
Das Beispiel ist übrigens top-aktuell und letzte Woche passiert und spielte auf einem BIND 9.9.3.
Sehr interessant! Danke für die Information. Ich Habe aktuell noch Resolver die über Bind 9.7 (Ubuntu 10.04) laufen. Ich stelle, mangels nicht vorhandenem IPv6 Netz jedoch das ganze IPv6 auf dem Betriebsystem ab. (In der sysctl.conf mittels "net.ipv6.conf.all.disable_ipv6 = 1") und habe dem Bind selbst in der Konfiguration "listen-on-v6 { none; };" mitgegeben. Ich meine mich zu erinnern das einige Dienste auch nicht starten wenn IPv6 nicht klappt, sie aber den Port daraf binden wollen. Könnt Ihr sagen ob das "reicht" bzw. kurz erläutern wie bzw. mit welcher Domäne man das testen kann?
Weil es mir gerade noch aufgefallen ist: Wer RFC2606 folgt, wird auch um Beachtung von RFC3849 und RFC5737 gebeten...die IP-Adressbereiche werden schließlich nicht zum Spaß vergeudet! ;-)
Interessant wieviele Internetseiten noch nicht über IPv6 laufen.
Einfach mal in den Netzwerkeinstellungen TCP-IPv4 ausschalten....
Also seit 2013 (wie hier der Beitrag) hat sich noch nicht sehr viel getan.
So viele machen ordentlich Kohle mit den Portmappern oder der gleichen.
Schade das nicht alle endlich mal auf den IPv6 Zug aufspringen....