Nicht existente Weburls werden auf nic.de.hn umgeleitet

[mcdaniels 22]

Hi!

Verhalten tritt bei jedem Client auf.

 

 

Windows-IP-Konfiguration

 

Hostname. . . . . . . . . . . . . : meinpc

Primäres DNS-Suffix . . . . . . . : domäne.intern.at

Knotentyp . . . . . . . . . . . . : Unbekannt

IP-Routing aktiviert. . . . . . . : Nein

WINS-Proxy aktiviert. . . . . . . : Nein

DNS-Suffixsuchliste . . . . . . . : domäne.intern.at

intern.at

 

Ethernetadapter LAN-Verbindung:

 

Verbindungsspezifisches DNS-Suffix:

Beschreibung. . . . . . . . . . . : Intel® PRO/1000 MTW Network Connec

tion

Physikalische Adresse . . . . . . : xx-xx-xx-xx-80-77

DHCP aktiviert. . . . . . . . . . : Nein

IP-Adresse. . . . . . . . . . . . : 192.168.0.50

Subnetzmaske. . . . . . . . . . . : 255.255.255.0

Standardgateway . . . . . . . . . : 192.168.0.1

DNS-Server. . . . . . . . . . . . : 192.168.0.200

192.168.0.201

 

Hab grade mal Wireshark laufen lassen. Wenn ich ein nslookup vom client aus mache mit einem FQDN meiner Lokalen Domäne, dann läuft das lt. Wireshark so:

 

nslookup

abfrage nach meinpc.domäne.intern.at

 

Paketsnifferausgabe:

1. Source: Mein PC -> Destination: Interner DNS Server -> Protokoll DNS .-> Standard Query A meinpc.domäne.intern.at.domäne.intern.at

2. Kommt dann vom Server retour "standard query response" no such name

3. Source: Mein PC -> Destination: Interner DNS Server -> Protokoll DNS -> Standard Query A meinpc.domäne.intern.at.intern.at

4. Kommt dann vom Server retour "standard query response" 82.198.85.17

 

Wenn ich per nslookup nur nach "meinpc" abfrage (also ohne den "Domänenanhang" funktionierts)

 

