DNSv6-Server ULA = alles kaputt?

[失败是成功之母]

Lancom WLAN Access-Point (müsste aber auch die Business-Router betreffen) mit LCOS 10.42. Zurückgesetzt auf Werkseinstellungen. Ethernet-Kabel mit meinem DHCPv4-Server verbunden. Alles wunderbar. Access-Point wird wie „alle“ Geräte von Lancom automatisch zum DHCP-Client. Ich ermittele seine IPv4, und aktiviere über WEBconfig lediglich IPv6. Sonst nichts geändert. Neustart. Und schon war der Auto-Updater kaputt:

Auf Firmware-Update prüfen
Ein Fehler ist während der Überprüfung aufgetreten: DNS-Fehler

Allerdings passierte das erst nach einem Neustart! Also mit SSH verbunden:

ping -c1 update.lancom-systems.de
ping failed: address resolution failed

Also meinen DNSv6-Server angepingt:

ping failed: route to null

Die „Ursache“ ist:

Code: Alles auswählen

/Setup/IPv6/Router/Routing-Table
> l

Prefix                                       Rtg-tag  Peer-or-IPv6                                              Comment
======================================================--------------------------------------------------------------------------------------------------------------------------
fec0::/10                                    0        ::                                                        do not route site local addresses
fc00::/7                                     0        ::                                                        do not route ULAs according to RFC 4193                                                          

OK, mein DNSv6-Server ist nicht über eine global eindeutige Adresse sondern eine Unique-Local-Address (ULA) definiert (weil ich kein stabiles IPv6-Präfix erhalte bzw. macht die Konkurrenz AVM auch so von Haus aus). Zum Test, die letzte Regel gelöscht: DNS klappt, Auto-Updater klappt. Freu. Aber mir kommen zwei Fragen:

1. Müsste der über SLAAC/RDNSS gelernte DNS-Server jene Regel nicht automatisch überschreiben? Und, viel wichtiger:
2. Müsste der Lancom interne DNS-Resolver nicht automatisch auf IPv4 zurückfallen?

Bin ja froh, dass Letzteres nicht passiert. Sonst hätte ich dieses Problem wohl nie bemerkt. Aber auch wenn ich ping -4 wähle, nimmt mein Lancom den DNSv6. Oder habe ich allgemein einen Denkfehler … ULAs im INTRANET sind route-bar. Macht jene Regel bei einem Lancom als LAN-Client überhaupt irgendeinen Sinn; müsste ich was ganz anderes aus- bzw. umschalten?

Wäre spannend zu wissen, denn „jeder“ der hinter einer FRITZ!Box in seinem Lancom dieses IPv6 aktiviert, macht sich folglich seinen Auto-Updater kaputt. Nicht schön, denn dann gibt es nur manuell Security-Updates. Springt dann irgendeine LED auf rot, wenn der Auto-Updater kaputt ist?

[失败是成功之母]

2. Müsste der Lancom interne DNS-Resolver nicht automatisch auf IPv4 zurückfallen?

Auch wenn man an die Routen bereinigt, macht er das nicht.

1. Müsste der über SLAAC/RDNSS gelernte DNS-Server jene Regel nicht automatisch überschreiben?

Muss ich das jetzt wirklich über den Support eintüten?

[VX500]

Hallo in die Runde,

das irgendwas mit DNS + IPv6 nicht stimmt, habe ich auch. Regelmäßig versucht mein Lancom 1781 EW (V9.24.0474) Adressen krampfhaft über den DNSv6 aufzulösen. Manche Adressen sind aber wohl nicht über IPv6 erreichbar. Ich bekomme dann keine Verbindung. Davon ist sogar Portunity (Telefongesellschaft) betroffen, weswegen ich dort direkt die IPv4-Adresse für SIP nehme. Auch ein paar E-Mail IMAP-Server können scheinbar nur IPv4. Der LANCOM versucht zunächst vergeblich den IMAP-Server auszulösen. Auch bei dus.net (Telefongesellschaft) benutze ich den Zugang für SIP über IPv4, weil proxyV6.dus.net oft nicht aufgelöst werden/erreicht werden kann.

Kuriosum: nach einer gewissen Zeit (ca. 15 min) klappt es dann manchmal mit der DNS-Auflösung über IPv6.
Das war aber schon immer so. Ich finde den Fehler nicht.

Grüße
Sascha

[失败是成功之母]

