Dns-Server "forwarded" nur!?
Sven
- internet-anbindung
0 Sven Rautenberg0 Sven0 nobody0 Sven
0 Sven Rautenberg0 Sven
Hello,
ich habe meinen DHCP-Server endlich dazu bekommen, dass er als primären DNS-Server das angibt, was er angeben soll.
Entsprechend gibt mir "ipconfig /all" auf einer W2k-Konsole folgendes aus:
. . .
Standardgateway . . . . . . . . . : 192.168.1.1
DHCP-Server . . . . . . . . . . . : 192.168.1.1
DNS-Server. . . . . . . . . . . . : 192.168.1.2
194.98.0.1
. . .
Die Statistiken meines DNS-Server's verraten mir jedoch...
isdn-router:/Status/TCP-IP-Statistik/DNS-Statistik
dir
LAN-Rx INFO: 49
LAN-Tx INFO: 3
WAN-Rx INFO: 0
WAN-Tx INFO: 0
Forwarded INFO: 46
Fehler INFO: 0
DNS-Zugriffe INFO: 2
DHCP-Zugriffe INFO: 0
Filter INFO: 0
Hit-Liste TABINFO: 64 x [Domain,Requests,Time,IP-Adresse]
Werte-loeschen AKTION:
...dass mein kleiner DNS-Server hier nur die Arbeit abschiebt, und zwar an seinen großen Bruder, die 192.168.1.1. Dieser scheint dann direkt 194.98.0.1 zu konsultiern.
Das Problem ist folgendes: Probeweise habe ich bei meinem DNS-Server mal 3 Domains registriert:
192.168.1.1 -> router
192.168.1.2 -> isdn-router
192.168.1.20 -> backup.sven
fakt ist, dass die Namensauflösung _nicht_ funktioniert (ping backup.sven -> "Unbekannter Host backup.sven."). Bzw. ganz offensichtlich nicht. In wirklichkeit funktioniert sie nämlich:
C:>nslookup
192.168.1.1
Server: isdn-router
Address: 192.168.1.2
Name: router
Address: 192.168.1.1
(Eingabe in die Konsole eines Windows-Rechners)
Was ist hier falsch? Wieso funktioniert dort die Namensauflösung, warum hier nicht (oder auch andersrum)?
Kann mir jemand helfen? Hat jemand irgendeine Idee?
Gruß,
Sven
Moin!
Zunächst mal ein paar grundsätzliche Infos zu Nameservern:
Es gibt zwei verschiedene Typen von Nameservern. Die einen sind dazu da, Informationen über bei ihnen gespeicherte Rechnernamen und IPs an jeden, der fragt, herauszugeben. Die anderen sind dazu da, Informationen bei anderen Nameservern zu beschaffen.
Die Unterscheidung ist also das Merkmal: Besitzt der Nameserver eine eigene Liste mit Namensauflösungen, die der Admin ihm gegeben hat, oder ist er nur dazu da, für seine Clients im Internet nach aufzulösenden Namen zu forschen.
Diese Art der Trennung, dass nämlich ein authoritativer Nameserver wirklich nur Anfragen, für die er aufgrund seiner Datenbank zuständig ist, beantwortet, aber nicht selbst im Netz bei anderen Nameservern anfragt, ist von diversen Fachleuten, unter anderem der ISC (die sind u.a. für die Programmierung von BIND zuständig) empfohlen. Authoritative Nameserver haben oft genug damit zu tun, Anfragen für ihre eigenen Zonen zu beantworten - da wäre es äußerst hinderlich, wenn man sie noch für irgendwelchen anderen Namensauflösungen mißbrauchen könnte.
Für diese "andere" Namensauflösungen sind sogenannte DNS-Caches zuständig. Die arbeiten vollkommen im Rahmen der Spezifikationen für Nameserver, sie speichern die empfangenen Antworten aber auch zwischen, solange sie das dürfen (das erlaubt bei weiteren Nachfragen nach derselben Domain schnellere Antworten), sie beantworten aber keinerlei Fragen nach irgendeiner selbstdefinierten eigenen Zone.
Der bekannteste Nameserver, BIND, hält sich leider nicht an diese Trennung, weshalb er scheinbar sehr leicht einzurichten ist. Ich persönlich bevorzuge DJBDNS, weil man da recht einfach Anfragen nach bestimmten Domains (beispielsweise die des eigenen Intranets - oder auch die von diversen Werbedomains) von dem üblichen "Ich frage das Internet"-Mechanismus ausnehmen und auf den eigenen zweiten Nameserver umbiegen kann.
Konkret zu deiner Frage: Solange du den verwendeten Nameserver nicht angibst, kann man dir schwer helfen. Ich habe für einen Augenblick den Eindruck gehabt, du hättest nach dem Vorbild der Aufgabentrennung tatsächlich zwei Nameserver, einen für deine Intranet-Zone, und einen als Cache.
Aber egal, ob du nun einen oder zwei eigene Nameserver hast: Deine Clients sollten per DHCP nur DEINEN Nameserver kennen, nicht aber den offiziellen deines Providers. Denn dafür hast du ja deinen Intranet-Nameserver, damit der gesammelt für alle Clients Namensanfragen auflöst.
192.168.1.1 -> router
192.168.1.2 -> isdn-router
192.168.1.20 -> backup.sven
Es ist eine gute Idee, nicht nur nackte Namen zu definieren, wie in den ersten beiden Fällen, sondern tatsächlich echte Domains und Top-Level-Domains zu verwenden. Gewisse Mechanismen benötigen dies (beispielsweise Cookies).
Hinsichtlich der Top-Level-Domain kannst du dir natürlich irgendwas ausdenken - es gibt aber auch definierte Domains, die nie im Internet Verwendung finden werden: ".test", ".invalid" und ".example", wobei .test sich noch am ehesten anbieten würde - ist immerhin das kürzeste.
- Sven Rautenberg
Hallo Sven,
Es gibt zwei verschiedene Typen von Nameservern. Die einen sind dazu da, Informationen über bei ihnen gespeicherte Rechnernamen und IPs an jeden, der fragt, herauszugeben. Die anderen sind dazu da, Informationen bei anderen Nameservern zu beschaffen.
autoritative Nameserver und nicht-autoritative Nameserver, stimmts?
Konkret zu deiner Frage: Solange du den verwendeten Nameserver nicht angibst, kann man dir schwer helfen.
Tja, leider habe ich nicht so viel Computer (schön wär's), diese beiden Server sind eben leider nur 2 Hardwarerouter. Der eine, 192.168.1.1, ist der DSL-Router und somit Gateway, DHCP-Server und DNS-Cache. Der andere, 192.168.1.2, _kann_ ein ISDN-Router sein, also Gateway, und dazu noch DHCP-Server und DNS-Server. Ich möchte nur den DNS-Server nutzen, alles andere ist deaktiviert. Müsste eigentlich auch funktionieren.
Ich habe für einen Augenblick den Eindruck gehabt, du hättest nach dem Vorbild der Aufgabentrennung tatsächlich zwei Nameserver, einen für deine Intranet-Zone, und einen als Cache.
mehr oder weniger. 192.168.1.1 ist ja auch DHCP-Server, macht also die Namensauflösung für die Computer, die sich ein DCHP-Lease und somit eine IP-Adresse geschnappt haben. Dieses Ding (Daydrek Vigor 2500WE) hat keinen eigenen DNS-Server, aber wie oben beschrieben, DNS-Cache.
192.168.1.2 hat einen eigenen Nameserver und soll deswegen zusätzliche Namensauflösung im Intranet betreiben, genau. Dieser Nameserver soll eigentlich _nicht_ bei anderen Nameservern nachfragen, also nicht nicht-autoritativ sein. Tut er aber dummerweise, wenn er's nicht weiß. Dann fragt er nämlich bei 192.168.1.1 nach. Und dieser schaut dann in seinem DNS-Cache nach oder fragt irgendeinen Nameserver im Internet.
Aber egal, ob du nun einen oder zwei eigene Nameserver hast: Deine Clients sollten per DHCP nur DEINEN Nameserver kennen, nicht aber den offiziellen deines Providers. Denn dafür hast du ja deinen Intranet-Nameserver, damit der gesammelt für alle Clients Namensanfragen auflöst.
hmm... generell eine gute Idee. Ich weiß zwar nicht, wie ich meinen DHCP-Server dazu bewegen soll, die IP des sekundären DNS-Servers nicht vom ISP zu besorgen, aber egal.
Ich werde es auf jeden Fall mal ausprobieren.... - ansonsten ist es nicht so optimal, da ich mein LAN in Hinsicht Computer-aus schützen wollte: Wenn der DNS-Server 192.168.1.2 nämlich mal aus ist, dann läuft nix mehr in Punkto Namensauflösung. Das ist schlecht.
192.168.1.1 -> router
192.168.1.2 -> isdn-router
192.168.1.20 -> backup.sven
Es ist eine gute Idee, nicht nur nackte Namen zu definieren, wie in den ersten beiden Fällen, sondern tatsächlich echte Domains und Top-Level-Domains zu verwenden. Gewisse Mechanismen benötigen dies (beispielsweise Cookies).
ja - aber mir geht es bei diesen beiden Namensauflösungen lediglich um Effektivität, und Cookies spielen da insgesamt keine Rolle. Wildcard's unterstützt der DNS-Server sowieso nicht, deswegen - naja.
Hinsichtlich der Top-Level-Domain kannst du dir natürlich irgendwas ausdenken - es gibt aber auch definierte Domains, die nie im Internet Verwendung finden werden: ".test", ".invalid" und ".example", wobei .test sich noch am ehesten anbieten würde - ist immerhin das kürzeste.
wie - d.h. ".text", usw. ist _verboten_?
Freundliche Grüße,
Sven
die beiden hardware-router werden nicht zu einer gewünschten arbeitsweise gebracht werden können.
selbst wenn der dsl-router dns-cache hat und der isdn-router ein paar dns-einträge verwalten kann.
das liegt ganz einfach an dem prinzip:
die router haben eine LAN seite und eine WAN seite.
üblicherweise verhalten sie sich dabei an der LAN seite wie ein dns-server (bind). an der WAN seite benehmen sie sich wie ein client.
für eine sinnvolle zusammenarbeit müßten die beiden router in serie (hintereinander) geschaltet werden. also die WAN seite des zweiten in die LAN seite des ersten, wobei der erste mit der WAN seite ins internet geht und der zweite mit der LAN seite die clients bedient.
hier gibts dan das problem der unpassenden elektischen interfaces:
mann kann zwar die WAN seite des dsl-routers mit der LAN seite des isdn-routers verbinden, muß dann aber via isdn ins internet. das ist jedoch nicht gewollt.
aber man kann nicht die WAN seite des isdn-routers mit der LAN seite des dsl-routers verbinden, da die elektischen interfaces völlig verschieden sind. es ginge nur mit einem zusätzlichen isdn-router, welcher mit der LAN seite mit der LAN seite des dsl-routers verbunden ist.
auch dann hätte man einen bottleneck, da isdn nur 64/128 kbit/s kann.
es gibt nur eine sinnvolle lösung:
beide router parallel betreiben, wobei der isdn-dns ja lokale auflösungen erledigen kann. am client müssen dann beide dns eingetragen werden.
Hola nobody,
die beiden hardware-router werden nicht zu einer gewünschten arbeitsweise gebracht werden können.
ehm - tolles statement ;)
selbst wenn der dsl-router dns-cache hat und der isdn-router ein paar dns-einträge verwalten kann.
genau so ist es.
die router haben eine LAN seite und eine WAN seite.
will ich doch hoffen - sonst wären es ja keine Router.
üblicherweise verhalten sie sich dabei an der LAN seite wie ein dns-server (bind). an der WAN seite benehmen sie sich wie ein client.
jo.
für eine sinnvolle zusammenarbeit müßten die beiden router in serie (hintereinander) geschaltet werden. also die WAN seite des zweiten in die LAN seite des ersten, wobei der erste mit der WAN seite ins internet geht und der zweite mit der LAN seite die clients bedient.
oh nein, das müssen sie nicht, glaub mir.
hier gibts dan das problem der unpassenden elektischen interfaces...
logisch.
beide router parallel betreiben, wobei der isdn-dns ja lokale auflösungen erledigen kann. am client müssen dann beide dns eingetragen werden.
Ich nehme jetzt mal die Router auseinander und mal dir mein LAN auf:
Splitter S0-Ausgang für NTBA
| | (nicht angeschlossen)
| |
| |
+- -|- - - - - - - - -+ +- - -|- - - - - - - - - - - --+
. | DSL- ROUTER . . | ISDN - ROUTER .
. | . . | .
. +---------------+ . . +------------------+ .
. | Gateway | . . | DNS-Server | .
. | DNS-Cache | . . | DHCP-Server<----------+ .
. | WLAN-AP | . . | Gateway<--------------+ DEAKTIVIERT
. | DHCP-Server | . . | ISDN-Capi-server <----+ .
. +---------------+ . . +------------------+ .
. | . . | .
. +---------------+ . . +------------------+ .
. | 100mbit switch| . . | 10mbit hub | .
. +---------------+ . . + +-----------+ .
. | | | | . . |UPLINK| | | | | .
+- -|- -|- - | -|- - -+ +- - - -|- - - | -|- | | - - --+
| | | | | | | | |
| | | +-------------------+ | | | +---+
| | | | | FREI |
| | Comp3 | Comp5 FREI
Comp1 Comp2 Comp4
So. Comp1, Comp2, Comp3, Comp4, Comp5, DSL-Router sowie ISDN-Router können allesamt ohne Probleme kommunizieren. D.h. ich nutze den ISDN-Router zur Zeit eigentlich nur als Hub. Ich könnte aber den DNS-Server noch dazu nutzen und würde das auch gerne tun.
Genau.
viele grüße,
sven
Moin!
192.168.1.2 hat einen eigenen Nameserver und soll deswegen zusätzliche Namensauflösung im Intranet betreiben, genau. Dieser Nameserver soll eigentlich _nicht_ bei anderen Nameservern nachfragen, also nicht nicht-autoritativ sein. Tut er aber dummerweise, wenn er's nicht weiß. Dann fragt er nämlich bei 192.168.1.1 nach. Und dieser schaut dann in seinem DNS-Cache nach oder fragt irgendeinen Nameserver im Internet.
Das ist aber doch eigentlich die beste Konfiguration. Wenn Clients nämlich zwei Nameserver definiert haben, werden die nacheinander abgearbeitet. Wenn der erste nicht antwortet, wird der zweite gefragt. Das dauert. Da ist es besser, wenn der einzige gefragte Nameserver immer antwortet und im Zweifel halt anderswo nachfragt.
hmm... generell eine gute Idee. Ich weiß zwar nicht, wie ich meinen DHCP-Server dazu bewegen soll, die IP des sekundären DNS-Servers nicht vom ISP zu besorgen, aber egal.
Wenn dieser Router einen DNS-Cache hat, dann sollte er dadurch grundsätzlich Server-Funktionalität mitbringen. D.h. UDP- und TCP-Port 53 sind offen. Da ist es irgendwie unsinnig, den DHCP-Clients was anderes als diesen DNS-Server bekannt zu machen. Aber vermutlich läßt dich da die Konfigurationsmöglichkeit wieder mal allein.
Für manche Router gibts übrigens die Chance, das bereits darauf installierte Linux durch ein vernünftiges Linux zu ersetzen. Da solltest du dich vielleicht mal umsehen. :)
Ich werde es auf jeden Fall mal ausprobieren.... - ansonsten ist es nicht so optimal, da ich mein LAN in Hinsicht Computer-aus schützen wollte: Wenn der DNS-Server 192.168.1.2 nämlich mal aus ist, dann läuft nix mehr in Punkto Namensauflösung. Das ist schlecht.
Sowas darf sowieso nicht passieren. Die Namensauflösung ist eines der zentralen, notwendigen Funktionalitäten, ein Ausfall derselben ist immer böse. Sorge einfach dafür, dass der Nameserver erreichbar ist.
192.168.1.1 -> router
192.168.1.2 -> isdn-router
192.168.1.20 -> backup.svenEs ist eine gute Idee, nicht nur nackte Namen zu definieren, wie in den ersten beiden Fällen, sondern tatsächlich echte Domains und Top-Level-Domains zu verwenden. Gewisse Mechanismen benötigen dies (beispielsweise Cookies).
ja - aber mir geht es bei diesen beiden Namensauflösungen lediglich um Effektivität, und Cookies spielen da insgesamt keine Rolle. Wildcard's unterstützt der DNS-Server sowieso nicht, deswegen - naja.
Sofern einer dieser Rechner einen Webserver enthält, wird dieser Cookies setzen wollen. Und wenn der Webserver nicht unter einer vernünftigen Webadresse als virtueller oder echter Host erreichbar ist, werden die Browser das Setzen der Cookies verweigern. Sofern du also mit irgendwelchen Cookie-Experimenten mal Probleme hast: Daran liegts dann, wenn alles andere ausgeschlossen ist.
wie - d.h. ".text", usw. ist _verboten_?
Das Internet funktioniert nicht durch Verbote, sondern nur durch Ratschläge, wie man gewisse Dinge sinnvollerweise tun sollte, weil andere sie genauso tun, und man deshalb besser zusammenarbeiten könnte.
Du kannst dir jederzeit jede beliebige Top-Level-Domain ausdenken, die du magst. Sobald diese aber mal offiziell online geht, hast du zumindest mit der Erreichbarkeit der von dir definierten Domains ein Problem, weil die sich überlappen. Dann mußt du deine eigenen Namen umändern - wenn du Pech hast, bedeutet das viele spannende Überraschungen in allen möglichen Skripten, weil du vielleicht deine bisherigen Namen aus Einfachheitsgründen irgendwo hartcodiert reingeschrieben hast. Mindestens aber musst du alle deine Bookmarks überarbeiten, was entweder wenig oder viel Arbeit ist.
- Sven Rautenberg
Moin Sven,
Das ist aber doch eigentlich die beste Konfiguration. Wenn Clients nämlich zwei Nameserver definiert haben, werden die nacheinander abgearbeitet. Wenn der erste nicht antwortet, wird der zweite gefragt. Das dauert.
ehm - die haben zwei Nameserver definiert. Nur der erste wird immer befragt, und der forwarded ja immer zum 192.168.1.1, der dann - wenn er es weiß - aus dem DNS-Cache lädt, ansonsten eben "das internet" befragt.
Da ist es besser, wenn der einzige gefragte Nameserver immer antwortet und im Zweifel halt anderswo nachfragt.
hm - und wenn dieser einzige Nameserver down ist, dann gibt's keine Namensauflösung mehr ;-)
Wenn dieser Router einen DNS-Cache hat, dann sollte er dadurch grundsätzlich Server-Funktionalität mitbringen. D.h. UDP- und TCP-Port 53 sind offen.
*nachschau* - nein, weder noch. Offen sind (bei den Ports < 1000) nur bei TCP: 7,9,13,17,19,80,135,445; UDP: 7,9,13,17,19,161,445,515.
Also natürlich lokal. Nicht auf der WAN-Seite.
Beim ISDN-Router (192.168.1.2) sind bei TCP _nur_ Port 23 offen. Hm - komisch.
Die Daten habe ich mit einem Portscanner rausbekommen - anscheinend steht nicht dabei, auf welchen ports gelauscht wird, denn z.B. ist der Telnet-Port 23 auch beim 192.168.1.1, also dem dsl-router, offen, d.h.an ihm wird gelauscht.
Da ist es irgendwie unsinnig, den DHCP-Clients was anderes als diesen DNS-Server bekannt zu machen. Aber vermutlich läßt dich da die Konfigurationsmöglichkeit wieder mal allein.
ehm - der Router ist kein DNS-Server, sondern DNS-Cache. Kein Server intus [;)]. Deswegen ja der isdn-router.
Oder wie meinst du das?
Für manche Router gibts übrigens die Chance, das bereits darauf installierte Linux durch ein vernünftiges Linux zu ersetzen. Da solltest du dich vielleicht mal umsehen. :)
ob da ein linux drauf ist? Vielleicht eher irgendeine selbstgeschnippelte unix-distribution (muss ja nicht immer linux sein ;o) - aber "keine Ahnung". Wie sollte ich das rausfinden? Ich glaube nicht mal, dass die Festplatte darauf (der lautstärke zu urteilen hat es keine) ein ganzes linux fassen würde.
Ansonsten wäre das natürlich wahnsinnig toll! Dummerweise gibt es nur einen tftp-Server - wie soll ich da ein ganzes linux draufladen - oder überhaupt lässt sich nur Firmware draufladen - und üblicherweise stellen Firmen bei solcher keinen Sourcecode der Firmware bereit ;)
Ansonsten: Vigor2500WE heißt das Ding von Draytek.
Sowas darf sowieso nicht passieren. Die Namensauflösung ist eines der zentralen, notwendigen Funktionalitäten, ein Ausfall derselben ist immer böse. Sorge einfach dafür, dass der Nameserver erreichbar ist.
Ist er ja ansonsten auch sehr oft - die 192.168.1.1. Nun will ich halt die 192.168.1.2 zum Nameserver machen - aber man weiß ja nie, ich habe so ein paar "Energiespaarfuzies" im haus, die das ding auch einfach abschalten würden (kein Witz: Der Router sowie der ISDN-Router wird täglich etwa 5 mal an und aus gemacht - weil diese Leute meinen, es wäre so besser (...)).
ja - aber mir geht es bei diesen beiden Namensauflösungen lediglich um Effektivität, und Cookies spielen da insgesamt keine Rolle. Wildcard's unterstützt der DNS-Server sowieso nicht, deswegen - naja.
Sofern einer dieser Rechner einen Webserver enthält, wird dieser Cookies setzen wollen.
Mein Rechner (backup.sven) enthält einen Webserver. der DSL-Router (192.168.1.1) enthält einen Webserver. Und wenn überhaupt, dann will nur meiner ein Cookie setzten. Eigentlich auch ohne Probleme.
Und wenn der Webserver nicht unter einer vernünftigen Webadresse als virtueller oder echter Host erreichbar ist, werden die Browser das Setzen der Cookies verweigern.
Ja? D.h. sie verweigern es, wenn 123.225.127.210 ein Cookie setzten will?
Sofern du also mit irgendwelchen Cookie-Experimenten mal Probleme hast: Daran liegts dann, wenn alles andere ausgeschlossen ist.
aha. oho.
Du kannst dir jederzeit jede beliebige Top-Level-Domain ausdenken, die du magst. Sobald diese aber mal offiziell online geht, hast du zumindest mit der Erreichbarkeit der von dir definierten Domains ein Problem, weil die sich überlappen. Dann mußt du deine eigenen Namen umändern - wenn du Pech hast, bedeutet das viele spannende Überraschungen in allen möglichen Skripten, weil du vielleicht deine bisherigen Namen aus Einfachheitsgründen irgendwo hartcodiert reingeschrieben hast. Mindestens aber musst du alle deine Bookmarks überarbeiten, was entweder wenig oder viel Arbeit ist.
Ok, dann gebe ich meinem LAn eben doch nicht die Top-Level-Domain "com" ;)
Gruß,
Sven