Wenn ich per nslookup einen externe Host auflösen will, dann schaut das so aus: (zb http://www.google.at).

 

Mein PC schickt anscheinend bei dieser Anfrage auch wieder http://www.google.at.domäne.intern.at an den internen DNS.

Der antwortet wieder mit no such name (weil es das ja nicht gibt eh klar).

Danach versucht er eine weitere Anfrage mit http://www.google.at.intern.at und bekommt dann wieder die IP 82.198.85.17 retour. Das ist dann halt die IP die offiziell von irgendjemanden auf intern.at registriert wurde.

 

Ich hab also anscheinend doch nen Knoten in meiner DNS Konfig? Soweit ich das verstanden habe darf der Client nicht überall domäne.intern.at anhängen.

 

Hab jetzt grad mal das hier gelesen: DNS Server hängt lokale domain-Bezeichnung beim extern weiterleiten an - administrator

 

Könnte das nicht bei mir auch der Fall sein... D.h. im schlimmsten Fall müsst ich die ganze Domäne umbenennen?

 

LG und vielen Dank!!!

[IThome 10]

Entferne auf einem Client testweise mal den Haken "Übergeordnete Suffixe des primären Suffixes anhängen" oder definiere eine benutzerdefinierte Suchliste unter "Diese Suffixe anhängen" , in der nur die interne Domäne steht ...

[mcdaniels 22]

Hey!

Hab beides versucht. Also in den Eigenschaften der LAN Verbindung Reiter DNS und dann die von dir erwähnten Änderungen vorgenommen.

 

Leider absolut keine Änderung.

 

Ist das normal, dass mein Client auf derlei Änderungen nicht reagiert? Vor allem kommt es mir auch komisch vor, dass das Internet überhaupt noch funktioniert.

 

Denn wie gesagt: Aus Google wird http://www.google.at.intern.at -> Die Ip die aufgelöst wird ist also eigentlich die falsche, trotzdem komm ich immernoch auf alle Homepages...?!?!

 

Meiner Meinung nach sollte doch immer dieselbe Seite im Browser erscheinen. Tut es aber (gott sei dank) (noch?) nicht.

 

Verstehe das ganze überhaupt nicht ... Vielleicht ists doch deshalb, weil ich auf meiner internen Domäne eben nicht intern.local sondern intern.at eingerichtet hab?

 

Siehst du / sehrt ihr das anders?

[IThome 10]

Was passiert denn, wenn Du IPCONFIG /FLUSHDNS ausführst und dann PING Google eingibst. Was sagt der Sniffer dann ?

[mcdaniels 22]

Hey!

Vorwerg nochmal Danke für deine Hilfe!

 

Der Sniffer sagt source -> mein pc -> destination mein interner dns server -> protokoll dns -> Standard query A Google

 

dann löst er den Echorequest korrekt auf d.h.

 

Source wieder mein Pc -> destination Google bzw. die korrekte ip v. Google

 

Scheint also zu funktionieren.

 

Je mehr ich mach, desto weniger kenn ich mich aus....

 

Ping in Verbindung mit Namensauflösung funktioniert Google -> 209.85.135.99

Nslookup: Google erzeugt ne nicht author. Antwort http://www.google.at.bruck.at -> 82.198.85.17

[IThome 10]

So langsam glaube ich, dass das eine NSLOOKUP Eigenart ist, die Namensauflösung erfolgt doch korrekt ...

[mcdaniels 22]

Hm.

Ja die Namensauflösung erfolgt korrekt - anscheinend zumindest fürs web und für existierende PC in meinem LAN. Nslookup allerdings nicht.

Mir ist das ganze zuallererst aufgefallen, als ich per nslookup gucken wollte, welche IP ein PC hat und mich beim Pc namen verschrieben habe. Da kam dann nämlich die IP des Webserver retour, der im Internet für http://www.intern.at zuständig ist. (da die NSLOOKUP Abfrage ja wie gesagt bei allen FQDN , die es bei mir lokal im DNS nicht gibt das intern.at angehängt hatte.)

 

Was noch dazuzusagen ist: Wenn bei den Tcp ip Einstellungen Übergeordnete Suffixe des primären DNS-Suffixes anhängen aktiv ist (was ja bei allen Clients so ist) dann gelange ich auch bei Eingabe einer nicht existenten Url zb: http://www.blubbbbbbb.de auf die Seite die mir Nslookup auflöst.

 

 

Jedenfalls war das soweit ich es nachvollziehen konnte früher nicht so (zumindest nicht bevor die domain offiziell registriert wurde von jemanden. )

 

Weißt du zufällig warum der Server immer zuerst versucht mittels meinpc.meinedomäne.intern.at abzufragen und dann - wenn er nichts findet - die Abfrage nochmals mit meinpc.intern.at versucht?

 

Ich würd fast wetten, dass, wenn meine Domäne "meinedomäne.local" heißen würde und eben nicht so doof (weil eben alles nur im Lan abläuft) benannt wäre, keine Probleme derart bestehen würden...

[mcdaniels 22]

Hallo

Update: Hab mich jetzt noch ne Zeit lang mit den internen DNS Einstellungen "gespielt" und nun folgendes umgestellt:

 

Bei der TCP IP Verbindung des Client -> Reiter DNS -> Diese DNS Suffixe anhängen ausgewählt und dann als DNS Suffix meinedomäne.intern.at. angegeben mit abschließendem Punkt

 

Weiters ist nach wie vor standardmässig aktiv "Adressen dieser Verbindung in DNS registrieren."

 

Nslookup hängt das intern.at bei externen domänen bzw nicht existierenden internen FQDN nicht mehr an (sondern "nur" noch meinedomäne.intern.at.)

 

Folglich macht ein nslookup auf Google -> http://www.google.at.meinedomäne.intern.at. -> no such name -> dann wird ein weiterer lookup versucht auf die richtige Url und richtig aufgelöst.

 

Das alles kann wenn - dann überhaupt - nur als dirty workaround eingestuft werden.

 

Jedenfalls kann ich das, was unter dem Foreneintrag (bei Administrator.de) gestanden ist nur bestätigen:

 

Niemals einer interne Domäne , irgendwelche offiziell möglichen Namen (.at, .de etc) geben! Immer .local!

 

Weiß nicht wie alle andren das sehen.

 

Wie unterscheidet ein DNS Server eigentlich, wann er den internen Domänennamen anhängen soll und wann nicht? Bei Google darf er das zb nicht bei ner intern vorhandenen IP / FQDN schon...

[IThome 10]

Der Server hängt eigentlich gar nix dran, das macht der Client, nach den Regeln zur Auflösung unvollständiger Namen (hast Du beim Sniffen doch schon gesehen) ...

[mcdaniels 22]

Hoi!

Stimmt - sorry ... macht der Client.

 

Welche Regeln sprichst du da an -> TCP IP Eigenschaften -> DNS -> Suffixe?

 

Ist grundsätzlich die Vorgangsweise des DNS eigentlich korrekt. Ich mein damit: 1. Anfrage der Adresse intern (inkl. meinedomäne.intern.at) , danach weitere Anfrage nach extern (ohne meinedomäne.intern.at)?

 

Hab meine Einstellungen gestern mit den Einistallungen eines Bekannten verglichen. Zumindest die Häkchen bei den Suffixen sind exakt gleich gesetzt. Nur, dass mein Bekannter eben seine Domäne : domäne.local gennannt hat. Das Verhalten tritt bei ihm nicht auf.

 

Meinst du, kann die ganze Problematik mit meinem Domänennamen , den es ja extern nun auch gibt, zusammenhängen?

 

LG

[IThome 10]

Er hängt die Suffixe eigentlich erst dann an, wenn ein unvollständiger Name aufgelöst werden soll, wenn Du beispielsweise nur \\SERVER eingibst und nicht \\SERVER.DOMAIN.DE. Per Default wird dann der primäre DNS-Suffix bzw. der verbindungsspezifische Suffix (z.B. über DHCP verteilt) an den unvollständigen Namen gehängt und diese Anfrage zum Server geschickt. Ist diese Anfrage erfolglos, wird der übergeordnete Suffix des primären Suffixes angehängt. Wird ein FQDN angegeben, wird eigentlich nichts angehängt (wozu auch, der Name ist ja nicht unvollständig). Der DNS-Server des 2003-Servers bekommt nun so eine Anfrage nach einem jetzt vollständigen Namen und weiss, welcher Host welcher Domäne aufgelöst werden soll. Ist er authoritativ für den Domänennamen, der abgefragt wird, schaut er in seiner Zonendatei nach. Wenn nicht, leitet er es weiter (unterschiedlich, je nach Konfiguration). Kann er es nicht finden, wie auch immer, bekommt der Client eine negative ANtwort und für den Server ist die Sache erledigt.

Ich stelle das mal nach, was sehen, was passiert ...

edit: Normalerweise benutzt man intern keinen öffentlichen Adressbereich, der einem nicht selbst gehört. Wenn einem ein externer Bereich gehört, kann man z.B. intern eine Unterdomäne des externen Bereiches erstellen und mit Weiterleitungen und Delegierungen arbeiten ...

[mcdaniels 22]

So!

Dank der Hilfe eines DNS Guru des Mcseboard :) konnten wir nun das Problem "umschiffen" indem wir bei den TCP / IP Eigenschaften (der NIC am Client) -> Erweitert -> DNS -> Im Feld "Diese DNS Suffixe anhängen [in Reihenfolge]" den Namen meiner Internen Domäne eingetragen haben.

 