Hast Du dazu, konkret zu dem Thema, einen eigenen Thread aufgemacht? Finde den in Deiner Historie nicht bzw. vielleicht Seiten-Symptome. Eine Auflösung über DNSv6 ist erstmal keinerlei Problem. Auch eine „krampfhafte“ Auflösung ist erstmal kein Problem, weil der DNSv6-Server ja vorhanden zu sein hat (er ist über RDNSS bzw. DHCPv6 gelernt und noch valide). Hier in diesem Thread geht es darum, dass der gelernte DNSv6-Server wegen einer falschen Default-Routen-Blockade nicht erreichbar ist. Und hier im dem Thread geht es darum, dass Lancom dann nicht auf DNSv4 zurückfällt.

Daher müsste man sich Deinen Fall in einem eigenen Thread mit einem Paket-Mitschnitt anschauen, z.B. welchen DNSv6-Server und welchen Adress-Typ dieser Server hat. Nach Deinen anderen Posts ist das der nachgelagerte Router hinter einem anderen Lancom Business Router. Und Du hast ein dynamisches globale IPv6-Präfix. Kann sein, dass der 1781EW einen DNSv6 in einem globalen Präfix gelernt hat. Bei einer Präfix-Änderung wird dieser DNSv6-Server dann nicht richtig invalidert. Diese Spekulation kannst Du testen, indem Du Deinem Haupt-Router eine ULA zuweist. Und ihn diese ULA dann als DNSv6 bewerben lässt. Du baust also nach, was AVM bei seinen FRITZ!Boxen macht. Wenn Du nicht gleich siehst, wie das geht, beschreibe ich das gerne in Deinem neuen eigenen Thread. Klappt hier nämlich ganz gut an einem dynamischen Präfix. Alternativ kannst Du auch direkt eine FRITZ!Box davorsetzen.

Allerdings musst Du aufpassen: Wir können in Deinem Fall nur Konfigurationsfehler lösen bzw. Workarounds für Funktionsbeschränkungen basteln; denn das Problem ist, dass sowohl LCOS 9.24 als auch Dein 1781EW schon lange End-of-Life und eigentlich nicht weiter zu verwenden sind. Ideal wäre, Du würdest Dir vorher noch einen 1781EW+ oder 1781VA in eBay schießen. Die kosten keine 60€ und Du kannst mit dem neusten LCOS mitspielen. Sollten wir auf einen Software-Bug stoßen, könnte man den dann sogar melden. Beim 1781EW+ hast Du das Problem, dass der kein LCOS 10.60 mehr bekommen wird aber Du hast den Vorteil, dass der kein DSL-Modem hat und somit einfacher als LAN-Client zu konfigurieren ist. Aber den 1781VA bekommst Du auch dorthin und der ist in eBay erheblich günstiger und der ist noch nicht einmal End-of-Sale, also noch lange bei LCOS dabei.

[backslash]

Hi VX500,

ein Rückfall der Auflösung von AAAA auf A erfolgt nur, wenn der DNS-Server auf die AAAA Anfrage ein SOA schickt. Schicht er hingegen eine norale Fehlermeldung (NoName), dann sagt der Server, daß er den NAMEN nicht kennt.- Dann macht es auch KEINEN Sinn, zu versuchen den NAMEN per A-Query aufzulösen.

Und wenn der DNS-Server deines Providers kein SOA schickt, dann ist das kein Problem des LANCOMs. Es gibt auch Provider, die verstümmelte SOAs schicken - das ist zwar genaugenommen auch kein Problem des LANCOMs, aber aktuelle Firmwaren reagieren auch darauf.

Und selbst, wenn es in deiner Uralt-Firmware einen Bug gibt, dann bist du jetzt stolzer Besitzer desselben...

Gruß
Backslash

[backslash]

Hi 失败是成功之母,

ja es ist so, daß der DNS-Forwarder für IPv6-DNS-Server den Router nutzt und dabei dann auf die Sperr-Route für die ULAs läuft. Diese Route dient dazu, zu verhindern, daß ULAs im Internet auftauchen - vergleichbar mit den Sperr-Routen für private Netze im IPv4-Router. OK, im IPv4-Router sind sie mitlerweile im Default abgeschaltet - im IPv6-Router fehlt dieser Schalter aber.

