Fehler in der DNS auflösung

[PathFinder 10]

Hallo zusammen !

 

Ich hab hier ein sehr seltsames Problem bei einem Kunden.

 

Irgendwie ist der Wurm in der DNS Auflösung.

 

Also auf normalen Wege funktioniert es wie es soll "ping www.google.de" IP Adresse kommt zurück.

 

gebe ich aber nun nslookup http://www.google.de ein bekomme ich zwar die korrekte IP geliefert, jedoch der name wird mir wie folgt angezeigt: "www.google.de.firma.de"

 

Was kann das denn nur sein ?

 

Bedenklich ist vielleicht das die offizielle Webseite der Firma: "www.firma.de" lautet und die interne Domäne heißt: "intern.firma.de"

 

Kann dass die Schwierigkeiten verursachen, wie kann man einen solchen Fehler beheben ??

 

Für eine Antwort wäre ich sehr dankbar.

 

Mfg der Path

[Hirgelzwift 10]

passiert das nur mit google oder mit allen dns abfragen?

[Daim 12]

Führe mal "nslookup www.google.de." (<-- auf den Punkt am ende achten) aus

[PathFinder 10]

Es passierte Ausnahmlos mit allen extern aufzulösenden DNS Namen. Google ist jetzt einfach nur das Testopfer.

 

Ich bin schon ein wenig weiter aber immer noch etwas verwundert.

 

Nochmal Kurz die Fakten

 

Domänen:

1. externe Domäne namens http://www.meinefirma.de

2. interne Domäne namens intern.meinefirma.de

 

DNS Server:

1. interner DNS Server (mit allem getestet was man da so machen kann, alles prima, interne auflösung wunderbar, ereigniss anzeige Sauber, netdiag alles passed etc.)

2. Externer DNS Server Nr.1 (194.25.0.68) Telekom

3. Externer DNS Server Nr.2 (194.25.0.60) Telekom

 

Und nu kommts

 

versuche ich den nslookup wie beschrieben löst er ja zuerst über den internen DNS auf, der kennt Google natürlich nicht und schickt an den ersten externen weiter (die 68) und ich bekomme besagten fehler

http://www.google.de'>http://www.google.de.meinefirma.de'>http://www.google.de.meinefirma.de ...

nicht! http://www.google.de.intern.meinefirma.de

 

gebe ich aber nun nslookup http://www.google.de 194.25.0.60 ein (also über den zweiten) ist das Problem weg ?!

 

ändere ich die Weiterleitung im internen DNS von 68 auf 60 ist das Problem bei jedem Client weg.

 

Ändere ich den DNS Server wieder zurück auf die 68 ist das Problem wieder da ?!

 

Ich habe nur eine Sache gemacht die mir seltsam vorkam, der Kunde verwaltet seine Domänen selber, diese liegen bei einem externen Rechenzenter, wo die Hosting Server stehen. Es gibt eine Webschnittstelle vom Anbieter unter der man die Domänen konfigurieren kann und dort waren 2 einträge die mich stutzig gemacht haben.

 

.meinefirma.de = xxx.xxx.xxx.xxx (standart IP des Webservers)

*.meinefirma.de = xxx.xxx.xxx.xxx (standart IP des Webservers)

 

sollte ja bedeuten das alles was nicht unter xxx.meinefirma.de aufgelöst werden kann an die standart IP geleitet wird und genau die stand immer im NSLookup

 

nslookup http://www.google.de

Server: internerserver.intern.meinefirma.de

Adresse: xxx.xxx.xxx.xxx

 

Nicht autorisierte Antwort:

Name: http://www.google.de.meinefirma.de

Adresse: xxx.xxx.xxx.xxx (Standart IP des Webservers wie weiter oben beschrieben)

 

Das Problem tritt aber nur mit den Clients der Domäne intern.meinefirma.de auf

 

Der Server hat keine Probleme

 

Fakt ist nun folgendes

 

Trage ich den 60er DNS als Weiterleitung ein ist alles ok (Cache aufem Server löschen, /flushdns am Client)

 

Trage ich den 68er DNS wieder ein, fängt der ganze ****sinn von vorne an.

 

Also entweder der 68er DNS hat noch infos von der eben angesprochenen Domänenkonfiguration, dieses .meinefirma.de = IP, *.meinefirma.de = IP und der 60er nicht, oder ich weiß es auch ned ^^

 

Fakt ist das es mit dem 60er geht (oder usnerem Firmen DNS, oder dem von NetCologne oder halt dem zweiten der TKom) und mit dem 68er dieser seltsame Fehler auftritt.

 

*haarerauf*

 

Wäre für jede Hilfe dankbar, ich ruf jetzt mal bei der TKom an und frag die mal was das soll/sein könnt.

 

Danke fürs Lesen wer es bis hierher geschaft hat =))

 

mfg der Path

[PathFinder 10]

@Daim

 

Ist ja interessant ...

 

hab nomma zurük gestellt nach deinem Vorschlag:

 

