Beides lässt sich über Suchmaschinen und die Suchbegriffe „ncbi blast“ finden. Nur führt bei uns der Klick auf den Eintrag zu „Seite nicht gefunden“ - meistens, nicht immer. Manachmal kommt die Startseite von ncbi, aber die blast-Seite nicht, manchmal auch umgekehrt, manchmal kann man sogar ein paar Aktionen unter Blast ausführen, beim nächsten Versuch eine Minute später geht es aber nicht mehr. Mit Firefox geht es gefühlt einen Hauch weniger unzuverlässig wie mit Chromium, aber damit arbeiten ist unmöglich.
Andere Webseiten funktionieren ohne Probleme.
Wir haben keine Proxy-Sperrlisten o.ä., es tut auch an Rechnern nicht, die in der noproxy-Group sind. Allerdings funktioniert es im WLAN!
Ich verstehe dabei vor allem nicht, warum es manchmal (selten) tut…
ich vermute, daß das mit dem Resolver und evtl. IPv6 zusammenhängt. Evtl. ist der Webserver der Domain nicht immer, oder unzuverlässig über IPv6 zu erreichen.
Im WLAN verwendest Du evtl. einen anderen Resolver, bzw. ist IPv6 nicht aktiv.
Ich bin nicht wirklich weitergekommen. Ich verwende die V7 mit OPNSense, hier läuft der Verkehr des WLAN auf einer eigenen Schnittstelle ein und über die LAN-Schnittstelle raus (ohne Firewall-Regeln) zum Belwü-Modem. Die EInstellungen für die LAN-Schnittstelle nach draußen unterscheiden sich also nicht zwischen dem pädagogischen Netz und dem WLAN - bis auf die Firewall, die im Pädnetz natürlich aktiv ist. Da dürfte es nach meinem Verständnis also keinen unterschiedlichen Resolver geben. Oder wie könnte ich das rausbekommen?
ich meine mich zu erinnern, dass NCBI da eine Art DoS-Schutz eingebaut hat und wenn innerhalb kurzer Zeit zu viele Abfragen von einer IP kommen, diese für einige Zeit blockiert wird.Vermutlich hängt das damit zusammen!?
Welcher Nameserver verwendet wird, bekommst Du mit einem Linux PC raus:
dig -t AAAA blast.ncbi.nlm.nih.gov
Bei dem Kommando siehst Du in der Antwort auch, welcher Nameserver verwendet wird. Wenn Du mit WLAN verbunden bist, und meine Theorie stimmt, dann dürfte hier keine IPv6 Adresse geliefert werden.
das „dig +trace“ dürfte hier keine Erleuchtung bringen, denn dann arbeitet dig selbst als rekursiver Resolver und umgeht den Resolver, den das System normalerweise verwendet. So kann man eigentlich (im Wesentlichen) nur testen, ob Port 53 nach außen offen ist.
Bei mir wird der Name übrigens so aufgelöst:
blast.ncbi.nlm.nih.gov. 43200 IN CNAME blast.wip.ncbi.nlm.nih.gov.
blast.wip.ncbi.nlm.nih.gov. 29 IN AAAA 2607:f220:41e:4290::110
Das wip kommt also vom CNAME.
Wichtig wäre zu klären, welche Resolver in den jeweiligen Netzen verwendet werden und weshalb der eine den Namen nicht richtig auflöst. Du hast in der Antwort „Server 127.0.0.1“ stehen, das heißt, das ist ein lokal laufender Resolver. Der macht aber normalerweise nichts anderes, als einen vorgelagerten Resolver zu kontaktieren (wird in der Netzwerkkonfigurationals oft als „der“ DNS-Server bezeichnet). Welcher das ist, findet man unter Linux mit einem der beiden folgenden Befehle heraus:
cat /run/systemd/resolve/resolv.conf
nmcli device show eth0
(Beim zweiten den Gerätenamen eth0 entsprechend der Ausgabe von ip a anpassen).
Wenn Du weißt, welche Resolver/DNS-Server in den beiden Netzen verwendet werden, sehen wir weiter.
bin im Homeoffice und habe von hier aus nur auf das Pädnetz und nicht aufs WLAN Zugriff.
Das dig +trace führt in der Tat zu keinem verwertbaren Ergebnis:
;; received 51 bytes from 127.0.0.53#53(127.0.0.53) in 4 ms
Der Client verweist in der resolv.conf auf den lmn-Server 10.0.0.1
Der Server verwendet netplan, nicht den network-manager, in der /etc/netplan/01-netcfg.yaml stehen als Nameserver der 10.0.0.1 selbst sowie der 10.0.0.254, also der OPNSense drin.
Der OPNSense hat unter System-Einstellungen-Allgemein den 10.0.0.1 sowie den 129.143.4.3 drinstehen, beide bei „Verwende Gateway“ auf „keiner“.
Wenn ich auf dem OPNSense unter Schnittstellen-Diagnose-DNS-Abfrage ncbi.nlm.nih.gov eingebe, zeigt er gar nichts an, wenn ich heise.de eingebe, gibt er mir folgendes zurück:
Rückmeldung A 193.99.144.80
|Auflösungszeit pro Server||Server|Abfragezeit|
| — | — |
|127.0.0.1|0 msec|
|10.0.0.1|1 msec|
|129.143.4.3|3 msec||
OPNSense, den Haken raus:
System - Einstellungen - Allgemein - DNS-Server Einstellungen - [ ] Do not use the local DNS service as a nameserver for this system
Ebenso könntest Du die anderen Einstellungen evtl. korrigieren:
System - Einstellungen - Allgemein - DNS-Server: Hier nur 10.0.0.1 rein, alles andere raus.
Hm, dann hat der OPNSense doch gar keinen DNS-Server, der ihm die externen Adressen auflösen würde?! Das probier ich lieber erst am Sonntag in der Schule, heute abend und morgen ist Unterricht in der Weiterbildung und wenn ich mich hier aussperre, muss ich durch den Schneeschauer draußen in die Schule radeln…
Ich dachte schon, weil Du oben bei Deinem OPNsense Test die Antwort hattest:
Da ist eben die 127.0.0.1 drinnen.
Bei mir wird bei der OPNsense Diagnose „Schnittstellen: Diagnose: DNS-Abfrage“ nur 10.0.0.1 gefragt.
Auf der OPNsense ist der Unbound DNS aktiv, welcher das erledigt.
Also die OPNSense fragt den Server um auch lokale Adressen auflösen zu können. Der Server hat als Forwarder in der smb.conf die OPNSense drinnen, welche via Unbound DNS die externen Adressen auflöst.
OK, ich hab’s jetzt auf deine Verantwortung mal ausprobiert, hat nur leider kaum was verändert.
Ich habe den Haken gesetzt und im Client die Seite aufgerufen - immerhin hat sich was verändert: Statt der Firefox-Seite „Verbindung fehlgeschlagen“ kam manchmal (!) eine OPNSense-Seite „kein DNS-Eintrag“.
Ich habe zusätzlich 129.143.4.3 rausgenommen, sodass in der Liste nur noch die 10.0.0.1 stand, keine Änderung.
Ich habe beides wieder zurückgesetzt, Hoppla, die ncbi-Seite wird aufgerufen, aber nach ein paar Klicks: Wieder Seite nicht gefunden, auch in der History zurück hilft nicht. Irgendwie hat er’s kurz - und dann wieder nicht.
auf meinem Testsystem ist bei der OPNsense unter System → Einstellungen → Allgemein überhaupt kein DNS eingetragen. Der Haken bei " Allow DNS server list to be overridden by DHCP" ist gesetzt, bei „Do not use the local DNS …“ ist kein Haken. Damit tut es bei mir.
Dass man hier 10.0.0.1 einträgt, erscheint mir unlogisch, denn damit hätte man ja einen Loop.
Hilfreich wäre eventuell noch, welchen DNS die OPNsense als Forwarder nutzt. Das findet man bei der OPNsense mit „cat /etc/resolv.conf“ heraus.
mal ausprobiert, hat nur leider kaum was verändert.