Forum: PC Hard- und Software FF83 findet lokalen Server nicht (mehr)


von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Moin,

heute habe ich auf FF 83 "geupdatet", seitdem funktionieren
meine lokalen Webseiten nicht meht. FF meint, "Die Verbindung
mit dem Server www.server.com schlug fehl.".

Unmittelbar vorher funktionierte nach noch alles.

Ich rufe die Seite mit zB
"<a target="blank" ref="http://server/rb">MurxVonMarx";
auf.

Bisher probiert:

network.dns.disablePrefetch auf true

Mit IE funktioniert alles. Übers Web lassen sich die nach außen
freigegeben Seiten aufrufen, der Indianer dürfte daher unschuldig
sein, in den Logfiles ist schlicht nichts ...

Bein Aufruf fügt der FF anscheinend ein ".com" an den
Servernamen und findet den dann natürlich nicht. Davor
schreibt er "www.". Ich kann mich nicht dran erinnern, daß
das vorher schon war.

Wie komme ich da weiter ? Was haben die da wieder geändert ?

Hausintern habe ich kein https, wozu auch ...

(es heißt natürlich href, nicht ref. Forum meint, das sei Spam,
das /a mag es auch nicht)

: Bearbeitet durch User
Beitrag #6479899 wurde vom Autor gelöscht.
von (prx) A. K. (prx)


Lesenswert?

Joachim D. schrieb:
> "<a target="blank" ref="http://server/rb">MurxVonMarx";;

- Lass dir eine lokale Domain einfallen, damit das nach einem DNS-Namen 
aussieht. Bei Fritzens ist fritz.box voreingestellt.

- Stell sicher, dass FF kein DNS-over-HTTPS verwendet.

- Notfalls schreibst du den Namen in die Hosts Datei rein: 
\windows\system32\drivers\etc\hosts

: Bearbeitet durch User
von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Vielen herzlichen Dank !

Ich habe Servername und IP in C:\Windows\System32\drivers\etc\hosts
eingetragen und er findet das wieder, alles ok !

von Rolf M. (rmagnus)


Lesenswert?

(prx) A. K. schrieb:
> Joachim D. schrieb:
>> "<a target="blank" ref="http://server/rb">MurxVonMarx";;;
>
> - Lass dir eine lokale Domain einfallen, damit das nach einem DNS-Namen
> aussieht. Bei Fritzens ist fritz.box voreingestellt.

Oder einfach .local

> - Stell sicher, dass FF kein DNS-over-HTTPS verwendet.
>
> - Notfalls schreibst du den Namen in die Hosts Datei rein:
> \windows\system32\drivers\etc\hosts

Joachim D. schrieb:
> Bein Aufruf fügt der FF anscheinend ein ".com" an den
> Servernamen und findet den dann natürlich nicht. Davor
> schreibt er "www.". Ich kann mich nicht dran erinnern, daß
> das vorher schon war.

Doch, diesen Blödsinn macht er schon lange, aber eigentlich erst, 
nachdem er es so wie es eingegeben war erfolglos versucht hat. Wenn ich 
bei mir http://server eingebe, sucht er erwartungsgemäß eine Weile rum, 
ersetzt dann den Text im Eingabefeld durch www.server.com und meldet 
dann, dass er das nicht finden kann. Das regt mich schon läger auf. Wenn 
man da einen lokalen Namen eingibt, aber das Ziel gerade noch nicht 
verfügbar ist, muss man erstmal den von Firefox kaputtgemachten Text im 
Eingebefeld reparieren, bevor man es nochmal versuchen kann.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Tja, merkwürdig.

In der Fritte lauert ein DNS-Server, der PC kann auf den
Webserver zugreifen, sogar der Windows-Explorer.

