2
BIND kopiert alle root-Server in Antwort
Hallo,
ich habe ein Problem mit einem BIND Server:
Stell ich an diesen Server eine Anfrage für eine Domain, die noch nicht im Cache ist (bei gecachten passiert es nicht) kopiert er eine Liste aller DNS-Rootserver mit in die Antwort:
MIr ist relativ rätselhaft warum er das macht, da er eigentlich die Rootserver gar nicht kennt und nur eine rekursive Auflösung mit einem übergeordneten Server (Microsoft DNS) machen soll (der dieses Verhalten nicht zeigt). Hier der relevante Part der Konfigurationsdatei:
Weiß jemand, woran das liegen könnte?
Grüße
Max
ich habe ein Problem mit einem BIND Server:
Stell ich an diesen Server eine Anfrage für eine Domain, die noch nicht im Cache ist (bei gecachten passiert es nicht) kopiert er eine Liste aller DNS-Rootserver mit in die Antwort:
# dig example.com @localhost
; <<>> DiG 9.3.4-P1.1 <<>> example.com @localhost
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6704
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 86124 IN A 208.77.188.166
;; AUTHORITY SECTION:
. 27656 IN NS d.root-servers.net.
. 27656 IN NS g.root-servers.net.
. 27656 IN NS l.root-servers.net.
. 27656 IN NS k.root-servers.net.
. 27656 IN NS e.root-servers.net.
. 27656 IN NS a.root-servers.net.
. 27656 IN NS b.root-servers.net.
. 27656 IN NS f.root-servers.net.
. 27656 IN NS h.root-servers.net.
. 27656 IN NS j.root-servers.net.
. 27656 IN NS c.root-servers.net.
. 27656 IN NS i.root-servers.net.
. 27656 IN NS m.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 25202 IN A 198.41.0.4
a.root-servers.net. 68601 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 21138 IN A 192.228.79.201
c.root-servers.net. 28876 IN A 192.33.4.12
d.root-servers.net. 28943 IN A 128.8.10.90
e.root-servers.net. 32415 IN A 192.203.230.10
f.root-servers.net. 29348 IN A 192.5.5.241
f.root-servers.net. 30848 IN AAAA 2001:500:2f::f
k.root-servers.net. 35878 IN A 193.0.14.129
k.root-servers.net. 37652 IN AAAA 2001:7fd::1
l.root-servers.net. 48851 IN A 199.7.83.42
l.root-servers.net. 50003 IN AAAA 2001:500:3::42
m.root-servers.net. 26368 IN A 202.12.27.33
;; Query time: 506 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 19 07:29:54 2009
;; MSG SIZE rcvd: 512MIr ist relativ rätselhaft warum er das macht, da er eigentlich die Rootserver gar nicht kennt und nur eine rekursive Auflösung mit einem übergeordneten Server (Microsoft DNS) machen soll (der dieses Verhalten nicht zeigt). Hier der relevante Part der Konfigurationsdatei:
options {
# Ordner mit allen Konfigurationsdateien
directory "/my/bind/etc";
# PID-Datei speichern nach
pid-file "/var/run/named.pid";
# NS-Server fuer weitergeleitete anfragen
forwarders {
172.16.33.2;
172.16.33.1;
};
# Erst weiterleiten, dann selbst aufloesen
forward first;
# Rekursive Abfrage erlauben
recursion yes;
# Erlaubte Client-IP-Bereiche
allow-query {
172.19.0.0/24; # WLAN-Netzwerk
172.16.0.0/16; # Normales Netzwerk
127.0.0.1; # localhost
};
};Weiß jemand, woran das liegen könnte?
Grüße
Max
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 106408
Url: https://administrator.de/contentid/106408
Ausgedruckt am: 22.11.2024 um 22:11 Uhr
2 Kommentare
Neuester Kommentar
-- verbatim kopiert von linuxforen.de -- http://www.linuxforen.de/forums/showthread.php?t=118106 -- ein beitrag von Doh!
Mythen und Legenden ranken sich - ich muss es immer wieder feststellen - um die Funktion "forward" beim beliebten Namensserver bind9 aus dem Hause ISC (um ehrlich zu sein, ich weiß nicht, ob sich das auf bind4 und bind8 übertragen lässt, aber wer nutzt die schon ?). Da ich es hier schon zig-fach falsch gelesen habe, nun als Tipp, wie die Funktion "forward" richtig anzuwenden ist:
Zunächst ein kleiner Ausflug in die Welt des DNS:
Ein Host stellt eine DNS-Query an seinen voreingestellten DNS-Server, meinetwegen lautet die Anfrage "www.linuxforen.de". Wenn der DNS-Server für die Domain nicht selbst zuständig ist und auch nicht weiß, welcher andere DNS dafür zuständig ist, so fragt der DNS-Server zunächst einen der derzeit 15 in seiner root.hint Datei hinterlegten root-Server, welche DNS-Server für die Domain "de" zuständig sind¹. Er bekommt die Antwort und fragt nun eben jenen Server an, welcher DNS-Server denn die Domain linuxforen.de betreut. Von dort aus hangelt er sich weiter bis zu dem Server, der ihm die IP von www.linuxforen.de liefern kann. Jede normale DNS-Query setzt also eine Kaskade von mindestens 3 Anfragen in Gang.
Wichtig ist auch noch sich klarzumachen, dass bind (und wohl alle anderen Nameserver auch) immer cachen. Sie speichern die zuletzt gemachten Anfragen für kurze Zeit zwischen um die Kaskade nicht ständig neu abarbeiten zu müssen. Wichtig: Dieser Cache wird immer - egal in welchem Betriebszustand forward sich gerade befindet - VOR der Kaskade befragt!
Ganz wichtig: Vor Cache und Kaskade stehen immer die eigenen (und auch deligierten) Zonen! Ein Nameserver forwarded niemals, wenn er Daten in der eigenen Datenbank oder im Cache stehen hat!
Die Funktion forward [first|only] kennt nun drei Betriebszustände (die Funktion "forward" macht natürlich nur Sinn in Verbindung mit der Funktion "forwarders { [IP-DNS1]; [IP-DNS2]};" wobei die IP's zu funktionstüchtigen DNS-Servern gehören sollten)":
Ich lese hier ganz oft, dass empfohlen wird, für's Heimnetz auf jeden Fall Forwarder einzustellen. Das macht nicht immer Sinn. Hat man z.B. eine DSL-Anbindung und nur wenige Rechner im Heimnetz, so kann man getrost auf den Forwarder verzichten, und den eigenen DNS (auch aus einem nicht-öffentlichen IP-Raum heraus) die Kaskade selbst starten lassen. Das ist meist schneller, als irgendwelche geplagten öffentlichen DNS-Server anzuhauen. Bei ISDN oder Modem-Verbindungen würde ich eher die "forward first"-Option empfehlen. Die "forward only"-Option eignet sich für das Heimnetz so gut wie nie! Man schränkt sich seinen DNS nur unnötig ein.
Hoffe ein wenig Licht in's Dunkle gebracht zu haben, nicht zu viel Unfug und Rechtschreibfehler hier eingebaut zu haben. Übrigens: ich hasse Fußnoten auch...
-- ende des zitats --
sprich, mach forward first aus, und lass den nameserver selbst auflösen.
Mythen und Legenden ranken sich - ich muss es immer wieder feststellen - um die Funktion "forward" beim beliebten Namensserver bind9 aus dem Hause ISC (um ehrlich zu sein, ich weiß nicht, ob sich das auf bind4 und bind8 übertragen lässt, aber wer nutzt die schon ?). Da ich es hier schon zig-fach falsch gelesen habe, nun als Tipp, wie die Funktion "forward" richtig anzuwenden ist:
Zunächst ein kleiner Ausflug in die Welt des DNS:
Ein Host stellt eine DNS-Query an seinen voreingestellten DNS-Server, meinetwegen lautet die Anfrage "www.linuxforen.de". Wenn der DNS-Server für die Domain nicht selbst zuständig ist und auch nicht weiß, welcher andere DNS dafür zuständig ist, so fragt der DNS-Server zunächst einen der derzeit 15 in seiner root.hint Datei hinterlegten root-Server, welche DNS-Server für die Domain "de" zuständig sind¹. Er bekommt die Antwort und fragt nun eben jenen Server an, welcher DNS-Server denn die Domain linuxforen.de betreut. Von dort aus hangelt er sich weiter bis zu dem Server, der ihm die IP von www.linuxforen.de liefern kann. Jede normale DNS-Query setzt also eine Kaskade von mindestens 3 Anfragen in Gang.
Wichtig ist auch noch sich klarzumachen, dass bind (und wohl alle anderen Nameserver auch) immer cachen. Sie speichern die zuletzt gemachten Anfragen für kurze Zeit zwischen um die Kaskade nicht ständig neu abarbeiten zu müssen. Wichtig: Dieser Cache wird immer - egal in welchem Betriebszustand forward sich gerade befindet - VOR der Kaskade befragt!
Ganz wichtig: Vor Cache und Kaskade stehen immer die eigenen (und auch deligierten) Zonen! Ein Nameserver forwarded niemals, wenn er Daten in der eigenen Datenbank oder im Cache stehen hat!
Die Funktion forward [first|only] kennt nun drei Betriebszustände (die Funktion "forward" macht natürlich nur Sinn in Verbindung mit der Funktion "forwarders { [IP-DNS1]; [IP-DNS2]};" wobei die IP's zu funktionstüchtigen DNS-Servern gehören sollten)":
- aus - indem man die Funktion komplett auskommentiert, ein "off" Schlüsselwort gibt es afaik nicht. Mit dieser Funktion ausgeschaltet verhält sich ein DNS genau so, wie oben beschrieben. Dieser Betriebszustand sollte für einen öffentlichen DNS - wie z.B. einen von T-Online oder ARCOR - gewählt werden. Im Prinzip ist es sinnvoll, alle DNS, die eine öffentliche IP besitzen, in dieser Betriebsart zu belassen, da die DNS-Anfragen in diesem Fall dann am schnellsten bearbeitet werden, zumindest wenn man eine gute Internetanbindung hat. Wichtig ist natürlich auch, dass so ein DNS - auch wenn er in einem lokalen Netz steht - eine direkte Internetanbindung benötigt, sonst kann er die Kaskade nicht starten (jaja, es gibt durchaus sinnige Varianten, in denen ein DNS nicht mit dem Internet verbunden ist!)
- first - ist diese Betriebsart gewählt, so startet der DNS bei einer Query zunächst nicht selbst die Kaskade, sondern bittet stattdessen den/die DNS-Server, die unter "forwarders" eingetragen sind, stellvertretend die Anfrage zu stellen (bzw. seinerseits die Anfrage an einen weiteren Forwarder weiterzuleiten). Sollten diese aus irgendwelchen Gründen keine Antwort liefern können, so startet der DNS-Server dann doch die Kaskade selbst. Diese Betriebsart macht z.B. dann Sinn, wenn relativ viele Hosts den DNS "quälen", dieser aber nur mit einer relativ schmalen Leitung ans Netz angeschlossen ist. Pro Anfrage gibt es nämlich ins Netz nur eine Query anstelle von dreien oder gar mehr (weil die Kaskade ja der Forwarder übernimmt). Auch hier gilt: der DNS benötigt eine Leitung ins Internet.
- only - nun macht der DNS gar nix mehr selbst (wie gesagt, in seinen Datenbanken und in den Cache schaut er natürlich trotzdem erst nach!). Diese Betriebsart wird vor allen Dingen bei sogenannten "Caching-Only"-DNS-Servern² eingesetzt, die keine direkte Anbindung ans Netz haben. Hat man zum Beispiel ein stark segmentiertes Firmen-Netz, so kann es vorkommen, dass man den Traffic innerhalb des Netzes etwas veringern will, und so in die verschiedenen Sub-Netze Caching-Only DNS-Server setzt. Diese haben oftmals gar keine Möglichkeit (wegen Firewall o.ä.) in das Internet zu kommen (sollen sie auch gar nicht), sondern die "leben" davon, ihre Anfragen an andere interne DNS-Server weiterzugeben, um ihren Cache möglichst groß zu halten. Stellt ein Server in der Betriebsart "forward only" eine Anfrage, so wird die Query an den Forwarder weitergeleitet. Wenn dieser keine Antwort weiß, so gibt der DNS-Server an den anfragenden Host eine negative Rückmeldung ohne selbst noch einmal eine Query zu versuchen.
Ich lese hier ganz oft, dass empfohlen wird, für's Heimnetz auf jeden Fall Forwarder einzustellen. Das macht nicht immer Sinn. Hat man z.B. eine DSL-Anbindung und nur wenige Rechner im Heimnetz, so kann man getrost auf den Forwarder verzichten, und den eigenen DNS (auch aus einem nicht-öffentlichen IP-Raum heraus) die Kaskade selbst starten lassen. Das ist meist schneller, als irgendwelche geplagten öffentlichen DNS-Server anzuhauen. Bei ISDN oder Modem-Verbindungen würde ich eher die "forward first"-Option empfehlen. Die "forward only"-Option eignet sich für das Heimnetz so gut wie nie! Man schränkt sich seinen DNS nur unnötig ein.
Hoffe ein wenig Licht in's Dunkle gebracht zu haben, nicht zu viel Unfug und Rechtschreibfehler hier eingebaut zu haben. Übrigens: ich hasse Fußnoten auch...
-- ende des zitats --
sprich, mach forward first aus, und lass den nameserver selbst auflösen.
sprich, mach forward first aus, und lass den nameserver selbst auflösen.
Genau andersrum wird ein Schuh draus: "only" hat mein Problem gelöst (ich brauche die Forwarder weil die Server auch noch eigene Zonen haben).
Warum er unnötigerweise alle Root-Server kopiert hat erklärt das aber nicht wirklich...
Für mich plausibel wäre nur, dass er trotz first lieber die Domain selbst auflösen wollte, ihm aber die Root hints fehlen und er darum den Forwarder nach der . Zone gefragt hat und die Antwort auch noch an die eigentliche angehängt hat.
Grüße
Max