Prinzipiell müßte es auch möglich sein, daß der Forwarder, wie beim IPv4 am Router vorbei geht - es passiert momentan aber nicht, weil sonst die Inbound-Firewall die DNS-Antworten verwirft. Hier müßte es eine entprechende Änderung geben, die das löst. Im IPv4 die das kein Problem, weil es dort keine Inbound-Firewall gibt.

Das ändert aber nichts daran, daß der Forwarder nicht auf den IPv4-Server wechselt. Das funktioniert aber nicht mit einer einzelnen DNS-Anfrage... Der Forwarder wechselt den Server immer dann, wenn ein Client eine Anfrage wiederholt - denn das ist für ihn das einzige Zeichen, daß der Server nicht geantwortet hat (der Forwarder ist prinzipiell stateless). Hast du nun neben dem IPv4 DNS-Server zwei IPv6 DNS-Server zugewiesen, dann braucht es zwei Wiederholungen von DNS-Anfragen, damit der Forwarder auf den IPv4 DNS-Server wechselt. Nach 30 Minuten fällt der Forwarder dann wieder auf den esten Server zurück - d.h. dann braucht es wieder zwei Wiederholungen...

Gruß
Backslash

[失败是成功之母]

Ich vermute, dass VX500s Problem nicht die entfernten DNS-Einträge sind, sondern dass die Ursache der DNS-Server im Haupt-Router bzw. die Adresse für den DNS-Server im Unter-Router. Aber das sollte man sich genauer anschauen; auch wenn jene LCOS-Version bzw. das Produkt am Ende sind. Vielleicht kann jemand (sig) den Fehler dann nachbauen und mit noch unterstützen LCOS überprüfen.

Hier müßte es eine entsprechende Änderung geben, die das löst.

Wer stößt das an? Mache ich das durch ein Support-Ticket oder …

Der Forwarder wechselt den Server immer dann, wenn ein Client eine Anfrage wiederholt …

Also mein Client (Lancom Auto-Updater) macht oder triggert das schon mal nicht. Das war mein Problem. Ich habe einen Lancom 1781VA ohne irgendwelche Änderungen. Selbst den Internet-Assistent abgebrochen. Lediglich IPv6 aktiviert. Das war alles, was ich nach einem Factory-Reset konfiguriert hatte. Der Haupt-Router ist eine FRITZ!Box. Und Schwupps … bekomme ich wegen dieser Route und einem fehlenden Fallback auf IPv4 keine automatischen Software-Updates. Es hat lange gedauert, bis ich verstand, was hier los ist. Hätte ich irgendwo in einem Status (-Tool) sehen können, was hier schief ist? Übrigens: Nicht nur der Auto-Updater sondern auch der Voice Call Manager (VCM) ist betroffen.

Nochmal: Hatte ich im Lancom-Produkt IPv6 aktiviert und schaltet irgendjemand im Haupt-Router auf einmal DNSv6 auf ULA, dann ist der Lancom sowohl für automatische Updates als auch für Telefonie blockiert. Viel Spaß beim Debuggen. Vermutlich geht dann auch die Lancom Management Cloud (LMC) nicht. Aber das kann ich nicht testen. Wäre auch nicht „so“ schlimm, weil man das wenigstens „gleich“ sieht.

Diese Route dient dazu, zu verhindern, daß ULAs im Internet auftauchen …

Ihr bezieht Euch vermutlich auf RFC 4193 Abschnitt 4.1. Schön. Aber was ist hier „Internet“. On-Default ist ein Lancom 1781VA (jedenfalls war das so bis LCOS 10.3x; aber viele andere Lancom Produkte sind es weiterhin) ein LAN-Client. Folglich kann der IP-Router gar nicht entscheiden, was mit ULAs zu machen ist. Müsste diese Route/Regel nicht erst nach dem Internet-Assistent hinzugefügt werden? Oder müsste der IP-Router nicht erst nach dem Internet-Assistent aktiviert werden? Aber selbst dann, kann die falsch sein. Irgendwas ist hier auf jeden Fall krumm: Es kann nicht sein, dass eine valide Änderungen im Haupt-Router (den ich vielleicht gar nicht unter Kontrolle habe) mir auf einmal alle Apps in LCOS blockiert. Ich kann den Fehler nur melden. Wie das auf die interne Architektur zu transformieren ist, kann ich von Außen nur anregen.

[backslash]

Hi 失败是成功之母

Ich vermute, dass VX500s Problem nicht die entfernten DNS-Einträge sind, sondern dass die Ursache der DNS-Server im Haupt-Router bzw. die Adresse für den DNS-Server im Unter-Router

