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:

      Quellcode

      1. 1,ppp256,2001:1608:10:25::1c04:b12f
      2. 2,ppp256,2001:1608:10:25::9249:d69b
      3. 3,ppp256,84.200.69.80
      4. 4,ppp256,84.200.70.40
      5. 5,rmnet0,2001:1608:10:25::1c04:b12f
      6. 6,rmnet0,2001:1608:10:25::9249:d69b


      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:

      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
      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

      1. root@bananapi:~# dig mail.yahoo.com @192.168.2.1
      2. ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> mail.yahoo.com @192.168.2.1
      3. ;; global options: +cmd
      4. ;; Got answer:
      5. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24828
      6. ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
      7. ;; QUESTION SECTION:
      8. ;mail.yahoo.com. IN A
      9. ;; ANSWER SECTION:
      10. mail.yahoo.com. 566 IN CNAME login.yahoo.com.
      11. login.yahoo.com. 31 IN CNAME fo-ds-ats.member.g02.yahoodns.net.
      12. fo-ds-ats.member.g02.yahoodns.net. 43 IN A 188.125.80.138
      13. ;; Query time: 2 msec
      14. ;; SERVER: 192.168.2.1#53(192.168.2.1)
      15. ;; WHEN: Wed Jun 22 11:32:11 CEST 2016
      16. ;; MSG SIZE rcvd: 115
      17. root@bananapi:~# dig -x 188.125.80.138 @192.168.2.1
      18. ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -x 188.125.80.138 @192.168.2.1
      19. ;; global options: +cmd
      20. ;; Got answer:
      21. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2738
      22. ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
      23. ;; QUESTION SECTION:
      24. ;138.80.125.188.in-addr.arpa. IN PTR
      25. ;; ANSWER SECTION:
      26. 138.80.125.188.in-addr.arpa. 1800 IN PTR ats1.member.vip.ir2.yahoo.com.
      27. ;; Query time: 45 msec
      28. ;; SERVER: 192.168.2.1#53(192.168.2.1)
      29. ;; WHEN: Wed Jun 22 11:32:28 CEST 2016
      30. ;; MSG SIZE rcvd: 88
      31. 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
      @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 :D

      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“ ()