Alternative IPv4/IPv6 DNS Server für DSL und LTE
-
-
-
Hallo Leute ...
Nach erneuten Test mit netalyzr ==> netalyzr.icsi.berkeley.edu/l=de gibt es offenbar erneut Schwierigkeiten mit den Telekom DNS.
•Bei der Suche nach wichtigen Namen haben wir unerwartete und möglicherweise gefährliche Ergebnisse empfangen:
"Ein beliebter Name weist eine mittelschwere Anomalie auf: Wir können keinen Reversenamen finden, der der vom DNS-Server Ihres Internetdienstanbieters bereitgestellten IP-Adresse zugeordnet ist. Wir hatten jedoch erwartet, einen Namen zu finden. Dies ist höchstwahrscheinlich auf einen langsamen DNS-Server zurückzuführen. Wenn Sie Netalyzr erneut ausführen und sich nichts an der Situation ändert, könnte dies an einer Fehlkonfiguration seitens des Domainbesitzers liegen. Vielleicht ist aber auch Ihr DNS-Server falsch konfiguriert oder er ermöglicht einen Man-In-The-Middle-Angriff."
Obwohl im kaskadierten Router alternative DNS eingetragen sind, schleichen sich die Telekom DNS scheinbar immer wieder durch, keine Ahnung weshalb. Muss ich, um den Telekom DNS nun endgültig den gar auszumachen resolv.conf & serverinfo editieren oder nur Letztere?
Hatte mir das folgendermaßen vorgestellt:
Was meint ihr?
Falls jemand ebenfalls mit netalyzr testen würde wäre es schon interessant, da ja alle hier Telekom Kunden sind.
-
eclp schrieb:
Falls jemand ebenfalls mit netalyzr testen würde wäre es schon interessant, da ja alle hier Telekom Kunden sind.
ich habe den test mit dem handy gemacht da ich auf dem pc kein java installiert habe
ich poste einfach mal den link zum ergebniss
n1.netalyzr.icsi.berkeley.edu/…-47de-8b9b#dns_properties -
-
eclp schrieb:
Nutzt du ein Android-Device?
ja
eclp schrieb:
Wenn ja, sind dort nicht uneditierbare Google Proxy hinterlegt? So dem so wäre, würde dein Test nur bedingt aussagekräftig was die Telekom DNS betrifft.
nein da ich cyanogenmod verwende (rooted) und einen eigenen proxy am laufen habe (für yt und wilmaa im localen netzwerk der auch über den sph dns auflöst) -
Hab' grad' mal den Test gemacht: hab' auch die Warnung bekommen - allerdings nur für 2 Domains.
Beim zweiten Test hatte ich nur noch eine Warnung...
Schätze also, die Datenbank macht gerade ein Update.
(letzte Nacht war auch eine Wartung am HAAP -- die basteln grad')
Seltsam allerdings: hab' den Test auch mal mit Google-DNS gemacht... auch da gab's Warnungen...
mfg, emkay -
Hier mal meine Testergebnisse: netalyzr.icsi.berkeley.edu/res…9-07ef9b61-ff9a-4832-981b
-
bei mir is es meist yahoo und comcast...
könnte also auch ein Problem bei den Domains selbst sein.
(interessant ist: eigentlich werden da in erster Linie Domains getestet, welche für US-Bürger interessant sind)
EDIT: im Moment würd' ich aber auf zu langsames Antworten tippen - so wie es auch der netalyzr vermutet. -
Moin Leutz!
Hab' nochmal ein paar Folge-Tests gemacht:
Problematisch sind bei mir immer die selben 3: att, yahoo, comcast
Meist wird einer oder mehrere davon angemahnt....
Jetzt das Lustige: auch mit den Google-DNS-Servern...
Ist also wohl kein Telekom-Problem, sondern liegt entweder wirklich an den Domains oder der netalyzr hat gerade Probleme.
mfg, emkay -
-
-
-
@heugabel: immerhin hat jetzt der Telekom-DNS selbst wieder einen Reverse-Eintrag...
Den Wildcard-Fehler, also das der DNS IPs für erfundene/nicht existierende Domains liefert - den kannst Du abstellen.
Das ist eine Einstellung deines Anschlusses - komm' nur gerade nicht drauf. wo die sich versteckt... (irgendwo in der Kommandozentrale)
Das sind die Vorschläge, die die Telekom schickt, wenn man sich vertippt...
Die Art der Vorschläge verstößt eigentlich gegen die Regel, das bei einer falschen URL eine Fehlermeldung zurück gegeben werden muß.
Sonst sind's ja auch bei Dir wieder yahoo und comcast.
Verdichtet sich also auf Domain-Fehler -- oder die Telekom hat wirklich ein Problem bei diesen 3 Domains.
mfg, emkay -
eMKay77 schrieb:
Verdichtet sich also auf Domain-Fehler -- oder die Telekom hat wirklich ein Problem bei diesen 3 Domains.
ich denke nicht dass die telekom da einen fehler hat
Quellcode
-
- root@bananapi:~# dig mail.yahoo.com @192.168.2.1
- ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> mail.yahoo.com @192.168.2.1
- ;; global options: +cmd
- ;; Got answer:
- ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24828
- ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
- ;; QUESTION SECTION:
- ;mail.yahoo.com. IN A
- ;; ANSWER SECTION:
- mail.yahoo.com. 566 IN CNAME login.yahoo.com.
- login.yahoo.com. 31 IN CNAME fo-ds-ats.member.g02.yahoodns.net.
- fo-ds-ats.member.g02.yahoodns.net. 43 IN A 188.125.80.138
- ;; Query time: 2 msec
- ;; SERVER: 192.168.2.1#53(192.168.2.1)
- ;; WHEN: Wed Jun 22 11:32:11 CEST 2016
- ;; MSG SIZE rcvd: 115
- root@bananapi:~# dig -x 188.125.80.138 @192.168.2.1
- ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -x 188.125.80.138 @192.168.2.1
- ;; global options: +cmd
- ;; Got answer:
- ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2738
- ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
- ;; QUESTION SECTION:
- ;138.80.125.188.in-addr.arpa. IN PTR
- ;; ANSWER SECTION:
- 138.80.125.188.in-addr.arpa. 1800 IN PTR ats1.member.vip.ir2.yahoo.com.
- ;; Query time: 45 msec
- ;; SERVER: 192.168.2.1#53(192.168.2.1)
- ;; WHEN: Wed Jun 22 11:32:28 CEST 2016
- ;; MSG SIZE rcvd: 88
- root@bananapi:~#
einfach mal selber mittels dig die domains abfragen
ich denke eher dass der netalyzr da irgendein problem hat -
-
@danXde: jupp, war eine der ersten Sachen, die ich damals gemacht hab...
@Stricted: mit 'nslookup -C ... ' kann man die Reverse-Einträge prüfen - da waren ein paar gestern scheinbar wirklich im Argen.
ABER: da werden 100 Domains gecheckt...
Vielleicht sind die 'gewarnten' am Ende der Liste und ein DOS-Filter der Telekom greift mal etwas früher, mal etwas später... wär zumindest eine Erklärung.
Oder eben Server-Überlast (obwohl es dann wohl nich immer die selben treffen würde)
Läge der Fehler bei den Domains, dann wäre er ja nicht schwankend.
(aber wie oben erwähnt, auch mit 8.8.8.8/8.8.4.4 hatte ich Warnungen...)
Seltsamer Fehler...
mfg, emkay -
Moin Leutz!
Wollt gerade mal die DNS-Server tauschen...
Dummerweise ist /var/dns/serverinfo die falsche Datei ==> alle Dateien unter /var/dns außer resolv.conf werden erst beim ersten Aufruf der Login-Seite des SPHs erzeugt... sind also nur gecachte Werte für die WebUI.
Geht die Suche also weiter
mfg, emkay -
-
@Heiko: naja, das stimmt so nicht ganz - da sind auch die Arbeitskopien mancher Dateien, weil /etc ja read-only ist...
und @shell war ja weiter oben der Meinung, /var/dns/serverinfo wäre die richtige Datei
Aber mal schauen, probiere gerade per Formular-Einblendung ans Ziel zu kommen
mfg, emkay
EDIT: hab's jetzt endlich geschafft, den SPH komplett auf Google-DNS umzustellen... (per verstecktem Formular im Engineer-Menü)
Aber ratet mal: die 'bekannten' Domains zeigen auch dann Probleme an... dafür kann aber der Google-DNS sonst scheinbar mehr/fehlerfreier als der Telekom-DNS --> also lasse ich den jetzt erstmal aktiv
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „eMKay77“ ()
-
Teilen
- Facebook 0
- Twitter 0
- Google Plus 0
-
Reddit 0
-
Ähnliche Themen