Unbound-Problem nach sich ändernder IPv6-Adresse

[mauorrizze]

Hi,
ich nutze Unbound für ein paar lokale overrides (und) als meinen primären DNS im Heimnetz. Per DHCP landet die router-IPv4 und je nach Gerät auch die public IPv6, dann bevorzugt, als DNS-Server in den Clients. Mein Problem ist, dass nach "freiwilliger Zwangstrennung" via periodic interface reset cron job und nachfolgendem IPv6-Wechsel (1&1) der Geräte unbound nicht mehr auf die öffentliche IPv6 reagiert. Ein Service Neustart behebt das Problem.
Auf Geräten mit der IPv6 als primärem DNS Server gibt es dann Probleme oder zumindest Verzögerungen beim domain auflösen, z.B. geht dann ein normales "dig" nicht mehr, genauso antwortet dig @ipv6

Code: [Select]

->>HEADER<<- opcode: QUERY, status: REFUSED, id: 36322
flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
WARNING: recursion requested but not availablewährend dig @ipv4 sowie auf den Geräten ohne den IPv6-Eintrag die Anfrage regulär beantwortet wird.
In Services: Unbound DNS: Access Lists ist die aktualisierte IPv6 mit passendem Bereich für den Client mit aufgelistet. Der Client dürfte unschuldig sein, passiert auch ohne dass er veraltete IPv6 Adressen mitschleift.

Als workaround würde ich den unbound service per cron kurz nach IP-Wechsel neustarten, allerdings geht das nach allem was ich bisher gelesen habe nicht persistent. Alternativ würde mich interessieren wie man OpnSense so konfiguriert dass für solche Sachen die link-local Adresse propagiert und nutzbar gemacht wird. Oder am besten wie man das eigentliche Problem behebt.
IPv4 bevorzugen fände ich keinen sinnvollen workaround für 2019

[schnipp]

Vermutlich hast Du (genauso wie ich) dieses Problem: --> siehe hier

[mauorrizze]

Vermutlich hast Du (genauso wie ich) dieses Problem: --> siehe hier

Bin mir nicht ganz sicher, eventuell war das der Grund warum ich manuelles reconnect per cron aktiviert habe, gut möglich dass ich das Problem mit der Trennung vom Provider auch hatte. Spätestens seit dem klappt das mit IPv6 aber stabil. Nur unbound lässt keine Anfragen über die neue IPv6 zu.

[schnipp]

[...] Nur unbound lässt keine Anfragen über die neue IPv6 zu.

Hattest Du in diesem Fall mal über die SSH-Konsole nachgeguckt, ob an dem Netzwerkinterface mehrere IPv6-Adressen mit unterschiedlichem Präfix kleben?

[mauorrizze]

Hattest Du in diesem Fall mal über die SSH-Konsole nachgeguckt, ob an dem Netzwerkinterface mehrere IPv6-Adressen mit unterschiedlichem Präfix kleben?

Ne aber *dig* kann ich aktuell machen
Nein, es ist schön brav nur die link-local und aktuelle public ipv6 eingetragen. Hatte ich in pfsense früher auch häufig dass alte IPv6 mitgeschleppt wurden und trotz deprecated-Markierung hin und wieder die Clients verwirrt hat. Aber ich vermute die manuelle Zwangstrennung beseitig das Problem. Daher falls es dir was hilft auch mal meine wichtigsten IPv6-Punkte:

Code: [Select]

1&1 VDSL Config mit Dual Stack und Zwangstrennung
[LAN]
IPv6 Conf Type Track Interface
[LAN/Track configuration]
IPv6 Interface WAN
IPv6 Prefix ID 0

[LAN2] #Freifunk
IPv6 Prefix ID 1

[WAN] #PPPoE
IPv6 Conf Type DHCPv6
[WAN/DHCPv6 client configuration]
Request only an IPv6 prefix [ ]
Prefix delegation size 56
Send IPv6 prefix hint [x]
Directly send SOLICIT [x]
Prevent release [ ]
Use IPv4 connectivity [x]

VLAN disabled weil ich geschafft habe die Fritzbox im Bridge Mode laufen zu lassen und die macht das. Nur sie selbst hat leider kein Internet ^^

Und das wichtigste:
System->Settings->Cron
Command: Periodic interface reset
Parameters: wan
1x am Tag
Das erzwingt den Reconnect zur Uhrzeit meiner Wahl und als Nebeneffekt wird so einiges bereinigt. Ich erinnere mich dass ich anfangs auch Probleme mit IPv6 hatte, aber weiß nicht mehr ob das Probieren der SOLICIT/hint Einstellungen oder der cronjob diese gefixt hatten.



Wenn sonst keiner eine Idee hat werde ich versuchen eine zusätzliche manuelle, feste IPv6 zu vergeben und diese propagieren zu lassen. Hab ich mich aber noch nicht mit beschäftigt. Glaub pfsense hat eh die link-local verwendet für sowas und hatte daher weniger Probleme bei Änderungen.

unbound hört interessanterweise auf allen Interfaces

Code: [Select]

unbound  unbound    91265 4  udp6   *:53                  *:*
unbound  unbound    91265 5  tcp6   *:53                  *:*
Und ich vermute dass die Access List, die laut Webinterface mit aktueller IPv6 korrekt ist, intern nicht ohne Neustart aktiv wird. Denn wenn ich explizit an der dort hinterlegen IPv6 (abzüglich /64) nachfrage, kommt selbiger status: REFUSED. Nicht nicht-erreichbar o.Ä.

[norg]

Habt ihr mal in /var/unbound/access_lists.conf geschaut ob dort euer Netzwerk zu sehen ist? Ich hatte auch Probleme und mit viel debuggen festgestellt, dass dort mein IPv6 Netzwerk fehlt obwohl ich sogar dank Business Anschluss statisches IPv6 (und IPv4) habe. Als ich dort mein /56 eingetragen habe und unbound restarted hab lief es auch. Nun muss ich es nur noch persistent hinkriegen.

Geht mit Services: Unbound DNS: Access Lists immerhin auch per UI!

[franco]

https://github.com/opnsense/core/issues/3797 ?

[mauorrizze]

Ja, https://github.com/opnsense/core/issues/3797 habe ich vor ein paar Tagen auch schon mal gesehen und als möglicherweise relevant eingestuft. WAN-Restart -> neue IPv6 -> LAN-Tracker-Update -> Unbound antwortet nicht mehr aus dem IPv6-LAN.

Das Problem von @norg habe ich nicht, aber trotzdem eine Beobachtung zu /var/unbound/access_lists.conf:
Während im Webinterface unter Services: Unbound DNS: Access Lists die korrekten, aktuellen IPv6 Subnetze stehen, sind in der /var/unbound/access_lists.conf die veralteten vom Vortag zu sehen, bis ich eben auch unbound neu starte und das ganze wieder funktioniert.