11
DNS Auflösung eines Hosts ergibt immer eine (falsche) IP. Selbst wenn ich Google befrage
Hallo zusammen,
ich habe hier ein kurioses Problem und verstehe einfach nicht wie es dazu kommt.
Ein Kunde von uns hat ein Problem mit einer bestimmten Website. Ohne ins Detail zu gehen was für Probleme das sind, habe ich heraus gefunden das es an dem physischen Host (mit der aufgelösten IP) liegt, der auf die Anfragen im Sinne des Kontextes nicht korrekt antwortet. Die URL lautet "etis.dealerconnection.com" und die Server liegen irgendwo in der Wolke von Akamai. etis.dealerconnection.com hat mehrere CNAMES und landet am Ende auf e125.x.akamaiedge.net.
Das Kuriose dabei ist nun folgendes: Löse ich diesen Host bei mir am Rechner auf, bekomme ich von Stunde zu Stunde eine andere IP. Aktuell ist es die 23.196.242.112. Bei meinem Kunden ist es aber IMMER (schon seit mehreren Tagen) die 72.246.170.87. Und eben dieser Host mit der IP 72.246.170.87 scheint hier falsch zu sein bzw antwortet nicht wie er sollte. Selbst wenn ich bei meinem Kunden einen Google DNS (8.8.8.8 oder 8.8.4.4) als DNS-Server angebe kommt stets die 72.246.170.87 bei der Auflösung heraus. Ich habe mit Wireshark geprüft ob die Anfragen auch wirklich an 8.8.8.8 gehen und kann dies bestätigen. Laut Wireshark gehen die UDP-Pakete an 8.8.8.8 und werden von dort auch immer mit der vermeintlich falschen IP beantwortet.
Ich stehe hier total auf dem Schlauch. Wie kann das sein? Was für Mechanismen raffe ich an dieser Stelle nicht?
Es wird eine Securepoint UTM als Hardware-Firewall eingesetzt mit der ich mich leider nicht auskenne. Aber macht die irgend eine Art DNS Injection??
Danke und Grüße
Martin
ich habe hier ein kurioses Problem und verstehe einfach nicht wie es dazu kommt.
Ein Kunde von uns hat ein Problem mit einer bestimmten Website. Ohne ins Detail zu gehen was für Probleme das sind, habe ich heraus gefunden das es an dem physischen Host (mit der aufgelösten IP) liegt, der auf die Anfragen im Sinne des Kontextes nicht korrekt antwortet. Die URL lautet "etis.dealerconnection.com" und die Server liegen irgendwo in der Wolke von Akamai. etis.dealerconnection.com hat mehrere CNAMES und landet am Ende auf e125.x.akamaiedge.net.
Das Kuriose dabei ist nun folgendes: Löse ich diesen Host bei mir am Rechner auf, bekomme ich von Stunde zu Stunde eine andere IP. Aktuell ist es die 23.196.242.112. Bei meinem Kunden ist es aber IMMER (schon seit mehreren Tagen) die 72.246.170.87. Und eben dieser Host mit der IP 72.246.170.87 scheint hier falsch zu sein bzw antwortet nicht wie er sollte. Selbst wenn ich bei meinem Kunden einen Google DNS (8.8.8.8 oder 8.8.4.4) als DNS-Server angebe kommt stets die 72.246.170.87 bei der Auflösung heraus. Ich habe mit Wireshark geprüft ob die Anfragen auch wirklich an 8.8.8.8 gehen und kann dies bestätigen. Laut Wireshark gehen die UDP-Pakete an 8.8.8.8 und werden von dort auch immer mit der vermeintlich falschen IP beantwortet.
Ich stehe hier total auf dem Schlauch. Wie kann das sein? Was für Mechanismen raffe ich an dieser Stelle nicht?
Es wird eine Securepoint UTM als Hardware-Firewall eingesetzt mit der ich mich leider nicht auskenne. Aber macht die irgend eine Art DNS Injection??
Danke und Grüße
Martin
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: 477948
Url: https://administrator.de/forum/dns-aufloesung-eines-hosts-ergibt-immer-eine-falsche-ip-selbst-wenn-ich-google-befrage-477948.html
Ausgedruckt am: 26.12.2024 um 12:12 Uhr
11 Kommentare
Neuester Kommentar
Hallo Martin,
logisch, weil Akamai auch ein hochdynamisches Netz ist und der Server hinter deren LBs wohl gut gefragt ist (oder einfach so "schwankt").
Du hast das Problem, weil die tolle SecurePoint einfach keine DNS-Einträge als Ziele hinterlegt bekommt, demnach hängst du dich Regelmäßig daran auf.
VG
logisch, weil Akamai auch ein hochdynamisches Netz ist und der Server hinter deren LBs wohl gut gefragt ist (oder einfach so "schwankt").
Du hast das Problem, weil die tolle SecurePoint einfach keine DNS-Einträge als Ziele hinterlegt bekommt, demnach hängst du dich Regelmäßig daran auf.
VG
Zitat von @mfernau:
Es wird eine Securepoint UTM als Hardware-Firewall eingesetzt mit der ich mich leider nicht auskenne. Aber macht die irgend eine Art DNS Injection??
Es wird eine Securepoint UTM als Hardware-Firewall eingesetzt mit der ich mich leider nicht auskenne. Aber macht die irgend eine Art DNS Injection??
Und wenn Du Dich "vor" die Firewall stellst mit Deiner Anfrage, bzw mal davor sniffst.: Ist dann das dieselbe Antwort?
Oder stell doch im Internet einen eigenen Nameserver hin und vergleiche dessen Antwort mit der, die beim Kunden ankommt, wenn er Deinen Nameserver nimmt.
lks
Das die Antworten oft neue IPs liefern ist mir schon klar. Das sind ganze Farmen dahinter. Alles gut. Ich verstehe nur nicht, wieso bei meinem Kunden immer dieselbe IP heraus kommt. Da ist doch was faul...
Was meinst Du mit
Meinst Du das in der Securepoint ggf noch ein DNS-Forwarder gepflegt werden muss? Eigentlich soll sich die UTM nicht um DNS-Anfragen kümmern. Das macht eigentlich der AD-Server im Netz. Und dieser AD-Server hat als Forwarder auch die Google-DNS Server hinterlegt. Am liebsten sollte die UTM gar nicht dazwischen funken.
Was meinst Du mit
Zitat von @certifiedit.net:
[...]
Du hast das Problem, weil die tolle SecurePoint einfach keine DNS-Einträge als Ziele hinterlegt bekommt [...]
[...]
Du hast das Problem, weil die tolle SecurePoint einfach keine DNS-Einträge als Ziele hinterlegt bekommt [...]
Meinst Du das in der Securepoint ggf noch ein DNS-Forwarder gepflegt werden muss? Eigentlich soll sich die UTM nicht um DNS-Anfragen kümmern. Das macht eigentlich der AD-Server im Netz. Und dieser AD-Server hat als Forwarder auch die Google-DNS Server hinterlegt. Am liebsten sollte die UTM gar nicht dazwischen funken.
Zitat von @Lochkartenstanzer:
Und wenn Du Dich "vor" die Firewall stellst mit Deiner Anfrage, bzw mal davor sniffst.: Ist dann das dieselbe Antwort?
Das geht leider nicht. Ich bin 300km weit weg und komme so erstmal nicht "dahinter".Und wenn Du Dich "vor" die Firewall stellst mit Deiner Anfrage, bzw mal davor sniffst.: Ist dann das dieselbe Antwort?
Oder stell doch im Internet einen eigenen Nameserver hin und vergleiche dessen Antwort mit der, die beim Kunden ankommt, wenn er Deinen Nameserver nimmt.
Martin
Zitat von @Lochkartenstanzer:
Oder stell doch im Internet einen eigenen Nameserver hin und vergleiche dessen Antwort mit der, die beim Kunden ankommt, wenn er Deinen Nameserver nimmt.
lks
Okay das ist interessant. Wenn ich einen von unseren DNS verwende wird tatsächlich mal eine andere IP geliefert. Wechsle ich zurück auf google kommt wieder die 72.246.170.87 wie schon seit Tagen.Oder stell doch im Internet einen eigenen Nameserver hin und vergleiche dessen Antwort mit der, die beim Kunden ankommt, wenn er Deinen Nameserver nimmt.
lks
Das ist ein anderes Ergebnis als ich erwartet habe. Dann antwortet in diesem Fall tatsächlich Google immer wieder mit derselben IP. Aber auch nur von meinem Kunden aus. Bei mir am PC wird ebenfalls Google als Forwarder verwendet und es kommt eine völlig andere und vor allem wecchselnde IP. Muss man das jetzt verstehen??
Zitat von @mfernau:
Das ist ein anderes Ergebnis als ich erwartet habe. Dann antwortet in diesem Fall tatsächlich Google immer wieder mit derselben IP. Aber auch nur von meinem Kunden aus. Bei mir am PC wird ebenfalls Google als Forwarder verwendet und es kommt eine völlig andere und vor allem wecchselnde IP. Muss man das jetzt verstehen??
Das ist ein anderes Ergebnis als ich erwartet habe. Dann antwortet in diesem Fall tatsächlich Google immer wieder mit derselben IP. Aber auch nur von meinem Kunden aus. Bei mir am PC wird ebenfalls Google als Forwarder verwendet und es kommt eine völlig andere und vor allem wecchselnde IP. Muss man das jetzt verstehen??
8.8.8.8 ist kein einzelner Host, sondern auch ein "CDN" für DNS. je nachdem, von wo man aus anfragt, antwortet ein anderes System. Faktisch heißt das, daß Du ein anderes System anfragst als Dein Kunde.
Du könntest übrigens auch mal cloudflare (1.1.1.1) oder quad9 (9.9.9.9) fragen.
Oder mal DoH (DNS over https) ausprobieren. Dann weiß man, ob die Antwort vom Nameserver kommt oder jemand "rumfummelt": https://developers.google.com/speed/public-dns/docs/dns-over-tls
lks
Zitat von @Lochkartenstanzer:
[...]
Du könntest übrigens auch mal cloudflare (1.1.1.1) oder quad9 (9.9.9.9) fragen.
[...]
Du könntest übrigens auch mal cloudflare (1.1.1.1) oder quad9 (9.9.9.9) fragen.
Genau den habe ich bereits genommen und es funktioniert jetzt endlich. Verstehen tue ich das trotzdem nicht. Das immer dieselbe IP von Google geliefert wird kann auch irgendwie nur ein Cache-Problem sein. Denn die TTL-Zeiten von e125.x.akamaiedge.net sind gerade einmal 20 Sekunden.
Nun denn, danke für den Anstoß mal einen anderen DNS-Server zu versuchen. Irgendwie hat sich in meinem Kopf festgebrannt das die Google DNS zuverlässige Resolver sind
Nein, dass du mit der SecurePoint nur nach IP erlauben kannst (imho willst du das). Die löst hierbei aber nicht als Einzelner Host auf, sondern als DNS Gruppe.
Dein Problem.
VG
Dein Problem.
VG
Zitat von @mfernau:
Nun denn, danke für den Anstoß mal einen anderen DNS-Server zu versuchen. Irgendwie hat sich in meinem Kopf festgebrannt das die Google DNS zuverlässige Resolver sind
Nun denn, danke für den Anstoß mal einen anderen DNS-Server zu versuchen. Irgendwie hat sich in meinem Kopf festgebrannt das die Google DNS zuverlässige Resolver sind
Nur, um es nochmal zusammenzufassen:
Dass du jedes Mal eine andere IP bei Akamai bekommst, gehört zu deren Nutzungserlebnis und ist Teil ihrer Strategie, Anfragen sowohl geographisch günstig zu routen (GeoDNS) als auch Load-Balancing und Ausfallsicherheit zu bieten.
Es ist vollkommen egal, welchen Resolver du fragst - alle werden dir immer was anderes erzählen, weil Akamai nur anhand der DNS-Anfrage und der IP-Adresse von der sie kommt (das ist der DNS-Resolver selbst) entscheiden kann, wo die Anfragen denn nun hingeleitet werden sollen.
Wenn du also 8.8.8.8 bei dir daheim fragst, wird deine Anfrage zu einer möglichst nahe gelegenen Instanz der 8.8.8.8 geroutet (Anycast), die widerum fragt die Akamai-Server und die werden denn eine IP-Adresse liefern, die in möglichst geographischer Nähe sein sollen.
Du kannst ja mal beliebige DNS-Server nach "whoami.akamai.net" fragen - da wird dir dann die IP zurückgeliefert, von der Akamai die DNS-Anfrage erhalten hat.
Jedenfalls bestimmt Akamai auf Basis dieser IP-Adresse, zu welchem Server sie deine Anfrage leiten wollen und liefern dann die entsprechende Adresse zurück. Genau deshalb ist es aber auch doof, irgendwelche dahergelaufenen DNS-Server zu nutzen, da Akamai das Routing anhand der IP-Adresse bestimmt, die du auch mit "whoami.akamai.net" siehst. Dann bekommst du nämlich meistens nicht unbedingt die optimalen Server für deinen Internetzugang zurückgeliefert sondern die, die für den Google-Server optimal erreichbar wären.
Zitat von @LordGurke:
Genau deshalb ist es aber auch doof, irgendwelche dahergelaufenen DNS-Server zu nutzen, ...
Genau deshalb ist es aber auch doof, irgendwelche dahergelaufenen DNS-Server zu nutzen, ...
Man sollte aus security-Sicht sowieso generell keine "dahergelaufenen" Server nutzen, insbesondere die quad1/8/9-Server nicht, und auch mit Nutzung der Provider-Server zurückhaltend sein. Eigene Nameserver sind immer noch am sinnvollsten und heutzutage auch mit wenigen Maus- oder Tastaturklicks einzurichten.
lks
Da hast du zweifelsohne Recht 
Ich verweise aber auch immer gerne auf genau diesen Umstand, weil der ziemlich unsubtil und wenig abstrakt greifbar ist:
Beispiel:
Frage ich den DNS-Resolver auf meinem Internetgateway nach "www.zdf.de" (was auch über Akamai gehostet wird):
~5ms von meinem Anschluss aus entfernt. Das ist ziemlich gut.
Jetzt frage ich mal z.B. Quad9:
Jetzt werden meine Anfragen erstmal über Hamburg nach Amsterdam geroutet - und brauchen dann halt auch direkt mehr als die dreifache Zeit dafür.
Hintergrund dafür ist, dass meine Anfrage an einen theoretisch nicht so weit entfernten Server von Quad9 geroutet wurde (mein Anschluss ist in Wuppertal, Nähe Düsseldorf):
"Mein" zuständiger Quad9-Server steht also in Amsterdam - daher nimmt Akamai dann an, dass es für mich günstig wäre, die Webseiten die ich haben will auch aus Amsterdam auszuliefern.
Man hat also einen echten, täglich spürbaren Nachteil bei der Nutzung dieser Resolver
Ich verweise aber auch immer gerne auf genau diesen Umstand, weil der ziemlich unsubtil und wenig abstrakt greifbar ist:
Beispiel:
Frage ich den DNS-Resolver auf meinem Internetgateway nach "www.zdf.de" (was auch über Akamai gehostet wird):
~# dig @localhost www.zdf.de. +short
ssl.zdf.de.edgekey.net.
e8383.e6.akamaiedge.net.
104.108.8.222
~# traceroute -I -q 1 -A 104.108.8.222
traceroute to 104.108.8.222 (104.108.8.222), 30 hops max, 60 byte packets
1 62.155.244.139 (62.155.244.139) [AS3320] 4.164 ms
2 217.239.55.41 (217.239.55.41) [AS3320] 5.317 ms
3 80.157.128.58 (80.157.128.58) [AS3320] 8.070 ms
4 a104-108-8-222.deploy.static.akamaitechnologies.com (104.108.8.222) [AS16625] 5.330 ms~5ms von meinem Anschluss aus entfernt. Das ist ziemlich gut.
Jetzt frage ich mal z.B. Quad9:
# dig @9.9.9.9 www.zdf.de. +short
ssl.zdf.de.edgekey.net.
e8383.e6.akamaiedge.net.
23.62.131.116
~# traceroute -I -q 1 -A 23.62.131.116
traceroute to 23.62.131.116 (23.62.131.116), 30 hops max, 60 byte packets
1 62.155.244.139 (62.155.244.139) [AS3320] 4.220 ms
2 hh-ea8-i.HH.DE.NET.DTAG.DE (62.154.32.126) [AS3320] 11.141 ms
3 hh-ea8-i.HH.DE.NET.DTAG.DE (62.154.32.126) [AS3320] 11.116 ms
4 80.150.168.162 (80.150.168.162) [AS3320] 10.348 ms
5 hbg-bb1-link.telia.net (213.155.135.80) [AS1299] 16.562 ms
6 adm-bb3-link.telia.net (213.155.136.160) [AS1299] 17.243 ms
7 adm-b1-link.telia.net (62.115.136.195) [AS1299] 17.010 ms
8 akamai-ic-335617-adm-b1.c.telia.net (62.115.162.235) [AS1299] 16.732 ms
9 a23-62-131-116.deploy.static.akamaitechnologies.com (23.62.131.116) [AS16625] 17.189 msJetzt werden meine Anfragen erstmal über Hamburg nach Amsterdam geroutet - und brauchen dann halt auch direkt mehr als die dreifache Zeit dafür.
Hintergrund dafür ist, dass meine Anfrage an einen theoretisch nicht so weit entfernten Server von Quad9 geroutet wurde (mein Anschluss ist in Wuppertal, Nähe Düsseldorf):
~# dig @9.9.9.9 whoami.akamai.net. +short
74.63.25.252
~# traceroute -I -q 1 -A 74.63.25.252
traceroute to 74.63.25.252 (74.63.25.252), 30 hops max, 60 byte packets
1 62.155.244.139 (62.155.244.139) [AS3320] 4.537 ms
2 217.239.60.6 (217.239.60.6) [AS3320] 5.459 ms
3 80.157.129.202 (80.157.129.202) [AS3320] 16.138 ms
4 *
5 4.68.72.246 (4.68.72.246) [AS3356] 2907.897 ms
6 res510.ams.rrdns.pch.net (74.63.25.252) [AS42] 10.825 ms"Mein" zuständiger Quad9-Server steht also in Amsterdam - daher nimmt Akamai dann an, dass es für mich günstig wäre, die Webseiten die ich haben will auch aus Amsterdam auszuliefern.
Man hat also einen echten, täglich spürbaren Nachteil bei der Nutzung dieser Resolver