Danach in ner cmd --> ipconfig /flushdns und am DNS Server den DNS Dienst neu starten bzw. DNS Cache leeren.

 

Die Auflösung funktioniert nun wieder so, wie es sein soll.

[IThome 10]

Hehe, Guru :D Ich weiss nicht, warum sich das Clientsystem bei Einstellung des Standards ohne den Haken "übergeordnete Suffixe des primären DNS-Suffixes anhängen" anders verhält, als wenn man das primäre Suffix in die benutzerdefinierte Suchliste schreibt. Warum hängt er das übergeordnete Suffix nach Fehlschlagen der Auflösung (wenn man einen nicht existenten FQDN angibt) an den FQDN und warum funktioniert die Auflösung, wenn an den FQDN ein Punkt angehängt wird. Beides verhält sich "normal", wenn eine benutzerdefinierte Suffuxsuchliste erzeugt wird, falsche Adressen werden nicht aufgelöst, existente URLs werden aufgelöst, ohne einen Punkt hinten anzustellen. Naja, nochmal den Sniffer anstellen, vielleicht ist ja noch was zu finden ...

[IThome 10]

Nach endloser Snifferei und Rumprobierei hier die (hoffentlich richtige) Lösung für das genannte Verhalten:

Die Domäne XYZ.AT ist eine offizielle Domäne im Internet, intern wurde eine Zone ABC.XYZ.AT erstellt, obwohl die externe Domäne nichts mit der Firma zu tun hat. In den Clienteigenschaften ist für das Auflösen unvollständiger Namen der Haken "Primäre und verbindungsspezifische DNS-Suffixe anhängen" und "Übergeordnete Suffixe des primären DNS-Suffix anhängen" ausgewählt. Der Client hat kein Verbindungssuffix, nur den primären Suffix ABC.XYZ.AT.

