Die Verwendung des PiHole als Filter spricht ja nicht automatisch dagegen, die FRITZ!Box als Forwarder zu nutzen ... wobei ich nicht so richtig verstehe, warum die FRITZ!Box selbst auch über das PiHole gehen soll. Die macht ja eher keine unerwarteten DNS-Abfragen wg. irgendwelcher eingebetteten Werbung in HTML-Seiten oder ähnliches ... die "Ziele" ihrer selbstinitiierten Kommunikation im Internet sind einigermaßen vorbestimmt und da greift man entweder ein, indem man die abfragenden Dienste stilllegt oder man läßt es gänzlich sein - hier mit DNS-Spoofing zu arbeiten (auch ein "NXDOMAIN" ist ein solches Spoofing, wenn es aus dem Unterdrücken einer Anfrage stammt), ist eher gefährlich und (m.E. jedenfalls) unnütz. Da ist dann das Umbiegen des AVM-Netzes (212.42.244.0/24) über "dev lan" auch wieder erfolgversprechender als Blockade jedes Kontakts mit AVM bzw. zum Einschleusen eines Anderen als MITM-Proxy.
Das führte immerhin zu der Erkenntnis, dass für die 7590 der DNS-Server immer im WAN liegen muss.
Das finde ich nun wieder interessant ... wie kommst Du darauf? Wobei die Frage halt auch wäre, was hier die "statische Konfiguration" von Adressen ist, die Du meinst ... für die gesamten IPv6-Einstellungen oder nur für die DNS-Server? Das eine wäre bei "IPv6 -> Statische Einstellungen nutzen" und das andere unter "DNS-Server -> DNSv6-Server" - beides unterhalb von "Internet -> Zugangsdaten" (falls spätere Leser suchen sollten). Gab es bei Dir tatsächlich eine entsprechende Route zum DNS in der FRITZ!Box?
Vielleicht hatte ich auch nur das Glück, daß ich keine IPv4-Konfiguration für die kaskadierte Box hatte (die somit auch keine DNS-Abfragen über IPv4 machte) ... iirc steht z.B. in der "/etc/resolv.conf" bei AVM immer die "127.0.0.1" und nicht die "::1" als NS-Adresse.
Ich stand vor einer guten Woche vor der Aufgabenstellung, an einem M-net-Anschluß hinter einer 7430 vom Provider, die ihre Konfiguration per TR-069 auch von dort bezieht und nicht entfernt/zu sehr modifziert werden soll, damit der Provider im Support-Fall nicht einfach die Hände heben und sich für "nicht zuständig" erklären kann, eine Möglichkeit der Verbindung zu einem eigenen SIP-Server zu schaffen ... M-net läßt die Kunden keine eigenen SIP-Accounts zusätzlich zu den automatisch konfigurierten anlegen.
Das Ganze sollte dann ohne geänderte Firmware (also ohne Shell-Zugriff oder eigene Skripte - auch damit künftige Updates mitgemacht werden können) auskommen und glücklicherweise (in diesem Falle tatsächlich) stellt M-net den Kunden nur DS-Lite-Anschlüsse und damit natürlich auch einen AFTR bereit (IPv4 nur gegen den happigen Aufpreis von knapp 5 EUR/Monat oder beim "ganz großen Anschluß"). Die 7580 dahinter (eigentlich viel zu überdimensioniert und nur der Tatsache geschuldet, daß zum Zeitpunkt der Installation nur die 7590 und 7580 das neue FRITZ!OS 7 erhalten hatten) hat also gar keine IPv4-Konfiguration auf der WAN-Seite, die sie anstelle der IPv6-Abfrage des DNS benutzen könnte - sie ist auf "IPv6 only" und die Benutzung des AFTR von M-net konfiguriert.
Den DNS-Server lernt sie jetzt per RA (eben für die link-lokale fe80::/10-Adresse) von der 7430 (das war - neben den Einstellungen für "volles" DHCPv6 - die einzige wirklich relevante Änderung in der 7430) und dann kann sie ihn eben auch nutzen ... alles andere (statische vom Provider, keine RA) hat hier auch nicht funktioniert (zumindest nicht auf Anhieb und ohne Shell-Kommandos), weil die statischen Server (unter "DNS-Server" eingetragen) per RA überstimmt wurden ("showdslstat" zeigt an, woher der DNSv6-Server stammt - "dhcp" oder "ra") und die Box selbst keine Routen zu den DNS-Servern anlegte (wenn ich das jetzt nicht durcheinander bringe, das waren auch viele Versuche mit wechselnden Konfigurationen und Versionen und die 7390 mit 06.83 verhielt sich anders als die 7580 mit 07.00).
Damit konnte sie jedenfalls den DNS-Server nur erreichen, wenn die Standard-Routen dazu paßten ... und die Konfiguration der öffentlichen IPv6-Adresse der 7430 (natürlich der auf deren LAN-Seite) als DNS scheiterte daran, daß der IPv6-Präfix bei jeder Einwahl ein anderer ist und entsprechend getauscht werden müßte, was AVM (zumindest bei dem per RA verkündeten) nicht vorsieht (die 7430 von M-net hat irgendeine alte 06.83 als Firmware - das unterschiedliche Verhalten verschiedener FRITZ!OS-Versionen kam da noch erschwerend hinzu.
Gerade bei kaskadierten Routern (und IPv6) kommt man bei AVM wohl nicht daran vorbei (deshalb staune ich auch, daß jetzt so großzügig auf "IPv6 preferred" gesetzt wird bei 1&1), die DNS-Abfragen (sofern man keine fixen Server nutzen will, was aus Datenschutzsicht auch nicht das Gelbe vom Ei ist - die Diskussion dazu läuft ja gerade im Zuge von "DNS over HTTP") schön brav über die Kaskade abzuwickeln und dabei dafür zu sorgen, daß tatsächlich auch die Clients am Ende zuerst mal nach AAAA-Einträgen suchen (oder zumindest gleich parallel).
Dann arbeitet der "multid" von AVM (bzw. der von ihm gesteuerte "dnsd") schön brav als Forwarder (jeder mit seiner eigenen Ansicht, was in der Zone "fritz.box" so los sei - die kriegt man also immer schon vom ersten Resolver und kommt an die dahinter nicht mehr ran) und Cache und nimmt auf der LAN-Seite die Requests entgegen, die er auf der WAN-Seite (so er sie nicht bereits selbst beantworten kann aus seinen Zonen oder dem Cache) dann wieder an seinen Server stellt. Damit braucht es auch kein (IP-)Routing von DNS-Abfragen und für die Clients stellt sich gar nicht mehr die Frage, wen oder was die Box selbst abfragt - entscheidend sind die vom "dnsd" verwendeten Resolver.
Denn die FRITZ!Box braucht (zumindest in meinem Beispiel) eben auch ihre eigene "Weltsicht" ... das geht schon beim DynDNS-Account los (wo die kaskadierte Box bei meiner Aufgabenstellung erkennen mußte, daß sie keine eigene IPv4-Adresse hat, diese somit nicht aktualisieren und auch nicht immer wieder neu abfragen muß ... wobei ich auch bei der Angabe einer IPv6-Adresse für den DynDNS-Server in FRITZ!OS 7 krachend gescheitert bin, wenn ich mich richtig erinnere (aber nicht etwa schon beim Eintragen, sondern erst irgendwann später beim Parsen im entsprechenden Daemon), aber der entscheidende Punkt ist/wäre ohnehin die "Kontrolle" des "ddnsd" auf den Erfolg bzw. die Notwendigkeit eines Updates) und endet bei der Tatsache, daß der "voidp" (für den zusätzlichen SIP-Account, der hier der eigentliche Antrieb war neben der Sicherheit, daß der Provider nicht ins LAN (des kaskadierten Routers) sehen kann) grundsätzlich die DNS-Server befragt, die er auf der WAN-Seite gelernt hat - kommt er da nicht hin (z.B. eben wegen des Überschreibens des DNSv6-Servers per RA mit einer "fd00::/8"-Adresse, wie es in der Standardeinstellung (auch noch im FRITZ!OS 7) der Fall ist) wegen fehlendem Routing, kriegt man keine SIP-Accounts ans Laufen.
Insgesamt scheint mir die FRITZ!Box auch mit FRITZ!OS 7 noch zu unausgereift für den Einsatz am DS-Anschluß ... selbst wenn Kaskaden vielleicht nicht der primäre Einsatzzweck sind. Aber seitdem einige Provider mit der "Router-Freiheit" auch den Support
generell verweigern möchten, sofern der Kunde eigene Endgeräte angeschlossen hat (und zwar vollkommen unabhängig davon, daß eine Leitungsunterbrechung ja i.d.R. nichts mit der Konfiguration zu tun hat), muß man m.E. immer öfter darüber nachdenken, solche Kaskaden zu bauen (bzw. ihre Verwendung zu empfehlen) - mal unabhängig von den zusätzlichen Stromkosten.
Wenn im Haushalt niemand lebt, der für den Support-Fall einfach mal den anderen Router anklemmen kann für die nächste Woche (und zwar inkl. Umkonfigurieren im LAN und bei der Telefonie - bis hin zur DECT-Anmeldung - man weiß ja nie, wie lange der Provider zur Fehlerbehebung braucht, wenn es keine Leitungsunterbrechung ist), werden die Kosten durch den zusätzlichen Stromverbrauch auch ganz schnell zweitrangig ... im Vergleich zu den Preisen, die der "durchschnittliche Dienstleister" für eine solche Umkonfiguration dann berechnen dürfte.
Damit ist und bleibt man entweder dem Provider hilflos ausgeliefert (inkl. möglicher Spionage über Fernwartungsfunktionen durch den Provider), weil man ausschließlich seinen Router verwendet oder man setzt den eigenen Router hinter den vom Provider und dann hat man genau dieses Szenario mit der Kaskade. Die meisten Kunden brauchen auch nicht wirklich etwas anderes als DS-Lite ... wenn sich IPv6-Adressen auch in den Mobilfunknetzen durchgesetzt haben, sind die Dienste der eigenen FRITZ!Box auch per IPv6 erreichbar und irgendwann wird AVM vermutlich auch mal IPv6 als Transport-Protokoll für das eigene VPN entdecken ... wenn das bei 07.00 noch nicht erfolgt sein sollte (ich hatte mal etwas in der Richtung irgendwo gelesen, weiß aber nicht, ob es tatsächlich bis ins Release gelangt ist).
Damit wäre dann so eine Konfiguration, wie ich sie eingerichtet hatte (das hier war in der Gegend von Hanau), immer öfter auch für Dienstleister eine denkbare (und dankbare) Lösung ... solange die kaskadierte Box korrekt konfiguriert ist, macht es am DS-Lite-Anschluß gar keinen Unterschied, ob ein Router an der Grenze des Heimnetzes sitzt (der vom Provider als Edge-Router) oder dahinter in einer Kaskade ... immer vorausgesetzt, die Präfix-Delegierung und die Port-Freigaben klappen im Edge-Router, was bei der 7430 auch nicht der Fall war, weil die Einstellung "exposed host" wirkungslos war und es tatsächlich nur mit den dynamischen Freigaben über PCP zwischen den FRITZ!Boxen sauber arbeitet.
Man verliert im kaskadierten Router aber nichts
zusätzlich an Funktionen ... ja, bei einigen Sachen (wie eben dem DynDNS-Beispiel) ist es sogar deutlich von Vorteil, wenn der kaskadierte Router auch weiß, daß es sich um einen DS-Lite-Anschluß handelt. Also sollte AVM den Fokus auch etwas mehr auf die korrekte Funktion (und zwar mit Standardeinstellungen) in diesem Szenario legen ... und da gibt es noch einiges zu tun. Ich hätte vermutlich (ohne zusätzlichen Shell-Zugang, auch wenn der kein Dauerzustand sein soll) auch irgendwann den Bettel hingeschmissen ... das Ganze nur mit den Support-Daten zu untersuchen und dann noch das unterschiedliche Verhalten der letzten FRITZ!OS-Versionen (von 06.83 bis 07.00) können einem schon den Nerv rauben.
------------------------------------------------------------------------------------
Ich hoffe nur, daß AVM die Situation in künftigen Versionen tatsächlich verbessert (man darf auch mal die eine oder andere zusätzliche Einstellung einführen, wenn die vorhandenen bei der gestiegenen Zahl von Möglichkeiten das nicht mehr abdecken können) und nicht - wie bisher leider zu oft üblich - mit dem Hintern beim Umdrehen das wieder einreißt, was man vorne gerade aufgebaut hat und was die Kunden inzwischen auch verwenden.
Wenn bei solchen - etwas komplizierter "geborenen", nichtsdestotrotz funktionierenden und zwar ohne jeden "dreckigen Trick" - Konfigurationen nach einem Firmware-Update wieder mal etwas nicht geht, wird man die Kunden kaum für ein Update (und möglichst noch ein automatisches, wenn es nach den Hersteller-Empfehlungen geht) begeistern können ... und damit führt man seine eigene Informations- und Firmware-Politik ("Wir empfehlen grundsätzlich
jedes Update auch aus Sicherheitsgründen.") gleich selbst ad absurdum.
Jedenfalls ist für mich - gerade bei einer FRITZ!Box als kaskadiertem Router - auch das derzeitige Verhalten des FRITZ!OS 7 indiskutabel ... so ein Router ist parallel auch immer ein Security-Device (vielleicht nicht immer ein gutes) und da sollte es schon eine Einstellung geben, ob der sich von irgendwelchen ND-Paketen auf seiner WAN-Seite (und die RAs gehören in diesen Kontext) dazu überreden läßt, einen anderen DNSv6-Server oder ein anderes Gateway zu benutzen. Die SLAAC-Mechanismen und ND sind ein Angebot und kein "must-have" ... wenn es statische Einstellungen gibt, kann es sinnvoll sein, diese per ND zu aktualisieren - oder eben auch nicht.
Wenn sich auf der WAN-Seite unsichere Geräte bewegen, die auch falsche RAs senden können, um den DNSv6-Traffic umzuleiten, dann kann die FRITZ!Box ja wohl kaum so einfach auch auf diese "hören" ... zumindest sollte man es ihr ausdrücklich verbieten können und dann muß man sich darauf auch verlassen können. Wenn sie die Einstellungen per DHCPv6 "gelernt" hat, dann muß sie diese auch verwenden ... im Extremfall kann man am besten sogar noch einstellen, welcher DHCPv6-Server als einziger "Vorgesetzter" zu akzeptieren ist (dann kann man ggf. sogar auf Broadcasts verzichten), um auch DHCP-Hijacking zu vermeiden. Die neueren Modelle mit ihrem zusätzlichen WAN-Port sind ja auch deutlich stärker auf den Betrieb hinter anderen Ethernet-Komponenten im Netz beim Kunden ausgelegt ... ob das nun ein externes Modem für DSL oder Glasfaser oder eben ein anderer Edge-Router ist. Da muß man dann auch mal zusätzliche Überlegungen dahingehend anstellen, was da von der Ethernet-Seite (am WAN-Anschluß) noch "nebenbei" kommen könnte.
Ansonsten wird die FRITZ!Box als Security-Device überflüssig, ja sogar gefährlich ... wenn mit der einfachen Konfiguration auch durch (relative) Laien immer weiter wachsende Unsicherheit durch undurchsichtige, unspezifizierte und undokumentierte Automatismen einzieht, tut sich AVM (nach meiner Ansicht jedenfalls) damit auch keinen Gefallen - weil zu den anderen Kröten, die man als Kunde inzwischen schlucken muß, immer mehr Skepsis ob der Sorgfalt beim Entwickeln und Testen kommt (und allzu oft wird Agilität vielleicht auch mit "funktioniert eben so wie es gerade fertig ist" verwechselt - das mag bei sicherheitsunkritischen Funktionen gelten und denkbar sein, ist bei security-relevanten Fragen aber ein absolutes "no go").
In dieselbe Kategorie gehört für mich auch die Feststellung, daß bei unkonfiguriertem Gerät die GRX-Boxen den WAN-Port einfach der Bridge mit den LAN-Ports zuschlagen ... es gibt bei AVM echte Vorkehrungen dafür, daß die Box aufgrund von Fehlern in den Einstellungen mit "Werkseinstellungen" startet (z.B. die Eventlog-Meldung mit der ID 60, die ich vor kurzem irgendwo in einer Liste hier veröffentlicht habe) und damit ist dann ein Netz hinter einer solchen Box, wo ansonsten der WAN-Port isoliert wäre mit der korrekten Konfiguration, jedem Zugriff von dieser Seite schutzlos ausgeliefert. Findet jemand einen Weg, eine FRITZ!Box zum "Vergessen" der Einstellungen zu zwingen, kann man damit auch einen bewußten Angriff fahren.
Warum geht AVM nicht hin und baut mit diesem WAN-Port in der Standard-Konfiguration (wenn das DSL-Modem aktiv ist) einfach eine echte DMZ auf? Dann schadet es auch nichts, wenn sich bei den Werkseinstellungen hinter diesem WAN-Port tatsächlich "das Internet" befindet ... der Zugriff auf die LAN-Ports ist trotzdem nicht möglich. Und AVM hat gleich noch etwas, was einige bisher schmerzlich vermissen ... nämlich eine "echte" DMZ, in der man auch eigene Dienste in einer Art und Weise betreiben kann, daß bei einem kompromittierten Server (und das passiert auch den Besten) nicht das gesamte LAN mit gefährdet wird, wie es bei einem "exposed host" nun mal der Fall ist. Ich verstehe auch noch, wenn man so einen Port nicht "brachliegen" lassen will ... aber das war schon mit dem LAN4 für das Gastnetz eher eine Schnapsidee, solange sich der Bootloader nicht dazu überreden ließ, von diesem Port keine FTP-Sessions zu akzeptieren. Das scheint (aus dem Kopf, aktuelle Tests müßte man noch mal machen) zumindest bei den GRX-Boxen und dem WAN-Port anders zu sein ... dort klappt zumindest das Suchen per UDP-Broadcast nicht, wenn ich mich recht entsinne.
Wobei mir dann auch gleich noch auffällt, daß bisher kaum thematisiert wurde, was AVM mit der 7590 auch noch bei jedem Update macht (zumindest mit der 06.92 und der 07.00 hat man es getan): Es gibt parallel zum Firmware-Update auch immer noch ein Update des Bootloaders ... geht man rein nach den Dateigrößen der jeweils enthaltenen Dateien "var/urladerupdate", ist das auch bei der 06.92 ein anderes als bei der 07.00 - wobei das auch auf die andere C-Library und das statische Linken dieses Programms zurückzuführen sein könnte. Der Inhalt (also der eigentliche Bootloader) könnte da immer noch derselbe sein ... bei der 7580 gibt es dieses Programm nicht, daher kann ich auch nicht einfach mal so nachschauen (bei der Ausführung), ob so ein Update tatsächlich mehrfach erfolgen würde oder wie weit es vorherige Prüfungen und Vergleiche gibt, ob ein Update überhaupt notwendig ist.
Die 7590 ist jedenfalls im Moment die einzige (mir bekannte) Box, wo AVM das mit dem "urladerupdate" (was in der "var/install" der anderen GRX-Boxen auch angelegt ist, wenn ich mich richtig erinnere) auch tatsächlich nutzt ... angesichts des doppelten Bootloader-Codes (wegen des NAND-Flashs) und der zusätzlichen Sicherheitsmaßnahmen (ich würde sagen, daß ein Update im finalisierten Zustand nur möglich ist, wenn tatsächlich beide Kopien des Bootloaders keine Fehler aufweisen ... das ist also nicht nur ein "blindes Überschreiben", wie es bei älteren NOR-Boxen teilweise geschah) sicherlich auch nichts, was man ohne echte Notwendigkeit machen würde - ich habe aber bisher noch in keiner "info.txt" etwas zu diesem Thema (hier wird die Box eben dauerhaft verändert, solange ein Recovery-Programm die Änderung am Bootloader nicht auch wieder rückgängig macht - DAS glaube ich aber nun tatsächlich erst, wenn ich es mit eigenen Augen gesehen habe) gefunden.