nein, sein Probem hat nichts mit deinem zu tun. Er hat definitiv ein Problem mit der Auflösung als solcher und nicht mit der Adresse des DNS-Servers: "Manche Adressen sind aber wohl nicht über IPv6 erreichbar. Ich bekomme dann keine Verbindung."

Wer stößt das an? Mache ich das durch ein Support-Ticket oder …

selbst dann würde das vermutlich in der Prio recht niedrig eingestuft - weil es nunmal seit über 10 Jahren so ist und bisher noch niemand ein Problem damit hatte...

Also mein Client (Lancom Auto-Updater) macht oder triggert das schon mal nicht

das macht normalerweise das Betriebssystem. wenn du z.B. von Wiondows aus einfach ein ping an einen DNS-Namen absetzt, dann sieht du, daß Windows mindestens einen Retry macht. und bei Linux läuft das genau so...
i.A. reicht es aus, daß irgend ein Client im LAN eine Wiederholung macht, damit auf den nächsten Server geschaltet wird. somit solte also im Fehlerfall sehr schnell die Auflösung wieder funktionieren.
Das Verhahren hat sich im den letzten 20 Jahren nicht geändert (sprich es war auch bei IPv4 onlöy so: wenn der ertste server nicht antwortet und ein Client die Anfrage wioederholt, wird der Server gewechselt)

aber viele andere Lancom Produkte sind es weiterhin ein LAN-Client. Folglich kann der IP-Router gar nicht entscheiden, was mit ULAs zu machen ist.

nein! I.A. sind LANCOMs Router und direkt mit dem Internet verbunden. Daß ein LANCOM-Router hinter einer Fritzbox hängt, ist eher unüblich - das gilt insbesondere für Router mit einem VDSL-Interface wie einem 1781VA
Und Accesspoints - die einzigen wirklichen "Clients" - sind normalerweise einfach Bridges, die somit gar nicht als DNS-Server dienen.

Gruß
Backslash

[失败是成功之母]

Er hat definitiv ein Problem mit der Auflösung als solcher …

Bin ich mir (noch) nicht sicher. Ich habe hier auch dus.net über IPv6 und solche Probleme nicht. Auch nutzt VX500 den IPv6-only Domain-Namen. Der hat überhaupt keinen A-Record. Aber wie geschildert, man müsste sich das genau anschauen. Es kann alles Unmögliche sein.

[VX500]

Guten Morgen,

ich hab für meinen DNSv6 Fall aus Langeweile weiter analysiert. Das Problem scheint im Ersten Router (Lancom 883) angesiedelt zu sein.
Da tauchen im Status unter IPv6/Firewall/Log-Tabelle reihenweise Einträge nach folgendem Schema auf:

Zeit Quelle Ziel Protokoll Zielport Filterregel Limit Aktion
25.05.2021 05:06:36 2003:d6:d724:XXXX::77 2003:180:2:4000::53 58 0 256 intruder detection 00000001 0 40000800


Die Quelle ist der Unterrouter (Lancom 1781 EW), das Ziel ist der DNSv6 Server der Deutschen Telekom.

Ferner werden auch Anfragen deren Ziel fe80::3 (ist die interne IPv6-Adresse des Hauptrouters) ist auf gleicher Art geblockt.
Warum blockiert die Firewall das? Ich habe da keine Regeln definiert, die das bewusst machen sollen.


Grüße
Sascha

[backslash]

Hi VX500,

Warum blockiert die Firewall das? Ich habe da keine Regeln definiert, die das bewusst machen sollen.

Die Firewall sagt dir doch, welche Regel zugeschlagen hat: "intruder detection". Das heißt i.A. daß die Route zur Quell-Adresse des Pakets nicht auf das Interface zeigt, über das das Paket empfangen wurde - sprich: die Route zum Netz 2003:d6:d724:XXXX zeigt nicht dahin, woher die Anfrage kam...

Du kannst dir aber eine Mail von der Firewall schicken lassen - dann steht dann genau drin, welshalb die Anfrage abgelehnt wurde

Gruß
Backslash

[VX500]

Danke backslash für den Tipp. Ich muss mir das mal in Ruhe anschauen. In beiden Routern gibt es nur eine WAN-Gegenstelle: INTERNET. Die Route dafür wurde vom Lancom-Assistenten jeweils bei Ersteinrichtung der Router automatisch erzeugt.

