fritz.box funktioniert nicht über WLAN

Wenn man halt irgendwelche Tools einsetzt die anonymisieren oder ähnliches, kann es schon vorkommen dass Routing oder DNS verändert wird.

In der Hilfe beschreibt Avast es auch https://www.avast.com/de-de/faq.php?article=AVKB44#idt_409

Sicheres DNS bietet eine verschlüsselte Verbindung zwischen Ihrem Web-Browser und Avasts eigenem DNS-Server, um eine Fälschung dieser Adressübersetzung auszuschließen.

Zum Vergrößern anklicken....

Kannst ja sonst schauen ob es eine Ausnahme gibt, wo fritz.box eintragen kannst.

Selbe Problem wäre, wenn DNS von Google manuell einträgst in WLAN Konfig.

Gute Frage, wir wissen ja nicht wann was aktiviert hast, oder es kürzlich durch ein Update gab.

Klingt fast wie das in http://www.ip-phone-forum.de/showthread.php?t=288655 genannte Problem ;-)

Antwortet ein nslookup/dig auf die Namensabfrage mit 127.0.53.53?

Hatte das Problem ebenfalls - nicht nur bei Wlan.

Ursache war eine von mir nicht vorgenommene Änderung an den Einstellungen der Netzwerkverbindungen unter Windows. Der automatische Bezug der DNS Serveradresse im IPv4 wurde ohne mein Wissen deaktiviert; dafür fand sich der Google DNS Server als bevorzugter DNS Server. Sobald ich es wieder auf automatisch zurückgestellt hatte, funktionierte es problemlos.

Ich verwende weder Anonymisierungs Tools, noch andere Programme, die Proxys o.ä. verwenden. Letztlich habe ich nicht weiter gesucht und bislang ist es auch nicht wieder aufgetreten.

Das Problem habe ich auch. Ein bischen Suche hat ergeben, das es seit dem 12.11. (wo die Probleme anfingen) eine neue TLD namens .box gibt. Und das kollidiert dann bei der Namensauflösung mit z.B. server(.fritz.box) Ich hoffe, das AVM beim nächsten Update ihr internes 'fritz.box' gegen etwas neutrales tauscht. Bis dahin gib es als Workaround nur, den Namen mit einem Punkt zu versehen, z.B. 'server.' Dann klappt es wieder.

kARMU schrieb:

Ich hoffe, das AVM beim nächsten Update ihr internes 'fritz.box' gegen etwas neutrales tauscht.

Zum Vergrößern anklicken....

Na hoffentlich nicht ... das macht nämlich so ziemlich jeden hier zu findenden Beitrag mit Links auf die eigene Box falsch - von Handbüchern und der AVM-KB mal ganz zu schweigen.

Wenn der AVM-DNS im multid tatsächlich einen Fehler haben sollte und er seine eigene Konfiguration (wo er die entscheidende Autorität für die Domain "fritz.box." sein sollte) ignoriert, dann wäre dieser auszubügeln und gut ist's.

Ansonsten ist zwar die Domain "fritz.box." im Internet dann nicht problemlos von einem Client hinter der FRITZ!Box zu erreichen - aber das wäre sicherlich das deutlich kleinere Übel.

Bei korrekter Arbeitsweise des Forwarders/Servers/Proxy (nenn' es wie Du willst) in der Box, sollte keine Abfrage an die TLD "box" gehen, die in der zweiten Ebene "fritz" enthält. Dafür ist der "multid" selbst SOA und solange da keine "delegation" hinterlegt ist, braucht man da auch niemand anderen zu fragen, wenn es um weitere "prefix"-Angaben geht. Eine solche "delegation" setzt die Existenz eines NS-Eintrags für die delegierte Subdomain voraus (und einen Host-Eintrag für den spezifizierten Nameserver oder entsprechenden "glue").

Es könnte allerdings eine Erklärung geben, warum das dann doch schiefgeht - ist aber nur Theorie. Wenn nämlich ein Client mit Proxy-Autodiscovery nach "wpad.box" sucht, kriegt er ggf. auch noch die Info für den SOA der TLD geliefert und wenn der FRITZ!Box-DNS dann wirklich schön in der Hierachie im DNS erst einmal diesen befragt nach der Adresse "fritz.box", bevor er in die eigene Konfiguration sieht, dann wäre das auch zu erklären, warum der Unsinn erzählt.

http://www.heise.de/newsticker/meld...ringt-manche-Netze-durcheinander-3491185.html

liefert eine "Lösung"

An den Namen der F!B noch einen Punkt hängen. also nicht fritz.box, sondern fritz.box.
(Mist, den Punkt sieht man fast nicht ;-)

Nun, es ist ja (bei mir) nicht der Aufruf der FB selber, das klappt.
Schlimmer ist, das der Zugiff auf diverse Linux-basierende Clients gestört ist (zu Win-PCs klappt nach wie vor). Um auf meinen VDR zu kommen reicht halt nicht mehr ein "http://vdr:8008", ich muss halt noch den Punkt anhängen "vdr.:8008".
Klingt erstmal nicht dramatisch, aber bei vielen Rechnern mit noch mehr Scripten/Batchdateien artet die Umstellung in Arbeit aus

Hast Du evtl. eine bessere Lösung?

Was mir noch aufgefallen ist...
Dieses neuerliche 'Fehl'verhalten haben nicht alle PC, bis jetzt:
ALLE Linux-Rechner lösen den Namen richtig auf.
Bei den Win-Rechenern arbeiten einige richtig, andere nicht mehr.
Starte ich die im abgesicherten Modus, klappt es auch wieder nach der alten Methode.

Kann mir DAS jemand erklären? Danke!

Da muss doch Windows ein Problem mit haben, seit der Umstellung ?!?!?