22
Keine DNS-Auflösung auf bestimmte Domain
Hallo,
ich habe irgendwie keine Idee mehr.
In meinem Netz gibt es zwei DNS-"Systeme":
A) Zwei Windows 2022 DCs mit jeweils DNS Server drauf. Einer davon ist auf allen anderen Serversystemen primärer DNS, der andere Sekundärer DNS. Die DNS-Server sind identisch konfiguriert. Es gibt eine bedingte Weiterleitung zu einer anderen Domain (nicht relevant). Alles, was nicht im lokalen DNS aufgelöst werden kann wird an die (Standard?) Liste von Root-DNS Servern gegeben (a.root = 198.41.0.4 usw.).
B) Ich habe noch einen komplett autarken DNS-Server auf meiner Sophos am laufen. Forwarding geht hier an Quad9 9.9.9.9.
Soweit funktioniert das alles und läuft auch schon länger so. Es gab keine kürzlichen Veränderungen.
Jetzt hatte ein Benutzer heute Probleme mit einer Webseite - keine DNS-Auflösung (die Domain muss ich wohl nennen
). Ich habe das jetzt gegen alle drei DNS Server getestet und im Internet auf dnschecker.org. Die beiden Windows-Systeme wollen die IPs hinter
www.ebnerstolz.de 94.186.144.230 und
eshare.ebnerstolz.de 141.95.22.201 (Dracoon-Instanz 1098705825.dracoon.cloud)
nicht auflösen. Auch nslookup schlägt fehl. Auf einem der beiden habe ich DNS-Cache geleert, DNS-Server neu gestartet und OS neu gestartet - kein Unterschied.
Auf meiner Sophos klappt alles wunderbar. Darüber komme ich auch an die beiden Webseiten aufrufen. dnschecker.org kann die DNS-Namen bei allen Diensten auflösen. Ich habe darüber hinaus auch keine andere Webseite finden können, die unter Windows DNS nicht läuft. Die beiden genannten hängen aber eigentlich auch nur Inhaltlich zusammen, vom Hosting her müssten das komplett unterschiedliche Dienste sein.
Der Kollege meinte, die hätten vor ca. 1 Monat noch funktioniert. Ist das jetzt irgendwo ein Glitch im Root-DNS? Eigentlich glaube ich nicht daran. Ich verstehe aber auch nicht, wo bei meinem Windows DNS noch eine Einschränkung oder ein Problem bestehen könnte.
ich habe irgendwie keine Idee mehr.
In meinem Netz gibt es zwei DNS-"Systeme":
A) Zwei Windows 2022 DCs mit jeweils DNS Server drauf. Einer davon ist auf allen anderen Serversystemen primärer DNS, der andere Sekundärer DNS. Die DNS-Server sind identisch konfiguriert. Es gibt eine bedingte Weiterleitung zu einer anderen Domain (nicht relevant). Alles, was nicht im lokalen DNS aufgelöst werden kann wird an die (Standard?) Liste von Root-DNS Servern gegeben (a.root = 198.41.0.4 usw.).
B) Ich habe noch einen komplett autarken DNS-Server auf meiner Sophos am laufen. Forwarding geht hier an Quad9 9.9.9.9.
Soweit funktioniert das alles und läuft auch schon länger so. Es gab keine kürzlichen Veränderungen.
Jetzt hatte ein Benutzer heute Probleme mit einer Webseite - keine DNS-Auflösung (die Domain muss ich wohl nennen
). Ich habe das jetzt gegen alle drei DNS Server getestet und im Internet auf dnschecker.org. Die beiden Windows-Systeme wollen die IPs hinterwww.ebnerstolz.de 94.186.144.230 und
eshare.ebnerstolz.de 141.95.22.201 (Dracoon-Instanz 1098705825.dracoon.cloud)
nicht auflösen. Auch nslookup schlägt fehl. Auf einem der beiden habe ich DNS-Cache geleert, DNS-Server neu gestartet und OS neu gestartet - kein Unterschied.
Auf meiner Sophos klappt alles wunderbar. Darüber komme ich auch an die beiden Webseiten aufrufen. dnschecker.org kann die DNS-Namen bei allen Diensten auflösen. Ich habe darüber hinaus auch keine andere Webseite finden können, die unter Windows DNS nicht läuft. Die beiden genannten hängen aber eigentlich auch nur Inhaltlich zusammen, vom Hosting her müssten das komplett unterschiedliche Dienste sein.
Der Kollege meinte, die hätten vor ca. 1 Monat noch funktioniert. Ist das jetzt irgendwo ein Glitch im Root-DNS? Eigentlich glaube ich nicht daran. Ich verstehe aber auch nicht, wo bei meinem Windows DNS noch eine Einschränkung oder ein Problem bestehen könnte.
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: 670210
Url: https://administrator.de/forum/keine-dns-aufloesung-auf-bestimmte-domain-670210.html
Ausgedruckt am: 16.01.2025 um 21:01 Uhr
22 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
Ich verstehe aber auch nicht, wo bei meinem Windows DNS noch eine Einschränkung oder ein Problem bestehen könnte.
DNSSEC auf den Windows Servern aktiviert? Sprich nicht für euere DNS-Zonen sondern für das Forwarding. Gibt da leider nach wie vor Probleme....Gruß,
Dani
1
Nicht das ich wüsste, gucke ich heute Abend nochmal rein
Heisst die Domain, denen die zwei DC's angehören evtl auch ebnerstolz.de?
also es gibt viele ursachen.
können DNS Probleme sein, können sogar provider spezifische probleme sein.
Wenn die gleiche leitung mit anderem DNS geht, dann liegts an den root DNS Einträgen.
Ich hatte es mal so das ich 2 Provider hatte.
Hab ich den traffic über leitung 1 geschickt gings nicht, über leitung 2 ja, und DNS war komplett identisch, kann also sogar Provider spezifische routing probleme geben will ich damit sagen...
Internet ist was feines
können DNS Probleme sein, können sogar provider spezifische probleme sein.
Wenn die gleiche leitung mit anderem DNS geht, dann liegts an den root DNS Einträgen.
Ich hatte es mal so das ich 2 Provider hatte.
Hab ich den traffic über leitung 1 geschickt gings nicht, über leitung 2 ja, und DNS war komplett identisch, kann also sogar Provider spezifische routing probleme geben will ich damit sagen...
Internet ist was feines
Moin @ukulele-7,
und genau an dieser Stelle, sprich, bei deinen AD-DNS-Servern, liegt laut meiner Kristallkugel angeblich der Hund begraben. Denn die Stammhinweise, sollte der DNS Server im Normalfall überhaupt nicht verwenden (weil unter anderem grotten langsam), sondern die Anfragen die er selbst nicht beantworten kann, an einen anderen (sicheren) DNS Server weiterleiten.
Trag mal bitte unter den Eigenschaften der beiden internen DNS-Servern, bei "Weiterleitungen" ...
... die interne IP deiner Sophos ein.
Das sollte dein Problem auch schon beheben.
Das ist suboptimal, hier solltest du eher die DNS Server deines ISP's verwenden.
Gruss Alex
A) Zwei Windows 2022 DCs mit jeweils DNS Server drauf. Einer davon ist auf allen anderen Serversystemen primärer DNS, der andere Sekundärer DNS. Die DNS-Server sind identisch konfiguriert. Es gibt eine bedingte Weiterleitung zu einer anderen Domain (nicht relevant). Alles, was nicht im lokalen DNS aufgelöst werden kann wird an die (Standard?) Liste von Root-DNS Servern gegeben (a.root = 198.41.0.4 usw.).
und genau an dieser Stelle, sprich, bei deinen AD-DNS-Servern, liegt laut meiner Kristallkugel angeblich der Hund begraben. Denn die Stammhinweise, sollte der DNS Server im Normalfall überhaupt nicht verwenden (weil unter anderem grotten langsam), sondern die Anfragen die er selbst nicht beantworten kann, an einen anderen (sicheren) DNS Server weiterleiten.
Trag mal bitte unter den Eigenschaften der beiden internen DNS-Servern, bei "Weiterleitungen" ...
... die interne IP deiner Sophos ein.
Das sollte dein Problem auch schon beheben.
B) Ich habe noch einen komplett autarken DNS-Server auf meiner Sophos am laufen. Forwarding geht hier an Quad9 9.9.9.9.
Das ist suboptimal, hier solltest du eher die DNS Server deines ISP's verwenden.
Gruss Alex
2
Hatte erst kürzlich auch ein paar Themen mit Dracoon, angelbich hatten die etwas geändert worauhin die Links von unseren Provider nicht mehr funktionierten (wollte auf einmal ein www. davor haben, woraufhin auf die Adresse ohne www. gelinkt wurde).
Bei ISP DNS verwenden bin ich eher skeptisch, wenn ich die von Vodafone verwende hab ich die meisten Fehler. Telekom sporadisch auch, MNet meist stabil. 1.1.1.1 und 8.8.8.8 haben das letzte Jahrzehnt immer funktioniert.
Für interne DNS Auflösung hab ich auch alle Hosts noch zusätzlich auf der Sophos und sie auch noch als dritter DNS. Für Linux Kisten funktioniert es besser (als einziger DNS), braucht man keine Lizenz von Microsoft und wenn ein Update auf den DCs das DNS schrottet hat man ein Fallback.
Bei ISP DNS verwenden bin ich eher skeptisch, wenn ich die von Vodafone verwende hab ich die meisten Fehler. Telekom sporadisch auch, MNet meist stabil. 1.1.1.1 und 8.8.8.8 haben das letzte Jahrzehnt immer funktioniert.
Für interne DNS Auflösung hab ich auch alle Hosts noch zusätzlich auf der Sophos und sie auch noch als dritter DNS. Für Linux Kisten funktioniert es besser (als einziger DNS), braucht man keine Lizenz von Microsoft und wenn ein Update auf den DCs das DNS schrottet hat man ein Fallback.
Zitat von @Dani:
DNSSEC auf den Windows Servern aktiviert? Sprich nicht für euere DNS-Zonen sondern für das Forwarding. Gibt da leider nach wie vor Probleme....
Kein DNSSEC, aber auch kein Forwarding sondern nur Stammhinweise (siehe weiter unten).DNSSEC auf den Windows Servern aktiviert? Sprich nicht für euere DNS-Zonen sondern für das Forwarding. Gibt da leider nach wie vor Probleme....
Nein, da gibt es keine Zusammenhänge und auch keine eigene Konfiguration in unserem DNS.
Zitat von @ThePinky777:
Hab ich den traffic über leitung 1 geschickt gings nicht, über leitung 2 ja, und DNS war komplett identisch, kann also sogar Provider spezifische routing probleme geben will ich damit sagen...
Hm also du meinst die Leitung, über die die DNS Abfrage läuft? Wir haben tatsächlich zwei ISPs...Hab ich den traffic über leitung 1 geschickt gings nicht, über leitung 2 ja, und DNS war komplett identisch, kann also sogar Provider spezifische routing probleme geben will ich damit sagen...
Zitat von @MysticFoxDE:
Trag mal bitte unter den Eigenschaften der beiden internen DNS-Servern, bei "Weiterleitungen" ...
Schon richtig, ich hatte mal früher auch hier mal die Sophos oder 9.9.9.9 gesetzt, aber das ist gefühlt ewig her. Mir war nicht bewusst, das Stammhinweise nachteilig sind.Trag mal bitte unter den Eigenschaften der beiden internen DNS-Servern, bei "Weiterleitungen" ...
... die interne IP deiner Sophos ein.
Das sollte dein Problem auch schon beheben.
Habe die 9.9.9.9 eingetragen, damit klappt es natürlich auch sofort. Dennoch verwundert mich das Verhalten ohne diesen Eintrag, das habe ich nicht erwartet.Das sollte dein Problem auch schon beheben.
Tatsächlich will ich keine Abhängigkeiten untereinander schaffen und wirklich redundant konfigurieren, daher nicht die Sophos. Früher war das eine Art Ausfallsicherheit (hatte früher nur einen DC mit DNS), mittlerweile lerne ich dadurch viel. Grade in diesem Fall war das nützlich.
B) Ich habe noch einen komplett autarken DNS-Server auf meiner Sophos am laufen. Forwarding geht hier an Quad9 9.9.9.9.
Das ist suboptimal, hier solltest du eher die DNS Server deines ISP's verwenden.
Auf der Sophos nutze ich die beiden ISP DNS als Fallback, da muss ich aber nochmal rein schauen ob
Zitat von @WoenK0:
Hatte erst kürzlich auch ein paar Themen mit Dracoon, angelbich hatten die etwas geändert worauhin die Links von unseren Provider nicht mehr funktionierten (wollte auf einmal ein www. davor haben, woraufhin auf die Adresse ohne www. gelinkt wurde).
Wäre nur die Dracoon-Instanz betroffen gewesen, hätte ich da auch Vermutungen angestellt. Kurioserweise betrifft es aber auch den Webserver und erwartungsgemäß teilen die eigentlich nichts außer die Domain unter der sie laufen. Vermutlich liegt das DNS bei deren Webhoster (Globalways GmbH).Hatte erst kürzlich auch ein paar Themen mit Dracoon, angelbich hatten die etwas geändert worauhin die Links von unseren Provider nicht mehr funktionierten (wollte auf einmal ein www. davor haben, woraufhin auf die Adresse ohne www. gelinkt wurde).
Ich habe noch eine weitere Webseite gefunden, die gestern Probleme hatte: hpe.com . Nun ist das bei HPE nicht verwunderlich sondern absolut normal, ich bin da auch nicht oft drauf. Gestern konnte ich mich da zwar bewegen, nur Downloads gingen nicht. Habe das aber eben getestet, auch das geht jetzt wieder.
Sehr sonderbar. Solche Probleme hatte ich monatelang nicht.
Sehr sonderbar. Solche Probleme hatte ich monatelang nicht.
Beobachte das mal weiter. Auch wir hatten, wie @Dani schon sagt, Probleme mit DNSSEC.
Dies ist bei Server 2022 standardmäßig aktiviert (DNS-Server → Eigenschaften → Erweitert → DNSSEC-Überprüfung für Remoteantwort aktivieren).
Das funktioniert eine ganze Zeit und plötzlich können einzelne Domains nicht mehr aufgelöst werden. Löscht man den Cache, geht es tw. für unbestimmte Zeit.
Bei uns betraf es u.a. chatgpt.com über Cloudflare DNS.
Dies ist bei Server 2022 standardmäßig aktiviert (DNS-Server → Eigenschaften → Erweitert → DNSSEC-Überprüfung für Remoteantwort aktivieren).
Das funktioniert eine ganze Zeit und plötzlich können einzelne Domains nicht mehr aufgelöst werden. Löscht man den Cache, geht es tw. für unbestimmte Zeit.
Bei uns betraf es u.a. chatgpt.com über Cloudflare DNS.
2Zitat von @prinzjulius:
Dies ist bei Server 2022 standardmäßig aktiviert (DNS-Server → Eigenschaften → Erweitert → DNSSEC-Überprüfung für Remoteantwort aktivieren).
Stimmt, das habe ich übersehen und ist aktiv.Dies ist bei Server 2022 standardmäßig aktiviert (DNS-Server → Eigenschaften → Erweitert → DNSSEC-Überprüfung für Remoteantwort aktivieren).
Das funktioniert eine ganze Zeit und plötzlich können einzelne Domains nicht mehr aufgelöst werden. Löscht man den Cache, geht es tw. für unbestimmte Zeit.
Den Cache habe ich gestern gezielt gelöscht, sowohl am DNS-Client als auch am DNS-Server + Neustart Dienst + Neustart OS. Das Verhalten hat sich nicht geändert, bis ich heute Morgen die Weiterleitung gesetzt habe.Bei uns betraf es u.a. chatgpt.com über Cloudflare DNS.
Interessant. Eventuell nehme ich die Weiterleitung nochmal raus, aber wohl erst am Wochenende...Den Cache habe ich gestern gezielt gelöscht, sowohl am DNS-Client als auch am DNS-Server + Neustart Dienst + Neustart OS. Das Verhalten hat sich nicht geändert, bis ich heute Morgen die Weiterleitung gesetzt habe.
Du sagtest, du hast den Cache nur auf einem DNS-Server gelöscht. Hast du denn beim anschließenden Test auch explizit diesen Server zum Auflösen der Domain angegeben?
nslookup ebnerstolz.de DNS01.domain.tldSonst ist evtl. der andere Server verwendet worden, der den Cache noch hat.
1
Moin,
Gruß,
Dani
Stimmt, das habe ich übersehen und ist aktiv.
dann nimm es temporär auf allen DCs raus, diese neu starten, DNS Cache löschen und dann nochmals probieren.Gruß,
Dani
1
Moin @ukulele-7,
die Stammhinweise sind DNS technisch eher als die letzte Bastion, aber keinesweg als der optimalse/effizienteste/sicherste Weg zu sehen.
Mich wunder es eher, dass du ohne eine Weiterleitung nicht schon eher die Probleme gehabt hast. 🙃
Na ja, genaugenommen solltest du insbesondere auch bei einem SGW wie einer Sophos XGS oder auch SG auf eine saubere DNS-Auflösungs-Kette achten, da ansonsten z.B. die C&C Erkennung des SGW's, die zum Teil auch DNS bassiert funktioniert, schlichtweg nicht greift. 😔
Sprich, Clients sollten nur entweder gegen die internen DC's, respektive deren DNS-Server auflösen oder gegen das SGW, die DC sollten ihre externen Anfragen gegen das SGW abwerfen und das SGW sollte seine externen Anfragen gegen die DNS des ISP's abfeuern, weil diese im Normalfall am nächsten liegen.
Nein, eher Datenschutz, insbesondere auch bei 8.8.8.8 oder 1.1.1.1. 😉
Gruss Alex
Schon richtig, ich hatte mal früher auch hier mal die Sophos oder 9.9.9.9 gesetzt, aber das ist gefühlt ewig her. Mir war nicht bewusst, das Stammhinweise nachteilig sind.
die Stammhinweise sind DNS technisch eher als die letzte Bastion, aber keinesweg als der optimalse/effizienteste/sicherste Weg zu sehen.
Habe die 9.9.9.9 eingetragen, damit klappt es natürlich auch sofort. Dennoch verwundert mich das Verhalten ohne diesen Eintrag, das habe ich nicht erwartet.
Mich wunder es eher, dass du ohne eine Weiterleitung nicht schon eher die Probleme gehabt hast. 🙃
Tatsächlich will ich keine Abhängigkeiten untereinander schaffen und wirklich redundant konfigurieren, daher nicht die Sophos. Früher war das eine Art Ausfallsicherheit (hatte früher nur einen DC mit DNS), mittlerweile lerne ich dadurch viel. Grade in diesem Fall war das nützlich.
Na ja, genaugenommen solltest du insbesondere auch bei einem SGW wie einer Sophos XGS oder auch SG auf eine saubere DNS-Auflösungs-Kette achten, da ansonsten z.B. die C&C Erkennung des SGW's, die zum Teil auch DNS bassiert funktioniert, schlichtweg nicht greift. 😔
Sprich, Clients sollten nur entweder gegen die internen DC's, respektive deren DNS-Server auflösen oder gegen das SGW, die DC sollten ihre externen Anfragen gegen das SGW abwerfen und das SGW sollte seine externen Anfragen gegen die DNS des ISP's abfeuern, weil diese im Normalfall am nächsten liegen.
Das ist suboptimal, hier solltest du eher die DNS Server deines ISP's verwenden.
Wieso? Geschwindigkeit?Nein, eher Datenschutz, insbesondere auch bei 8.8.8.8 oder 1.1.1.1. 😉
Gruss Alex
Zitat von @prinzjulius:
Du sagtest, du hast den Cache nur auf einem DNS-Server gelöscht. Hast du denn beim anschließenden Test auch explizit diesen Server zum Auflösen der Domain angegeben?
Nein, habe nur an einem gelöscht. Hatte aber heute Morgen auch den anderen noch neu gestartet (Windows Updates) um den gleich zu ziehen, und dann nochmal auf beiden getest. Ich werde nochmal einen "sauberen" Test machen.Du sagtest, du hast den Cache nur auf einem DNS-Server gelöscht. Hast du denn beim anschließenden Test auch explizit diesen Server zum Auflösen der Domain angegeben?
nslookup ebnerstolz.de DNS01.domain.tldZitat von @MysticFoxDE:
Na ja, genaugenommen solltest du insbesondere auch bei einem SGW wie einer Sophos XGS oder auch SG auf eine saubere DNS-Auflösungs-Kette achten, da ansonsten z.B. die C&C Erkennung des SGW's, die zum Teil auch DNS bassiert funktioniert, schlichtweg nicht greift. 😔
Ja das ist schon sauber, denke ich.Na ja, genaugenommen solltest du insbesondere auch bei einem SGW wie einer Sophos XGS oder auch SG auf eine saubere DNS-Auflösungs-Kette achten, da ansonsten z.B. die C&C Erkennung des SGW's, die zum Teil auch DNS bassiert funktioniert, schlichtweg nicht greift. 😔
Das ist suboptimal, hier solltest du eher die DNS Server deines ISP's verwenden.
Wieso? Geschwindigkeit?Nein, eher Datenschutz, insbesondere auch bei 8.8.8.8 oder 1.1.1.1. 😉
Mit den Deutschen ISPs habe ich tatsächlich auch kein Problem i.S. Datenschutz aber technisch sind die schonmal unzuverlässig, zumindest Vodafone / Unitymedia.
Lässt du auf der Sophos ausgehende DNS-Anfragen nur für UDP oder auch für TCP zu?
Und kannst du die delegierten Nameserver (ns[1-3].vodafone-ip.de) direkt abfragen, ob und was die dir antworten, bzw. kannst du sie per Traceroute erreichen?
Und kannst du die delegierten Nameserver (ns[1-3].vodafone-ip.de) direkt abfragen, ob und was die dir antworten, bzw. kannst du sie per Traceroute erreichen?
Zitat von @LordGurke:
Lässt du auf der Sophos ausgehende DNS-Anfragen nur für UDP oder auch für TCP zu?
Guter Ansatz aber es ist tatsächlich immer UDP/TCP gesetzt in der Sophos.Lässt du auf der Sophos ausgehende DNS-Anfragen nur für UDP oder auch für TCP zu?
Und kannst du die delegierten Nameserver (ns[1-3].vodafone-ip.de) direkt abfragen, ob und was die dir antworten, bzw. kannst du sie per Traceroute erreichen?
Nein Vodafone habe ich in der Vergangenheit mal genutzt. Aktuell ist es nur 9.9.9.9 .Zitat von @ukulele-7:
Und kannst du die delegierten Nameserver (ns[1-3].vodafone-ip.de) direkt abfragen, ob und was die dir antworten, bzw. kannst du sie per Traceroute erreichen?
Nein Vodafone habe ich in der Vergangenheit mal genutzt. Aktuell ist es nur 9.9.9.9 .Das sind keine Resolver, die Domain liegt auf auf diesen autoritativen Servern:
$ dig +norec @f.nic.de. ebnerstolz.de. NS
; <<>> DiG 9.20.3 <<>> +norec @f.nic.de. ebnerstolz.de. NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52141
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;ebnerstolz.de. IN NS
;; AUTHORITY SECTION:
ebnerstolz.de. 86400 IN NS ns1.vodafone-ip.de.
ebnerstolz.de. 86400 IN NS ns2.vodafone-ip.de.
ebnerstolz.de. 86400 IN NS ns3.vodafone-ip.de.
;; Query time: 6 msec
;; SERVER: 2a02:568:0:2::53#53(f.nic.de.) (UDP)
;; WHEN: Wed Dec 18 11:17:25 CET 2024
;; MSG SIZE rcvd: 108Da wäre jetzt die Frage, ob dir diese Nameserver antworten wenn du sie direkt befragst.
Nachtrag: Es könnte auch an dem CNAME "1098705825.dracoon.cloud" liegen, auf den in "eshare" verwiesen wird.
Die Domain "dracoon.cloud" hat nämlich eine inkonsistente Nameserver-Delegation, was manche Resolver nicht mögen:
In den Nameservern für "cloud" wird auf die autoritativen Nameserver "acns0[1-5].anexia-it.com" verwiesen, in der DNS-Zone von "dracoon.cloud" stehen allerdings die Nameserver "acns0[1-5].xaas.systems" als autoritativ.
Beide Varianten lösen auf die selben IPs auf und eigentlich sollte diese Inkonsistenz kein Problem sein, welches zu DNS-Auflösungsproblemen führt, aber...
Kannst du einmal separat testen, welche Antworten du (dig, nslookup...) erhältst, wenn du explizit nach "eshare.ebnerstolz.de" und nach "1098705825.dracoon.cloud" fragst?
Die Domain "dracoon.cloud" hat nämlich eine inkonsistente Nameserver-Delegation, was manche Resolver nicht mögen:
$ dig +trace +dnssec '1098705825.dracoon.cloud.'
; <<>> DiG 9.20.3 <<>> +trace +dnssec 1098705825.dracoon.cloud.
;; global options: +cmd
. 25859 IN NS g.root-servers.net.
. 25859 IN NS e.root-servers.net.
. 25859 IN NS b.root-servers.net.
. 25859 IN NS k.root-servers.net.
. 25859 IN NS l.root-servers.net.
. 25859 IN NS m.root-servers.net.
. 25859 IN NS h.root-servers.net.
. 25859 IN NS d.root-servers.net.
. 25859 IN NS i.root-servers.net.
. 25859 IN NS f.root-servers.net.
. 25859 IN NS c.root-servers.net.
. 25859 IN NS j.root-servers.net.
. 25859 IN NS a.root-servers.net.
. 25859 IN RRSIG NS 8 0 518400 20241230050000 20241217040000 61050 . rswM6OY8ylCNnmkfbUrdnNcTyPMuraztXrBbrrfTOO1M3vp9gCea+qj+ FKEPxb/M7EwJYthquLPfOX+5nkV2ROBFwXrTBYS4Zg6zLC40lNwPFqdY 9X2cYpfYW1ljr1LuW9bEyBYwCfZB8g7eg+v0nMyrX+uDLH2mneiwJhiZ orJTZqVegiHMlX5jNe+btW7uJdAD+05MkI8CP8uD4ZElZ4ghjAG77aZB DLD9Ra+SE4j/1ECrkWEwP543tlYq0mmLIDP3TDObTGFMy3qjjItQtM83 NmCWD8OAFNbl28AaYMDREpMryZDaxPXNEYiAF3JDfTyM1otJqd7C9kjm 9gM/qg==
;; Received 525 bytes from 2a02:a00:f::c2#53(2a02:a00:f::c2) in 3 ms
cloud. 172800 IN NS ns01.trs-dns.com.
cloud. 172800 IN NS ns01.trs-dns.net.
cloud. 172800 IN NS ns01.trs-dns.org.
cloud. 172800 IN NS ns01.trs-dns.info.
cloud. 86400 IN DS 7041 13 2 03E1B41319FDD3A14E27CE35FFBA8036DA51E328165CE102AE69A6C1 203F64E4
cloud. 86400 IN RRSIG DS 8 1 86400 20241231050000 20241218040000 61050 . Md6zI9JgyzDDid3VFq4xzm94D91YO+5hgqhB+HiB6O+n0pJnpkg709zq b6eGRAJc/b7UjINngKcTbVqT+s5HawDPbsj2eGYq6JfpiJlSkkwGp0V4 tP8LoVXKs+8B5Xdcp4U3m/FccJ2BeEnI1J3vP3+Kskq8KfDm3xztlySQ Wxop8JSIsCODQESHXQYPGTBELwngknyJaj7WrwDg8qFgaI0VAe+GhCDN N0jRqEGnXfSZTnH0tTv5EweehJV0M0aTT2efLBwhcJn5ZvN6Yt7N/eNX 9qt7dNjvcv3GbWF2ERD0B5/yT0xx3au3JKvlIvVuzY3nfjoi6H9AEwHB O3Il/g==
;; Received 657 bytes from 2001:500:2f::f#53(f.root-servers.net) in 0 ms
dracoon.cloud. 900 IN NS acns03.anexia-it.com. <--- inkonsistent zur autoritativen Zone
dracoon.cloud. 900 IN NS acns04.anexia-it.com.
dracoon.cloud. 900 IN NS acns01.anexia-it.com.
dracoon.cloud. 900 IN NS acns02.anexia-it.com.
dracoon.cloud. 900 IN NS acns05.anexia-it.com.
HT3BBE52QFEA3EKHEL6VAE4CVUE8777V.cloud. 300 IN NSEC3 1 1 0 - HT6L5OLG1P6S8KJ46GSSFH8NK8V88KN8 NS SOA RRSIG DNSKEY NSEC3PARAM
HT3BBE52QFEA3EKHEL6VAE4CVUE8777V.cloud. 300 IN RRSIG NSEC3 13 2 300 20250117092137 20241218092137 36804 cloud. uyd7Qw8H1J5aGprRcKJ5vNfM4Iun2pv8/Bs3g7J4AomsJABPxhvgZu4/ jGPWRPHZy6JgkqCYHdshhsF1qYB23w==
R8LBMBPDIKQ5A6550BPBMA6LVVQAGNT2.cloud. 300 IN NSEC3 1 1 0 - R8MIMJS57OIMOHHGO7HH1PARH48E7LBC NS DS RRSIG
R8LBMBPDIKQ5A6550BPBMA6LVVQAGNT2.cloud. 300 IN RRSIG NSEC3 13 2 300 20250117092137 20241218092137 36804 cloud. TB5kKx6HXSK8eZThM4DOq81tZyaRzwvmPksOd4wqPm5PLK9c0EffrinI Mbaytz1OXoQ8OCD/ZcU4l2fTCix8Lg==
;; Received 565 bytes from 2620:57:4002::1#53(ns01.trs-dns.net) in 3 ms
1098705825.dracoon.cloud. 900 IN A 141.95.22.201
dracoon.cloud. 3600 IN NS acns02.xaas.systems. <---- inkonsistent zur Delegation
dracoon.cloud. 3600 IN NS acns05.xaas.systems.
dracoon.cloud. 3600 IN NS acns01.xaas.systems.
dracoon.cloud. 3600 IN NS acns03.xaas.systems.
dracoon.cloud. 3600 IN NS acns04.xaas.systems.
;; Received 186 bytes from 2a00:11c0:aa1::1#53(acns01.anexia-it.com) in 6 msIn den Nameservern für "cloud" wird auf die autoritativen Nameserver "acns0[1-5].anexia-it.com" verwiesen, in der DNS-Zone von "dracoon.cloud" stehen allerdings die Nameserver "acns0[1-5].xaas.systems" als autoritativ.
Beide Varianten lösen auf die selben IPs auf und eigentlich sollte diese Inkonsistenz kein Problem sein, welches zu DNS-Auflösungsproblemen führt, aber...
Kannst du einmal separat testen, welche Antworten du (dig, nslookup...) erhältst, wenn du explizit nach "eshare.ebnerstolz.de" und nach "1098705825.dracoon.cloud" fragst?
Ich glaube, ich bin nicht ganz sicher worauf du hinaus willst
dc.meinedomain.de hat aktuell die Weiterleitung an 9.9.9.9 gesetzt, daher sind natürlich keine Unterschiede zu erwarten.
Ich bekomme von ns1.vodafone-ip.de [145.253.2.19] keinen Ping zurück, von acns05.xaas.systems [185.81.208.1] aber schon.
C:\>nslookup
Standardserver: dc.meinedomain.de
Address: 10.0.*.*
> set type=NS
> www.ebnerstolz.de.
Server: dc.meinedomain.de
Address: 10.0.*.*
ebnerstolz.de
primary name server = ns1.vodafone-ip.de
responsible mail addr = hostmaster.adm.arcor.net
serial = 2024121100
refresh = 28800 (8 hours)
retry = 14400 (4 hours)
expire = 1814400 (21 days)
default TTL = 7200 (2 hours)
> eshare.ebnerstolz.de.
Server: dc.meinedomain.de
Address: 10.0.*.*
Nicht autorisierende Antwort:
eshare.ebnerstolz.de canonical name = 1098705825.dracoon.cloud
> 1098705825.dracoon.cloud.
Server: dc.meinedomain.de
Address: 10.0.*.*
dracoon.cloud
primary name server = acns05.xaas.systems
responsible mail addr = j.schreier.dracoon.com
serial = 554
refresh = 14400 (4 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 3600 (1 hour)
> server 9.9.9.9
Standardserver: dns9.quad9.net
Address: 9.9.9.9
> www.ebnerstolz.de.
Server: dns9.quad9.net
Address: 9.9.9.9
ebnerstolz.de
primary name server = ns1.vodafone-ip.de
responsible mail addr = hostmaster.adm.arcor.net
serial = 2024121100
refresh = 28800 (8 hours)
retry = 14400 (4 hours)
expire = 1814400 (21 days)
default TTL = 7200 (2 hours)
> eshare.ebnerstolz.de.
Server: dns9.quad9.net
Address: 9.9.9.9
Nicht autorisierende Antwort:
eshare.ebnerstolz.de canonical name = 1098705825.dracoon.cloud
dracoon.cloud
primary name server = acns05.xaas.systems
responsible mail addr = j.schreier.dracoon.com
serial = 554
refresh = 14400 (4 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 3600 (1 hour)
> 1098705825.dracoon.cloud.
Server: dns9.quad9.net
Address: 9.9.9.9
dracoon.cloud
primary name server = acns05.xaas.systems
responsible mail addr = j.schreier.dracoon.com
serial = 554
refresh = 14400 (4 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 3600 (1 hour)
>Ich bekomme von ns1.vodafone-ip.de [145.253.2.19] keinen Ping zurück, von acns05.xaas.systems [185.81.208.1] aber schon.
C:\>tracert ns1.vodafone-ip.de
Routenverfolgung zu ns1.vodafone-ip.de [145.253.2.19]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 10.0.*.*
2 <1 ms <1 ms <1 ms ip-xxx-xxx-xxx-xxx.um19.pools.vodafone-ip.de [xxx.xxx.xxx.xxx]
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * ^C
C:\>tracert acns05.xaas.systems
Routenverfolgung zu acns05.xaas.systems [185.81.208.1]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 10.0.*.*
2 <1 ms <1 ms <1 ms ip-xxx-xxx-xxx-xxx.um19.pools.vodafone-ip.de [xxx.xxx.xxx.xxx]
3 15 ms 16 ms 11 ms ip-109-192-225-253.um38.pools.vodafone-ip.de [109.192.225.253]
4 12 ms 11 ms 11 ms ip-081-210-151-026.um21.pools.vodafone-ip.de [81.210.151.26]
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 17 ms 16 ms 17 ms ae3-1337.bbr02.anx25.fra.de.anexia-it.net [80.81.195.166]
8 13 ms 14 ms 15 ms acns05.xaas.systems [185.81.208.1]
Ablaufverfolgung beendet.
C:\>nslookup www.ebnerstolz.de. ns1.vodafone-ip.de
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 145.253.2.19
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.
C:\>nslookup eshare.ebnerstolz.de. acns05.xaas.systems
Server: UnKnown
Address: 185.81.208.1
*** eshare.ebnerstolz.de. wurde von UnKnown nicht gefunden: Query refused.
C:\>nslookup 1098705825.dracoon.cloud. acns05.xaas.systems
Server: UnKnown
Address: 185.81.208.1
Name: 1098705825.dracoon.cloud
Address: 141.95.22.201
Da dürfte dein Problem liegen:
Und auf DNS antwortet der (dir) auch nicht:
Wenn das bei ns2 und ns3 auch so ist, kann keine DNS-Auflösung mehr stattfinden.
Bei einer Messung mit 250 Probes im Vodafone-Netz haben 27 keine Antwort erhalten – das dürfte also ein Problem im Vodafone-Netz sein.
Du könntest dich da einmal an den Hostmaster des Nameservers wenden, laut SOA soll man sich an hostmaster(@)adm.arcor.de wenden und denen vielleicht den Link zur ATLAS-Messung schicken:
C:\>tracert ns1.vodafone-ip.de
Routenverfolgung zu ns1.vodafone-ip.de [145.253.2.19]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 10.0.*.*
2 <1 ms <1 ms <1 ms ip-xxx-xxx-xxx-xxx.um19.pools.vodafone-ip.de [xxx.xxx.xxx.xxx]
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.Und auf DNS antwortet der (dir) auch nicht:
C:\>nslookup www.ebnerstolz.de. ns1.vodafone-ip.de
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 145.253.2.19
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.Wenn das bei ns2 und ns3 auch so ist, kann keine DNS-Auflösung mehr stattfinden.
Bei einer Messung mit 250 Probes im Vodafone-Netz haben 27 keine Antwort erhalten – das dürfte also ein Problem im Vodafone-Netz sein.
Du könntest dich da einmal an den Hostmaster des Nameservers wenden, laut SOA soll man sich an hostmaster(@)adm.arcor.de wenden und denen vielleicht den Link zur ATLAS-Messung schicken:
$ dig +short ebnerstolz.de. SOA
ns1.vodafone-ip.de. hostmaster.adm.arcor.net. 2024121100 28800 14400 1814400 7200
Hm grundsätzlich gebe ich dir Recht, das sollte nicht so sein. Ich weiß jetzt leider nicht, ob das schon lange der Fall war oder erst vor drei Tagen angefangen hat. Störungen bei Vodafone gibt es ja mal aber die dauern normalerweise auch nicht sooo lange
Mir scheint das eher ein verdecktes Problem zu sein was sich bisher nicht geäußert hat. Schon komisch da ich ja sogar im Routing über die Vodafone Leitung raus gehe, muss ich mal schauen was passiert wenn ich über unseren lokalen ISP gehe. Werde ich auch mal testen sobald ich mal Abends meine Ruhe habe^^
Das erklärt auch nicht die Probleme mit der eshare-URL, die ja nicht bei Vodafone liegt. Und die hat definitiv vor ~1 Monat funktioniert.
Ich werde berichten, wenn ich alles nochmal nachgestellt habe. Aktuell geht alles durch die DNS Weiterleitung auf Quad9.
Mir scheint das eher ein verdecktes Problem zu sein was sich bisher nicht geäußert hat. Schon komisch da ich ja sogar im Routing über die Vodafone Leitung raus gehe, muss ich mal schauen was passiert wenn ich über unseren lokalen ISP gehe. Werde ich auch mal testen sobald ich mal Abends meine Ruhe habe^^
Das erklärt auch nicht die Probleme mit der eshare-URL, die ja nicht bei Vodafone liegt. Und die hat definitiv vor ~1 Monat funktioniert.
Ich werde berichten, wenn ich alles nochmal nachgestellt habe. Aktuell geht alles durch die DNS Weiterleitung auf Quad9.
Das erklärt auch nicht die Probleme mit der eshare-URL, die ja nicht bei Vodafone liegt. Und die hat definitiv vor ~1 Monat funktioniert.
Naja, wenn du die Domain (und damit auch alle Subdomains) nicht mehr auflösen kannst, erklärt es das doch ganz gut