Der erste Router (Lancom 883) hat das eingebaute VDSL-Modem aktiv und hängt an einem Telekom VDSL-Anschluss.
Der zweite Router (1781EW) hängt dahinter. Der 1781EW hat ja einen separaten Fast-Ethernet WAN-Anschluss. Der wird auch genutzt.

Bei einer tracert Abfrage zu einem beliebigen externen Host sieht man auch das es durch diese beiden Router ins Internet geht.

Grüße
Sascha

[backslash]

Hi 失败是成功之母,

nochmal zum eigentlichen Thema...

zusammen mit dem DPS wurde auch der fehlende Part in der IPv6-Firewall implementiert, so daß der DNS-Forwarder im IPv6 jetzt tatsächlich auch am Router "vorbei" laufen kann. Ich hab das mal für die nächets 10.50 (>= 10.50.0109) eingebaut. Damit sollten es dann auch mit den ULA-Sperr-Routen funktionieren...

Gruß
Backslash

[失败是成功之母]

Ein Problem in der Erwachsen-Bildung ist, zu erkennen, ob der zu Schulende lernwillig und/oder lernfähig ist. Und warum sollte ich überhaupt jemanden nachschulen, obwohl ich nicht dafür entlohnt werde? Support bzw. Produkt-Unterstützung bedeutet immer, dass man die Anregungen des Kunden intern transformieren muss. Das ist ein wenig Arbeit. Aber einen Kunden mit seinem Anliegen niederknüppeln, geht für jemanden der Außenwirkung hat, gar nicht.

[Der Forwarder wechselt den Server immer dann, wenn ein Client eine Anfrage wiederholt …] macht normalerweise das Betriebssystem.

Mein Betriebssystem LCOS macht diese Wiederholung offenbar nicht. Jedenfalls kommt der Auto-Updater in LCOS nicht ins Internet auch wenn das Lancom-Produkt sowohl IPv6 als auch IPv4-Connectivity hat. Bietet der übergeordnete Internet-Router seinen DNS-Server als ULA, dann blockiert „jene Regel“ das LCOS förmlich.

wenn du […] von Windows aus einfach ein ping an einen DNS-Namen absetzt, dann sieht du, daß Windows mindestens einen Retry macht

Ich habe Windows 10 hinter einem Lancom-Router. Im Test-Aufbau ist Windows 10 ist nur per IPv4 verbunden. Der Lancom-Router hat sowohl IPv6- als auch IPv4-Connectivity zu seinem Internet-Router. Windows 10 kann nicht surfen. Der Lancom-Router leitet die DNS-Anfragen des Windows 10 immer wieder an die ULA des Internet-Router. Und diese Route ist mit „jener Regel“ geblockt.

… wechselt … Betriebssystem … Retry

Meinst Du einen Fallback-Mechanismus von IPv6 auf IPv4 ala Happy-Eyeballs? Kann nicht sein. Denn Du müsstest wissen, dass die IPv6-Connectivity auch dann zu funktionieren hat, wenn die Internet-App bzw. deren Host-Betriebssystem kein Happy-Eyeballs bietet. Jene Fallback-Mechanismen sind dazu da, Defekte unsichtbar zu machen. Fallbacks sind nicht dazu da, damit Defekte zu verharmlosen.

Accesspoints sind […] einfach Bridges, die somit gar nicht als DNS-Server dienen.

Die Lancom Access-Points haben mehrere Apps an Bord: Auto-Updater, NTP-Client und so weiter. Diese Apps kommen nicht mehr ins Internet, wenn als DNS-Server eine ULA zugewiesen wurde. Der auf dem Access-Point lokale DNS-Proxy ist blockiert auch dann, wenn nicht nur IPv6 sondern auch IPv4-Connectivity vorliegt.

Daß ein LANCOM-Router hinter einer Fritzbox hängt, ist eher unüblich

Reingefallen.
Bei mir ist der Internet-Router gar keine FRITZ!Box sondern auch ein Lancom. Allerdings habe ich meinen Lancom so konfiguriert, dass er sich selbst mit seiner ULA als DNS-Server bewirbt (mittels SLAAC-RDNSS und DHCPv6-Option). Genau wie das AVM FRITZ!OS (und viele andere CPEs es) von Haus aus machen. Ich musste nur darauf achten, dass der Lancom seine ULA auch als Loopback-Adresse kennt.