Wenn ein Name wie -WWW.GOOGLE.DE- im Browser eingegeben wird, prüft der Resolver, ob es sich um einen FQDN handelt. In diesem Fall handelt es sich nicht um einen FQDN, da kein abschliessender Punkt vorhanden ist. Es handelt sich also um einen Multiple-Label Unqualified Domain Name. Der Resolver hängt an diesen Namen den Punkt an und macht ihn so zu einem FQDN. Diese ANfrage wird an den lokalen DNS-Server geschickt, der die Anfrage weiterleitet und von einem DNS-Server im Internet eine richtige Antwort bekommt.

So weit, so gut ... Was aber passiert, wenn man im Browser einen falschen Namen wie -www.irgendwas.at- angibt ? Der Resolver prüft wieder den Namen, stellt fest, dass es ein Multiple-Label Unqualified Domain Name ist und hängt einen Punkt an, um ihn zum FQDN zu machen. Diese ANfrage wird zum DNS-Server geschickt, der ist nicht zuständig und leitet es weiter, bekommt vom externen DNS-Server eine negative Antwort und leitet sie zum Client. Da das Anfügen eines Punktes nicht zum Erfolg geführt hat, behandelt der Resolver den Multiple-Label Unqualified Domain Name wie einen SIngle-Label Unqualified Domain Name, also einen Namen, der gar keinen Punkt enthält. In diesem Falle wirken die Einstellungen der Auflösung unvollständiger Namen. Da die Clients wie oben beschrieben eingestellt waren, hängt der Resolver den primären DNS-Suffix an und schickt dann die Abfrage -WWW.IRGENDWAS.DE.ABC.XYZ.AT- zu seinem lokalen DNS-Server. Dieser ist für die Zone ABC.XYZ.AT zuständig, kennt aber die Domäne DE nicht und liefert eine negative Antwort zurück. Nach Fehlschlagen dieser Anfrage führt der Client Devolution aus, er hängt also den übergeordneten Suffix des primären Suffixes an, danach wieder den übergeordneten usw. , bis entweder aufgelöst wurde oder 2 Labels überbleiben (also XYZ.AT in diesem Fall). Die Anfrage lautet also -WWW.IRGENDWAS.DE.XYZ.AT- und wird zum lokalen DNS-Server geschickt. DIeser ist nicht zuständig und schickt sie zum DNS-Server im Internet. Jetzt kommt der DNS-Server von XYZ.AT ins Spiel, der die Unterdomäne DE nicht kennt und eine Adresse einer Seite zurückliefert (die "falsche" Seite, die der interne Client angezeigt bekommt, wenn er sich vertippt hat).

Wird am Client jetzt entweder der Haken "Übergeordnete Suffixe des primären DNS-Suffix anhängen" entfernt oder es wird eine benutzerdefinierte Suchliste mit dem Namen des primären DNS-Suffixes erstellt, wird der übergeordnete DNS-Suffix nicht mehr angehängt, die Anfrage landet also nicht mehr beim DNS-Server von XYZ.AT im Internet und wird negativ beantwortet. Ebenso, wenn an die falsche Anfrage ein Punkt angehängt wird, es also ein FQDN ist, an den kein Suffix mehr angehängt wird.

Entweder ist das jetzt korrekt so oder es ist absolut daneben recherchiert, daher möchte ich Euch bitten, es zu berichtigen, falls es fehlerhaft sein sollte , Danke :)