19
DeutschlandLAN der Telekom - welche internen IPs?
Ein Kunde von mir hat sich DetschlandLan der Telekom hinstellen lassen und möchte nun, dass ich das in seinen Internetzugang mit einbinde. Das Verlangen ist verständlich, er hat sein neues Betriebsgelände in einer kostengünstigen Industriebrache mit ansonsten miserablen Anschlussbedingungen (2x Vodafone DSL mit 2 MBit!). Die beiden Anschlüsse laufen auf den Loadbalancer eines Lancom Router 1782, das DeutschlandLAN soll da einfach mit dazu.
Leider war ich bei der Installation nicht vor Ort. Der Telekom-Techniker hat kabelseitig eine Art Endgerät dagelassen, was wiederum mit dem WAN-Anschluss eines Routers Cisco 800 verbunden ist, der offensichtlich an seinen 4 Switchports den Kundenzugang bereitstellen soll. Der Anschluss ist inzwischen freigeschaltet. Ein testweise angeschlossenes Notebook erhielt per DHCP aber keine IPV4-Adresse zugewiesen, eine fest eingestellte IP (als Gateway zu verwenden?) ist nicht bekannt. Der Cisco 800 ist doch da als Router, oder?
Auf Nachfrage erhielt ich folgende Info: "... Ihr IPv4 80.x.x.160/29 Adressbereich ist klassisch geroutet. Adressen: Netz - Broadcast 80.x.x.160 - 80.x.x.167, Gateway 80.x.x.161/29 (255.255.255.248)"
Das sind m.E. doch die externen Adressen, oder? Ein Lookup weist den Bereich jedenfalls der Telekom zu. Aber was interessiert mich bei WAN-Adressen ein Gaetway? Und wie kann - falls das Gateway .161 sich auf die LAN-Seite bezieht - diese innerhalb des gleichen Subnetztes liegen, wie die WAN-Seite?
Bin total verwirrt und bitte um hilfreiche Denkanstöße. Danke.
Eine weitere Nachfrage beim Service ergab die wenig hilfreiche Antwort, dass man sich prinzipiell nicht um die internen Adressen der Kunden kümmere - was für sich alleine ja auch sinnvoll ist. Aber da ich auch keine Zugangsdaten für den Cisco habe ("... bleibt Eigentum der Telekom ..."), um diesen z.B. auf DHCP zu stellen, weiss ich nicht, wie ich das Ding ins LAN einbinden bzw. an einen der Ethernet-Ports des Lancom anschliessen soll.
Nachtrag: Nachdem ich mir das hier nochmal durchgelesen habe: http://www.telekom.de/dlp/agb/pdf/43814.pdf - könhte es sein, dass der Telekom-Cisco einfach nur als Switch agiert? Das wäre nat. eine verblüffnd einfache Lösung ... ?
Leider war ich bei der Installation nicht vor Ort. Der Telekom-Techniker hat kabelseitig eine Art Endgerät dagelassen, was wiederum mit dem WAN-Anschluss eines Routers Cisco 800 verbunden ist, der offensichtlich an seinen 4 Switchports den Kundenzugang bereitstellen soll. Der Anschluss ist inzwischen freigeschaltet. Ein testweise angeschlossenes Notebook erhielt per DHCP aber keine IPV4-Adresse zugewiesen, eine fest eingestellte IP (als Gateway zu verwenden?) ist nicht bekannt. Der Cisco 800 ist doch da als Router, oder?
Auf Nachfrage erhielt ich folgende Info: "... Ihr IPv4 80.x.x.160/29 Adressbereich ist klassisch geroutet. Adressen: Netz - Broadcast 80.x.x.160 - 80.x.x.167, Gateway 80.x.x.161/29 (255.255.255.248)"
Das sind m.E. doch die externen Adressen, oder? Ein Lookup weist den Bereich jedenfalls der Telekom zu. Aber was interessiert mich bei WAN-Adressen ein Gaetway? Und wie kann - falls das Gateway .161 sich auf die LAN-Seite bezieht - diese innerhalb des gleichen Subnetztes liegen, wie die WAN-Seite?
Bin total verwirrt und bitte um hilfreiche Denkanstöße. Danke.
Eine weitere Nachfrage beim Service ergab die wenig hilfreiche Antwort, dass man sich prinzipiell nicht um die internen Adressen der Kunden kümmere - was für sich alleine ja auch sinnvoll ist. Aber da ich auch keine Zugangsdaten für den Cisco habe ("... bleibt Eigentum der Telekom ..."), um diesen z.B. auf DHCP zu stellen, weiss ich nicht, wie ich das Ding ins LAN einbinden bzw. an einen der Ethernet-Ports des Lancom anschliessen soll.
Nachtrag: Nachdem ich mir das hier nochmal durchgelesen habe: http://www.telekom.de/dlp/agb/pdf/43814.pdf - könhte es sein, dass der Telekom-Cisco einfach nur als Switch agiert? Das wäre nat. eine verblüffnd einfache Lösung ... ?
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: 329872
Url: https://administrator.de/contentid/329872
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
19 Kommentare
Neuester Kommentar
Zitat von @qualidat:
Auf Nachfrage erhielt ich folgende Info: "... Ihr IPv4 80.x.x.160/29 Adressbereich ist klassisch geroutet. Adressen: Netz - Broadcast 80.x.x.160 - 80.x.x.167, Gateway 80.x.x.161/29 (255.255.255.248)"
Das sind m.E. doch die externen Adressen, oder?
Auf Nachfrage erhielt ich folgende Info: "... Ihr IPv4 80.x.x.160/29 Adressbereich ist klassisch geroutet. Adressen: Netz - Broadcast 80.x.x.160 - 80.x.x.167, Gateway 80.x.x.161/29 (255.255.255.248)"
Das sind m.E. doch die externen Adressen, oder?
das sind die Adressen, die Dir für extern zur Verfügung stehen.
- Netz ist 80.x.x.160/29
- gateway 80.x.x.161
- Broadcast 80.x.x.167
- Nutzbare IP-Adressen 80.x.x.162-166
Aber was interessiert mich bei WAN-Adressen ein Gaetway?
Und wie solen die Geräte udn Route rwissen, wo sie die Pakete hinschicken sollen, die ins Internet sollen?
Und wie kann - falls das Gateway .161 sich auf die LAN-Seite bezieht - diese innerhalb des gleichen Subnetztes liegen, wie die WAN-Seite?
Nein. LAN UND WAn sind zwei verschiedene Paar Schue.
Also:
- Als erstes sollest Du Dir übe rdie Funktionsweise von IP und routing Wissen anlesen.
- Danach nimmst Du einfach einen Firewall, z.B. die pfsense nach der Anleitung von aqui. zur Not tut es auch ein einfacher Router, der Masquerading (landläufig NAT genannt) kann
- Dem verpaßt Du auf der WAN-Seite die IP-Adresse 80.x.x.162 und trägst die 161 als gateway ein.
- Auf der LAN-Seite nimmst Du ein Netz aus dem RFC1918-bereich, z.B. 10.17.131.0/24
Fertig ist der Lack, wie @aqui zu sagen pflegt.
lks
PS: Die weiteres Andressen kannst Du z.B. per 1:1-NAT auf eine DMZ oder einen Server mappen, wenn Du z.B. den VPN-, Web- oder Mailserver inhouse betreibst.
Danke für die Antwort, hilft mir aber nicht wirklich und ich habe den Eindruck, du hast meine Frage nicht vollständig gelesen.
Natürlich wiess ich , was WAN und LAN ist und ich nahm bisher an, der von der Telekom hingestellte Cisco dient as Router. Für mich ist die Telekomseite WAN und die dort vergeben Adressen interessieren mich eigentlich nur für den Fall, dass ich von Aussen zugreifen will, DAS kommt aber erst später. Und eben die LAN-seitigen Eigenschaften dieses Cisco kenne ich nicht, DHCP macht er nicht, Zugriff auf dessen Config habe ich auch nicht - da kann ich schlecht einfach irgend einen Adressbereich "nehmen".
Ich habe den Cisco nicht mitbestellt, das hat der Kunde alleine gemacht bzw. sich "beraten" lassen.
Deine Aussagen ergäben nat. Sinn, wenn ich auf den Cisco verzichte und das "Endgerät" der Telekom einfach direkt mit dem vorhandenen Lancom verbinde und die oben genannten Einstellungen vornehme.
Das habe ich aber noch nicht probiert ... mache ich Monag früh. Ich nahm an, dass hier jemand schonmal einen Anschluss "DeutschalndLAN" eingerichtet hat und die Situation genauer beschreiben kann.
Natürlich wiess ich , was WAN und LAN ist und ich nahm bisher an, der von der Telekom hingestellte Cisco dient as Router. Für mich ist die Telekomseite WAN und die dort vergeben Adressen interessieren mich eigentlich nur für den Fall, dass ich von Aussen zugreifen will, DAS kommt aber erst später. Und eben die LAN-seitigen Eigenschaften dieses Cisco kenne ich nicht, DHCP macht er nicht, Zugriff auf dessen Config habe ich auch nicht - da kann ich schlecht einfach irgend einen Adressbereich "nehmen".
Ich habe den Cisco nicht mitbestellt, das hat der Kunde alleine gemacht bzw. sich "beraten" lassen.
Deine Aussagen ergäben nat. Sinn, wenn ich auf den Cisco verzichte und das "Endgerät" der Telekom einfach direkt mit dem vorhandenen Lancom verbinde und die oben genannten Einstellungen vornehme.
Das habe ich aber noch nicht probiert ... mache ich Monag früh. Ich nahm an, dass hier jemand schonmal einen Anschluss "DeutschalndLAN" eingerichtet hat und die Situation genauer beschreiben kann.
Moin,
wie lks bereits schrieb, hat dein Kunde nicht nur eine PublicIP von der DTAG erhalten, sondern in diesem Fall 6 nutzbare, wobei eine als Gateway-Adresse bei "drauf geht".
Die IPs werden über/ durch den Cisco bereitgestellt. D.h. die LAN-Seite des obigen Cisco stellt dir das o.g. Netz 80.x.x.160/ 29 bereit.
Die 5 IPs haben den Vorteil, dass du z.B. eine IP für Mails verwenden kannst, eine weitere für z.B. VPN-Zugänge, eine dritte für einen Webserver in einer DMZ, die vierte für normalen WebTraffic der User und mit der fünften.... deine Phantasien...
Da du ja einen LANCOM vor Ort hast, kannst du ein oder mehrere Patchkabel zwischen Cisco und LANCOM stecken und am LANCOM den Port als WAN-Port definieren. Dem Port/ den Ports gibst du dann einfach eine (oder alle) der 5 verfügbaren Adressen (80.x.x.162, 80.x.x.163, 80.x.x.164, 80.x.x.165 oder 80.x.x.166, jeweils mit der 29er Netzmaske) und kannst dann in Abhängigkeit der IP die Pakete entsprechend routen bzw. Firewall-Regeln walten lassen...
Du solltest jedoch noch nach den passenden DNS-Server fragen,wenn du über den neuen Zugang auf DNS-Anfragen laufen lassen möchtest.
Die DNS-Server trägst du dann im LANCOM noch ein.
wie lks bereits schrieb, hat dein Kunde nicht nur eine PublicIP von der DTAG erhalten, sondern in diesem Fall 6 nutzbare, wobei eine als Gateway-Adresse bei "drauf geht".
Die IPs werden über/ durch den Cisco bereitgestellt. D.h. die LAN-Seite des obigen Cisco stellt dir das o.g. Netz 80.x.x.160/ 29 bereit.
Die 5 IPs haben den Vorteil, dass du z.B. eine IP für Mails verwenden kannst, eine weitere für z.B. VPN-Zugänge, eine dritte für einen Webserver in einer DMZ, die vierte für normalen WebTraffic der User und mit der fünften.... deine Phantasien...
Da du ja einen LANCOM vor Ort hast, kannst du ein oder mehrere Patchkabel zwischen Cisco und LANCOM stecken und am LANCOM den Port als WAN-Port definieren. Dem Port/ den Ports gibst du dann einfach eine (oder alle) der 5 verfügbaren Adressen (80.x.x.162, 80.x.x.163, 80.x.x.164, 80.x.x.165 oder 80.x.x.166, jeweils mit der 29er Netzmaske) und kannst dann in Abhängigkeit der IP die Pakete entsprechend routen bzw. Firewall-Regeln walten lassen...
Du solltest jedoch noch nach den passenden DNS-Server fragen,wenn du über den neuen Zugang auf DNS-Anfragen laufen lassen möchtest.
Die DNS-Server trägst du dann im LANCOM noch ein.
Hallo qulidat,
anscheinend hast du es nicht ganz verstanden. Lks hat vollkommen recht. Der Cisco ist da schon richtig auch wenn du ihn nicht mitbestellt hast. Du hast hier nicht mehr eine 0850 VDSL Leitung bei der du dich mit PPPOE einwählst.
Du hängst dein Gerät an den Cisco Router und gibst ihm eine IP wie Lks schon geschrieben hat(80.x.x.160/29 Das ist dein Adressbereich den du zur Auswahl hast sonst keiner) und definierst als Gateway den Cisco Router. Hinter dem Cisco Router ist noch immer WAN und wenn du dort direkt deine Geräte anschließt steht das auch im WAN, ohne Firewall davor -> nicht gut! Du musst also hinter den Cisco noch einen Router oder FW anschließen und an diesem Gerät dann kannst du am LAN Interface DHCP einstellen oder statische IP Adressen vergeben(im Rahmen RFC1918).
Hat dein Lancom noch ne Schnittstelle frei die du an den Cisco Router hängen kannst? Wenn ja Ip adresse x.x.x.162 und x.x.x.161 als gateway.
Gruß
anscheinend hast du es nicht ganz verstanden. Lks hat vollkommen recht. Der Cisco ist da schon richtig auch wenn du ihn nicht mitbestellt hast. Du hast hier nicht mehr eine 0850 VDSL Leitung bei der du dich mit PPPOE einwählst.
Du hängst dein Gerät an den Cisco Router und gibst ihm eine IP wie Lks schon geschrieben hat(80.x.x.160/29 Das ist dein Adressbereich den du zur Auswahl hast sonst keiner) und definierst als Gateway den Cisco Router. Hinter dem Cisco Router ist noch immer WAN und wenn du dort direkt deine Geräte anschließt steht das auch im WAN, ohne Firewall davor -> nicht gut! Du musst also hinter den Cisco noch einen Router oder FW anschließen und an diesem Gerät dann kannst du am LAN Interface DHCP einstellen oder statische IP Adressen vergeben(im Rahmen RFC1918).
Hat dein Lancom noch ne Schnittstelle frei die du an den Cisco Router hängen kannst? Wenn ja Ip adresse x.x.x.162 und x.x.x.161 als gateway.
Gruß
Zitat von @qualidat:
Danke für die Antwort, hilft mir aber nicht wirklich und ich habe den Eindruck, du hast meine Frage nicht vollständig gelesen.
Danke für die Antwort, hilft mir aber nicht wirklich und ich habe den Eindruck, du hast meine Frage nicht vollständig gelesen.
Und ich glaube, Du hast meine Antwort nicht verstanden, obwohl ich genau auf Deine frage geantwortet habe.
Natürlich wiess ich , was WAN und LAN ist und ich nahm bisher an, der von der Telekom hingestellte Cisco dient as Router.
Ja das ist auch ein Router.
Für mich ist die Telekomseite WAN und die dort vergeben Adressen interessieren mich eigentlich nur für den Fall, dass ich von Aussen zugreifen will, DAS kommt aber erst später.
Trotzudem mußt Du Dich mit dem Thema beschäftigen,m auch wenn das später kommt.
Und eben die LAN-seitigen Eigenschaften dieses Cisco kenne ich nicht, DHCP macht er nicht, Zugriff auf dessen Config habe ich auch nicht - da kann ich schlecht einfach irgend einen Adressbereich "nehmen".
Wie ich schon oben schrieb, mußt Du Deinen eigenen Router oder Deine Firewall an die Cisco hängen und eine fixe IP-Adresse aus dem Dir zugeteilten nutzbaren Bereich 162...166 nehmen und das dem WAN-Interface Deines Routers oder Deiner Firewall zuweisen. Stell Dir einfach vor, die Cisco würde bei der Telekom stehen und Du hättest einfach ein Ethernet-Kabel zu Dir gelegt.
Die Cisco macht kein DHCP, weil das sinnfrei in diesem Anwendungsfall wäre. Du mußt also dem WAN-Interface Deines Routers (Die Cisco ist nicht Dein Router!) eine statische IP-Adresse geben. Und im LAN kannst Du Dir irgendein RFC1918-netz nehmen, wie ich Dir schon oben geschrieben habe.
Ich habe den Cisco nicht mitbestellt, das hat der Kunde alleine gemacht bzw. sich "beraten" lassen.
Der Cisco ist per default dabei. Das ist der Provider-Router, an den Du dann Deinen Kundenrouter hängst.
Deine Aussagen ergäben nat. Sinn, wenn ich auf den Cisco verzichte und das "Endgerät" der Telekom einfach direkt mit dem vorhandenen Lancom verbinde und die oben genannten Einstellungen vornehme.
Du kannst nciht auf den Cisco verzichten. Der muß da stehen. Du hängst Deien LAN-COM an die CISCO und gibst dem WAN-Interface z.B. die 80.x.x.162/29 mit gateway 80.x.x.161
Das habe ich aber noch nicht probiert ... mache ich Monag früh. Ich nahm an, dass hier jemand schonmal einen Anschluss "DeutschalndLAN" eingerichtet hat und die Situation genauer beschreiben kann.
Bevor Du hier rumschreist, faß Dich mal an die eigene Nase umd lies die Antworten und versuche sie zu verstehen. Ansonsten hock Dich auf den Hosenboden und büffle IP-Grundlagen.Es ist schon eine Frechheit, dem Antwortgeber das eigene Unverständnis anzulasten.
lks
Zitat von @em-pie:
Du solltest jedoch noch nach den passenden DNS-Server fragen,wenn du über den neuen Zugang auf DNS-Anfragen laufen lassen möchtest.
Du solltest jedoch noch nach den passenden DNS-Server fragen,wenn du über den neuen Zugang auf DNS-Anfragen laufen lassen möchtest.
Inso einem Setup maht man DNS selbst und verläßt sich nciht auf dem Provider. Und den eigenen DNS sollte man also schon kennen.
lks
Jo, internes DNS sowieso "Zuhause", aber welchen DNS-Server setzt er dann für Anfragen an z.B. google.de ein!?
Den 8.8.8.8 vermutlich nicht
Den 8.8.8.8 vermutlich nicht
Ich wollte niemanden beleidigen. Trotzdem empfand ich die erste Antwort arrogant klingend und wenig verständlich. Da haben spätere Poster mehr zur Lösung beigetragen.
Mein Verständnisproblem war darin begründet, dass, wenn der Cisco bei mir steht, wieso ich mich dann auf dessen LAN-Seite im gleichen Subnetz mit meinen öffentlichen Adressen befinde.
Aber eingedenk der Tatsache, dass es ja im Telekom-Netz wiederum Router gibt, die diese Adressen kennen ... naja ... da schliest sich dann der Kreis. Die IP-Adressen auf der WAN-Seite des Cisco sind vermutlich völlig andere, aber nur Telekom-intern von Bedeutung - ist doch richtig so, oder?
Mein Verständnisproblem war darin begründet, dass, wenn der Cisco bei mir steht, wieso ich mich dann auf dessen LAN-Seite im gleichen Subnetz mit meinen öffentlichen Adressen befinde.
Aber eingedenk der Tatsache, dass es ja im Telekom-Netz wiederum Router gibt, die diese Adressen kennen ... naja ... da schliest sich dann der Kreis. Die IP-Adressen auf der WAN-Seite des Cisco sind vermutlich völlig andere, aber nur Telekom-intern von Bedeutung - ist doch richtig so, oder?
Für DNS nehme ich immer Open DNS, 208.67.220.220 und ...222.222.
Hi,
dieser Link hilft dir weiter:
https://www2.lancom.de/kb.nsf/1275/B4C07D62B250243DC125763B002DDFF8?Open ...
Bei den DHCP bzw. IP-Einstellungen gibst du die Daten ein, die dir von der Telekom vorliegen.
LG puerto
dieser Link hilft dir weiter:
https://www2.lancom.de/kb.nsf/1275/B4C07D62B250243DC125763B002DDFF8?Open ...
Bei den DHCP bzw. IP-Einstellungen gibst du die Daten ein, die dir von der Telekom vorliegen.
LG puerto
Zitat von @em-pie:
Jo, internes DNS sowieso "Zuhause", aber welchen DNS-Server setzt er dann für Anfragen an z.B. google.de ein!?
Den 8.8.8.8 vermutlich nicht
Jo, internes DNS sowieso "Zuhause", aber welchen DNS-Server setzt er dann für Anfragen an z.B. google.de ein!?
Den 8.8.8.8 vermutlich nicht
Den eigenen natürlich. Man braucht weder google noch providerserver für dns. İst bei mir Standard.
lks
Auch wenn das hier gerade etwas OT wird:
Aber woher wissen deine eigenen DNS-Server, unter welcher IP z.B. google.de, microsoft.de, administrator.de, etc. zu erreichen sind?
Ich persönlich pflege eigentlich nicht manuell alle möglichen DNS-Einträge, die im WWW so verfügbar sind, auf meinem DNS-Server...
Das wäre ja so, als wenn du die Rufnummer der Spedition Müller in Timbuktu suchst und nur in deinem (handgeschriebenen) Telefonbuch schaust, welches unter dem Telefon am Tischchen im Flur steht (ja, etwas Oldschool, aber so war das ja von 30 Jahren noch, ohne Internet, etc.)
Ich würde dann doch das Telefonbuch/ die Gelben Seiten nehmen, welches mir mein Provider (DasÖrtliche oder früher noch von der Post) gegeben hat.
Ooooder, du betreibst einen eigenen öffentlichen DNS-Server, aber auch der muss ja irgendwie die Einträge in anderen Servern finden....
Aber woher wissen deine eigenen DNS-Server, unter welcher IP z.B. google.de, microsoft.de, administrator.de, etc. zu erreichen sind?
Ich persönlich pflege eigentlich nicht manuell alle möglichen DNS-Einträge, die im WWW so verfügbar sind, auf meinem DNS-Server...
Das wäre ja so, als wenn du die Rufnummer der Spedition Müller in Timbuktu suchst und nur in deinem (handgeschriebenen) Telefonbuch schaust, welches unter dem Telefon am Tischchen im Flur steht (ja, etwas Oldschool, aber so war das ja von 30 Jahren noch, ohne Internet, etc.)
Ich würde dann doch das Telefonbuch/ die Gelben Seiten nehmen, welches mir mein Provider (DasÖrtliche oder früher noch von der Post) gegeben hat.
Ooooder, du betreibst einen eigenen öffentlichen DNS-Server, aber auch der muss ja irgendwie die Einträge in anderen Servern finden....
Zitat von @em-pie:
Aber woher wissen deine eigenen DNS-Server, unter welcher IP z.B. google.de, microsoft.de, administrator.de, etc. zu erreichen sind?
Ich persönlich pflege eigentlich nicht manuell alle möglichen DNS-Einträge, die im WWW so verfügbar sind, auf meinem DNS-Server...
Aber woher wissen deine eigenen DNS-Server, unter welcher IP z.B. google.de, microsoft.de, administrator.de, etc. zu erreichen sind?
Ich persönlich pflege eigentlich nicht manuell alle möglichen DNS-Einträge, die im WWW so verfügbar sind, auf meinem DNS-Server...
Das macht ein rekursiv arbeitender DNS-Resolver. Der arbeitet so:
DNS arbeitet hierarchisch. Jeder Punkt trennt (von rechts nach links gelesen) die einzelnen DNS-Zonen, von denen aus du dich immer weiter herunterhangelst. Etwas anderes machen die Provider-DNS oder der Google-DNS auch nicht.
Dein Resolver fängt ganz oben bei den Root-Nameservern an und fragt diese nach "www.administrator.de".
Die IP-Adressen der Root-Nameserver sind statisch in den sogenannten "Root-Hints" als Datei hinterlegt. Diese IP-Adressen ändern sich quasi nie
Jedenfalls hat dein Resolver jetzt gefragt, der Root-Nameserver weiß aber nur, dass man für ".de" die Nameserver der DENIC fragen muss und liefert deren IP-Adressen gleich mit.
Dein Resolver trampelt jetzt also zu den DENIC-Nameservern und fragt nach "www.administrator.de". Die DENIC weiß das auch nicht, kann aber die IP-Adressen der Nameserver für "administrator.de" nennen.
So latscht dein Resolver nun also zu den Nameservern für "administrator.de" und fragt dort wieder nach. Diesmal hat er aber endlich den zuständigen ("authoritativen") Nameserver erwischt, der ihm alles beantworten kann, was dein Resolver wissen will.
Dein Resolver legt diese ganzen Informationen die er gesammelt hat dann in seinen Cache, damit er beim nächsten Mal nicht wieder die ganze Kette durcharbeiten muss.
Das können wir gerne mit Beispielen vertiefen, dafür solltest du dann aber einen eigenen Thread aufmachen
Danke für die Erläuterung, welche mir erfreulicherweise seit meiner Ausbildung vor 10 Jahren bereits bekannt ist 
Ich belasse es jetzt hier einfach mal dabei, um den Thread zu schonen.
Ich werde einfach weiterhin in meinen Firewalls einen mir bekannten öffentlich-zugänglichen DNS-Server eintragen (bzw. über den DHCP-Server des Providers eintragen lassen) und verweise meine eigenen DNS-Server auf die Firewall, damit ich weiterhin auf administrator.de aktiv sein kann, ohne die IP kennen zu müssen
Hat seit jeher tadellos funktioniert und wird vermutlich auch noch einige Jahre weiter so funktionieren
Von daher wieder Back2Topic.
Denke, dem TO müsste zwischenzeitig geholfen worden sein, nicht zuletzt durch puertos Link
Ich belasse es jetzt hier einfach mal dabei, um den Thread zu schonen.
Ich werde einfach weiterhin in meinen Firewalls einen mir bekannten öffentlich-zugänglichen DNS-Server eintragen (bzw. über den DHCP-Server des Providers eintragen lassen) und verweise meine eigenen DNS-Server auf die Firewall, damit ich weiterhin auf administrator.de aktiv sein kann, ohne die IP kennen zu müssen
Hat seit jeher tadellos funktioniert und wird vermutlich auch noch einige Jahre weiter so funktionieren
Von daher wieder Back2Topic.
Denke, dem TO müsste zwischenzeitig geholfen worden sein, nicht zuletzt durch puertos Link
Zitat von @em-pie:
Auch wenn das hier gerade etwas OT wird:
Aber woher wissen deine eigenen DNS-Server, unter welcher IP z.B. google.de, microsoft.de, administrator.de, etc. zu erreichen sind?
Auch wenn das hier gerade etwas OT wird:
Aber woher wissen deine eigenen DNS-Server, unter welcher IP z.B. google.de, microsoft.de, administrator.de, etc. zu erreichen sind?
Ganz einfach:
Die fragen deren Server.
Offensichtlich besteht da noch Lernbedarf bei Dir. Listze mal die DNS-protokolle nach.
Ein DNS-Server, der kein forwarder ist, schat sie den angefragten namen an. Er fragt die root-server nach der TLD und weiß damit, welchen namesever er nach der second-level-domain fragen muß. Und diesen fragt er dann nach dem host/domain-namen, der aufgelöst werden soll.
Und das Ergebnis gibt er dann dem anfragenden Client zurück.
Man muß also keine forwarder nutzen, um an eine host-ip von google & co. zu kommen.
Wie gesagt. einfach mit den Protokollen beschäftigen, dann weiß man auch, wie das funktioniert.
Das DNS-Protokoll wurde dafür geschaffen, daß ein Server das herausfindet.
Ich persönlich pflege eigentlich nicht manuell alle möglichen DNS-Einträge, die im WWW so verfügbar sind, auf meinem DNS-Server...
Genau deswegen gibt es ja DNS, damit man das nicht manuell machen muß.
lks
Zitat von @em-pie:
Ich werde einfach weiterhin in meinen Firewalls einen mir bekannten öffentlich-zugänglichen DNS-Server eintragen (bzw. über den DHCP-Server des Providers eintragen lassen) und verweise meine eigenen DNS-Server auf die Firewall, damit ich weiterhin auf administrator.de aktiv sein kann, ohne die IP kennen zu müssen
Ich werde einfach weiterhin in meinen Firewalls einen mir bekannten öffentlich-zugänglichen DNS-Server eintragen (bzw. über den DHCP-Server des Providers eintragen lassen) und verweise meine eigenen DNS-Server auf die Firewall, damit ich weiterhin auf administrator.de aktiv sein kann, ohne die IP kennen zu müssen
ich glaube, Du hast imemr noch nicht verstanden, daß es unerheblich ist, ob Du die IP-Adresse von Administrtaor.de kennst oder nciht. Wenn Du einen Eigenen Nameserver hast, sorgt der dafür, daß Deine Clients und auch Deine Firewall das automatisch erfahren.
Hat seit jeher tadellos funktioniert und wird vermutlich auch noch einige Jahre weiter so funktionieren
Außer der Provider-Nameserver spinnt und Du kommst nicht auf Administrator.de weil Du nicht weißt, wie man an die Information kommt.
lks
Zitat von @em-pie:
Danke für die Erläuterung, welche mir erfreulicherweise seit meiner Ausbildung vor 10 Jahren bereits bekannt ist
Danke für die Erläuterung, welche mir erfreulicherweise seit meiner Ausbildung vor 10 Jahren bereits bekannt ist
Nimm es mir bitte nicht übel, jedoch: Basierend auf deiner Fragestellung gibt es da dennoch offenbar eine Verständnislücke wie DNS-Rekursion funktioniert. Deiner Logik nach müsste ja jeder DNS-Record jeder Domain weltweit auf den Google-DNS-Servern angelegt und verwaltet werden... o_O
Ach, übel nehme ich keinem etwas, denn
A) bin ich kein Gott und somit nicht allwissend und
B) lerne ich gerne dazu
Ich breche hier aber mal ab, da ich vermute, dass wir einander vorbei reden
lks habe ich vorhin ne PN gesendet, da ich diese Thematik nicht als derart wichtig erachte, dafür einen eigenen Thread zu eröffnen, es mir aber keine Ruhe lässt
So,
Und ab hier dann gerne wieder B2T
Sorry, lieber TO, für den Exkurs, ist nicht meine Absicht gewesen
A) bin ich kein Gott und somit nicht allwissend und
B) lerne ich gerne dazu
Ich breche hier aber mal ab, da ich vermute, dass wir einander vorbei reden
lks habe ich vorhin ne PN gesendet, da ich diese Thematik nicht als derart wichtig erachte, dafür einen eigenen Thread zu eröffnen, es mir aber keine Ruhe lässt
So,
Und ab hier dann gerne wieder B2T
Sorry, lieber TO, für den Exkurs, ist nicht meine Absicht gewesen
Moin @all,
Ich werde die Kommentare heute Abend, welche nichts zum Thema beitragen ausblenden.
Gruß,
Dani
Auch wenn das hier gerade etwas OT wird:
etwas ist gut...bitte ab sofort beim Thema bleiben.Ich werde die Kommentare heute Abend, welche nichts zum Thema beitragen ausblenden.
Gruß,
Dani