Nur der FF kocht da sein eigenes Süppchen ;(

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Es ist nur eine Frage der Zeit, bis folgendes zum default wird: 
https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/

Das wird dann lustig. Dann muss man sich entweder Zuhause mit selbst 
signierten Zertifikaten herumschlagen, oder braucht ne richtige Domain 
mit richtigem Zertifikat.

Und wetten, dass danach bald darauf LetsEncrypt anfangen wird, für die 
Zertifikate Geld zu verlangen?

von Gerd E. (robberknight)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Es ist nur eine Frage der Zeit, bis folgendes zum default wird:
> 
https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/

Wenn Du Dir das genauer durchliest, wirst Du feststellen, daß Dich das 
nicht daran hindert, explizit HTTP-Seiten mit einer "http://..."-URL 
aufzurufen. Es wird ab dann nur versucht standardmäßig https zu 
verwenden und bringt bei http eine Warnung.

> Und wetten, dass danach bald darauf LetsEncrypt anfangen wird, für die
> Zertifikate Geld zu verlangen?

Genau, und die Echsenwesen übernehmen bald die Regierung.

Das Problem des TO hat nichts mit https oder Zertifikaten zu tun (oder 
Verschwörungen). Das Problem ist/war die Adressierung. Ich denke es 
fehlt ein Domainname, wie auch A.K. schon meinte. Man sollte die URL 
immer mit einem FQDN aufbauen, auch im lokalen Netz. Auf die Domain zu 
verzichten und zu hoffen, daß der Rechner implizit den richtigen 
Domainnamen ergänzt, ist ein Spiel mit dem Feuer.

: Bearbeitet durch User
von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Klar. Ich bewege mich in meinem LAN und brauche dazu eine
Domain. Das ist doch total abgedreht ;(

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Rolf M. schrieb:
> (prx) A. K. schrieb:
>> Joachim D. schrieb:
>>> "<a target="blank" ref="http://server/rb">MurxVonMarx";;;;
>>
>> - Lass dir eine lokale Domain einfallen, damit das nach einem DNS-Namen
>> aussieht. Bei Fritzens ist fritz.box voreingestellt.
>
> Oder einfach .local

Die korrekte Domain für lokale Netzwerke ist home.arpa. : 
https://tools.ietf.org/html/rfc8375

.local ist für lokales mdns (bonjour/avahi/etc.) reserviert. Man sollte 
es nicht als DNS domain für das lokale netz verwenden. Ausserdem war 
.local ursprünglich für link lokale Adressen gedacht: 
https://tools.ietf.org/html/rfc6762#section-3

von (prx) A. K. (prx)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Die korrekte Domain für lokale Netzwerke ist home.arpa. :
> https://tools.ietf.org/html/rfc8375

Nett. Jetzt müsste man nur noch eine Installation finden, die sich daran 
hält. Wobei ich beim darin referenzierten RFC7788 nicht sicher bin, ob 
das nicht die gleiche Kategorie fällt, wie der RFC1149.

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

(prx) A. K. schrieb:
> 🐧 DPA 🐧 schrieb:
>> Die korrekte Domain für lokale Netzwerke ist home.arpa. :
>> https://tools.ietf.org/html/rfc8375
>
> Nett. Jetzt müsste man nur noch eine Installation finden, die sich daran
> hält. Wobei ich beim darin referenzierten RFC7788 nicht sicher bin, ob
> das nicht die gleiche Kategorie fällt, wie der RFC1149.

Ich habe diese leider auch noch niemand anderen verwenden gesehen. Ein 
Schertz ist es aber nicht. Die Domain ist auch bei der IANA als special 
use domain vermerkt: 
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

Ausserdem braucht man die Domain zwingend, wenn man lokal auf dem PC 
DNSSEC prüft, und keine eigene Domain hat, aber trotzdem per DNS auf 
lokale Geräte zugreifen will. Zugegebenermassen scheint das auch keiner 
zu machen, wobei ich aber hoffe, dass sich das noch ändert, und sich 
DNSSEC und DANE vielleicht doch noch durchsetzen...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.