Weiterleitung über die 194.25.0.68 (der der nicht bei mir geht)

 

DNS Cache gelöscht, /flushdns am Client

 

nslookup http://www.google.de'>http://www.google.de'>http://www.google.de = selber fehler

 

nslookup http://www.google.de.'>http://www.google.de.'>http://www.google.de. = kein fehler ?

 

das selbe am Client:

nslookup http://www.google.de 194.25.0.68 = Fehler

nslookup http://www.google.de 194.25.0.60 = OK

 

nslookup http://www.google.de. 194.25.0.68 = OK

nslookup http://www.google.de. 194.25.0.60 = OK

 

 

 

mfg der Path

[PathFinder 10]

Ich werd irre =)

 

hab das ganze jetzt nochmal an 6 verschiedenen Clients getestet.

 

1. /flushdns

2. nslookup http://www.google.de'>http://www.google.de (ist jetzt ok weil weiterleitung über den 60er NS)

3. nslookup http://www.google.de 194.25.0.68 = FEHLER

4. nslookup http://www.google.de. 194.25.0.68 = OK

 

nur beim Chef am Client, da geht es egal in welcher konstellation.

 

GhostBusters rufen ?! ;P

 

mfg der Path

[Daim 12]

Ein FQDN besteht mit dem PUNKT am ende der Adresse, denn damit hängt der DNS-Resolver (also der Client) den DNS-Suffix nicht an, den er Standardmäßig mit gibt.

[PathFinder 10]

und was genau müsste ich da nun gegen machen ?

 

und warum liefert mir der 60iger NS keinen Fehler ?

[Hirgelzwift 10]

schau mal in den DNS einstellung des clients ob da was drin steht in bezug auf "diese suffixe anhängen..."

 

ich glaube ghostbuster ist keine gute idee :suspect:

 

außerdem solltest du intern auch nur interne DNS server verwenden.

[PathFinder 10]

Primäre und Verbindungsspezifische DNS Sufixe anhängen, Standarteinstellung.

 

Sonst ist dort nichts weiter eingetragen

 

Und der interne DNS wird normalerweise auch verwendet, das war ja alles nur zu Testzwecken.

[Hirgelzwift 10]

ich bin mir nicht ganz sicher aber ich habe hier immer wieder mal gelesen das es einen root eintrag (. zone) in den dns servern geben kann der so wie ich das verstanden habe gelöscht werden müsste. ich habe das noch nicht gesehen, ist wohl nur bei W2K3 DNS so. kannst du mal im DNS nachschaun od du einen . eintrag hast und das hier evtl. mitteilen bevor du aktionen durchführst. dann weis ich schon wen man fragen muss ;)

 

guckst du hier:

 

http://www.mcseboard.de/showthread.php?t=53347

[Daim 12]

Moin,

 

ich bin mir nicht ganz sicher aber ich habe hier immer wieder mal gelesen das es einen root eintrag (. zone) in den dns servern geben kann der so wie ich das verstanden habe gelöscht werden müsste. ich habe das noch nicht gesehen, ist wohl nur bei W2K3 DNS so. kannst du mal im DNS nachschaun od du einen . eintrag hast und das hier evtl. mitteilen bevor du aktionen durchführst. dann weis ich schon wen man fragen muss

 

Du meinst die Root-Zone.

Das passiert z.B. dann, wenn beim promoten der DC keine Verbindung zum Internet hat und somit die Stammserver nicht an/abfragen kann. Somit erstellt er sich selbst die "." Zone. Das bedeutet dann für den DNS, falls er eine Anfrage nicht beantworten kann, fragt er auch keinen weiteren DNS an, denn er geht ja davon aus - das er ein Root-Server wäre und wenn er es nicht weiss - weiss es keiner ;)

 

Diese Zone muss man löschen, es sei denn - man geht per Proxy ins Inet.

[IThome 10]

Ist die "." Zone nicht nur bei 2000 eingerichtet worden ? Bei 2003 hab ich das zumindest noch nicht gesehen, selbst wenn keine Verbindung zu den Rootservern besteht ...

[Daim 12]

Also ich habe es bisher auch noch nicht gesehen bzw. erlebt, aber ich lese in div. Foren/Newsgroups auch bei 2003 immer noch davon

[PathFinder 10]

Da klemmts nicht drann, die Tatsache ist mir auch schon seid 2000 bekannt =)

 

Seltsam ist ja wirklich das es über 194.25.0.60 alles tadelos funktioniert und über 194.25.0.68 eben nicht !

 

Fakt scheint zu sein das der Client den Domänen Sufix anhängt aber auch nicht den vollen sondern nur den letzten Teil sprich: meinefirma.de und nicht intern.meinefirma.de

 

folge ich Daims Rat und schließe die rekursiv aufzulösende adresse mit einem Punkt am ende ab, funkt es ja egal über welchen NS....

 

Ich kanns mir einfach nicht erklären, hab sowas auch noch nicht erlebt.

 

mfg Path