Eine global-eindeutige Adresse (GUA) geht nicht, weil ich kein festes IPv6-Präfix habe. Ja, ich hätte den Standardwert mit dem Doppelpunkt, also der Link-Local-Address (LLA) lassen können. Aber ich habe mich (wie AVM und andere CPE-Hersteller) für eine ULA entschieden. Eine valide Adresse für einen DNS-Server.

bisher noch niemand ein Problem damit hatte

Wäre ja noch schöner, wenn dieser Fehler schon bekannt, dessen Ursache schon analysiert und verstanden aber noch immer nicht behoben wurde. Solch einem Argument kann ich auch ganz anders begegnen: Einige von Euch sind der Meinung, dass 90+% Eurer Kunden nicht so schlau sind, wie Ihr. Also glaubst Du wirklich, dass in den zehn Jahren jemand das soweit analysiert hätte?

irgend ein Client im LAN [macht] eine Wiederholung, damit auf den nächsten Server geschaltet wird

Ich dachte der DNS-Forwarder wäre „prinzipiell stateless“. Nehmen wir mal an, das fällt unter die Ausnahmen, die sich hinter dem Wort „prinzipiell“ verstecken. Bei mir passiert das nicht – siehe mein Beispiel mit Windows 10. Alle Hosts hinter diesem Lancom-Router sind ebenfalls tot.

der DNS-Forwarder [läuft ab LCOS 10.50.0109] tatsächlich auch am Router "vorbei" […] damit sollten es dann auch mit den ULA-Sperr-Routen funktionieren.

Verstanden? Nein! Warum muss ich jetzt nachschulen?
Das Problem mit jener ULA-Regel hast Du nicht nur bei DNS sondern auch bei anderen Anwendungen. Beispiel: NTP. Mein Haupt-Router bewirbt sich als NTP-Server – ebenfalls mit seiner ULA. Ja, solche DHCPv6-Optionen liest das aktuelle LCOS (jedenfalls nach meinen Tests noch) nicht aus. Aber angenommen in ein paar Jahren implementiert jemand die DHCPv6-Option 56 (RFC 5908). Dann bekommt LCOS keine Uhrzeit und der Auto-Updater geht wieder nicht, weil das TLS-Zertifikat noch nicht gültig ist. Übrigens: Ich wollte meinen NTP-Server fest in LCOS eintragen, als ULA, und bin tatsächlich auch hier auf die Nase gefallen.

Das Problem ist jene ULA-Regel. Sie ist teilweise richtig und teilweise falsch. Das IETF will lediglich, dass ich meine ULA (und damit meine MAC) eines Host-Computers nicht ins Internet posaune. Aber ich darf sehr wohl mit meiner global gültigen IPv6-Adresse jede ULA kontaktieren. Aber in LCOS verbietet jene ULA-Regel beides. Die Regel ist so falsch.

der DNS-Forwarder [läuft ab LCOS 10.50 RC1] tatsächlich auch am Router "vorbei" […] damit sollten es dann auch mit den ULA-Sperr-Routen funktionieren.

Schön, nur geht es selbst für DNS immer noch nicht. Zwar sehe ich jetzt [getestet LCOS 10.50 RC3], dass meine Lancom Access-Points tatsächlich auch das Software-Update über DNS starten, ihren Lancom WLC suchen und so weiter. Aber wenn eine DNS-Antwort eintrudelt, dann wird diese mit einer ICMPv6-Nachricht zurückgewiesen – udp/53 sei „Destination unreachable“ bzw. „Port unreachable“. Erst wenn ich jene ULA-Regel lösche, wird die DNS-Antwort akzeptiert. Und erst dann klappt auch der Auto-Updater.

das Ziel ist der DNSv6 Server der Deutschen Telekom […] Ziel fe80::3 (ist die interne IPv6-Adresse des Hauptrouters) ist auf gleicher Art geblockt.

Bist Du weiter gekommen? Welcher Adresstyp ist denn die Quelle? Die Frage ist auch, warum das bei Dir nicht dauerhaft sondern nur manchmal passiert. Ich kann nur sagen, dass ich hier weder eine globale (GUA) noch eine link-lokale Adresse (LLA) nutze. Stattdessen kommt bei mir eine ULA als DNS-Server zum Einsatz (sowohl im Haupt-Router als auch im dahinter geschalteten Router).

[backslash]

das ist jetzt einfach nur noch unverschämt!

ich werde darauf nicht mehr antworten! fühle dich auf die Block-Liste gesetzt!

Ende der Kommunikation