MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Fritz!Box, ULA und IPv6 DNS

Bericht über ein Troubleshooting von DNS-Auflösungen mit IPv6, Fritz!Box und Unique Local Addresses und eine magische Lösung.

Auslöser

Eigentlich habe ich bei einem Kunden mit mit SCEP, Intune-Policies und TPM rumgeschlagen. Einige Clients bekamen kein Computerzertifikat und im Eventlog fand ich Meldungen wie:

Protokollname: Application
Quelle:        CertificateServices-Client
Ereignis-ID:   86
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
BBeschreibung:

Error initializing SCEP certificate registration for WORKGROUP\CLIENT1$ via 
https://AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net/templates/Aik/scep:

GetCACaps

Method: GET(15ms)
Phase: GetCACaps
The server name or address could not be resolved 0x80072ee7 (WinHttp: 12007 ERROR_WINHTTP_NAME_NOT_RESOLVED)
https://AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net/templates/Aik/scep

Dabei handelt es sich wohl um Kontakte von Windows zu einem Microsoft Cloud Service, um die Authentizität des TPM-Module zu prüfen und damit einen Certificate Singing Request zu signieren. Das soll aber hier nicht Thema sein.

DNS über IPv6 und ULA

Das Eventlog sagt deutlich, dass es den Namen nicht auflösen kann. Also habe ich die gleichen Adressen mittels NSLOOKUP abgefragt. Die Antwort auf einem Windows 11 Client mit einer Fritz!Box 7590 (Firmware Version 8.02) deutet nicht darauf hin, dass der Name nicht auflösbar ist, sondern der DNS.Server keine Antwort liefert.

Die IP-Adresse des DNS-Servers kam mir erst etwas suspekt vor. Aber die Adresse beginnt mit "FD" und ist damit eine "Unique Local Address (ULA)". Nach dem Prefix "FD" kommen 40 Bit (=2^40 = 1.099.511.627.776 mögliche Adressen= und ein 16bit (=65535) Subnetz. Es ist relativ unwahrscheinlich, dass zwei Firmen schon hier identische Netzwerke verwenden.

Das sind quasi die Gegenstücke von privaten IPv4-Addressen (10.x.x.xx, 172.16-172-32.x.x, 192.168.x.x). Wenn die Adresse nicht von ihnen vorgegeben sondern zufällig gewählt wird, dann entsprechend sie ehr noch den 169.254.x.x-Adressen, die Geräte sich selbst aussuchen können. Diese Funktion ist in der Fritz!Box per Default aktiv.

So wird eine koordinierte IPv6-Kommunikation im Netzwerk gewährleistet, auch wenn vom Provider keine IPv6-Verbindung angeboten wird. In meiner Umgebung bekomme ich von meinem Provider offizielle IPv6-Adressen, die durch die Fritz!Box auch an die Clients weitergereicht werden. Damit hat mein Client mehrere IP-Adressen.

Für die Namensauflösung können in IPv6 drei Optionen genutzt werden, von denen die Fritz!Box wohl nur die ersten beiden Optionen unterstützt.

  • DHCP verteilt DNS-Server
  • DNS-Server per Router Announcement
  • DNS-Server als Multicast-Adresse

Das führte in meiner Konfiguration dazu, dass mein Client anscheinend DNS-Server auch mehrfach gelernt habe.

Ich habe dann bei NSLOOKUP explizit die DNS-Server angegeben und folgende Antworten bekommen:

Host  DNS-Server Ergebnis

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net 

 Default IPv6 UIP
fd1d:baaf:d80b:0:2e91:abff:fe49:d7c9

Keine Antwort 

outlook.office.com

 Default IPv6 UIP
fd1d:baaf:d80b:0:2e91:abff:fe49:d7c9

Keine Antwort

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net  

 
2a00:6020:4e92:e200:2e91:abff:fe49:d7c9

OK

outlook.office.com

 
2a00:6020:4e92:e200:2e91:abff:fe49:d7c9
 

OK

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net  

 
192.168.178.1 

OK 

outlook.office.com

 
192.168.178.1 

OK 

Es hat den Anschein, dass zu dem Zeitpunkt meine Fritz!Box keinen DNS-Service auf der ULA angeboten hat. Da die ULA-Adresse an erster Stelle war, hat mein Client den Namen einfach nicht aufgelöst. Damit stellen sich mir nun zwei Fragen

  • Warum antwortet meine Fritz!Box nicht auf die DNS-Anfragen an die ULA?
  • Warum lernt mein Client doppelte DNS-Server?

Andere DNS-Server

DNS ist nicht an das lokale Netzwerk gebunden. Ich kann per NSLOOKUP ja auch andere DNS-Server fragen und das ist immer mein zweiter Versuch. Vielleicht ist der abgefragte Name tatsächlich nicht im Internet auflösbar und meine Fritz!Box kann ihrerseits den Namen nicht auflösen und liefern. Also habe ich die Testserie erweitert. Zuerst habe ich mir von der Fritz!Box die DNS-Server meines Providers geben lassen:

Hier haben wir schon mal vier externe DNS-Server und dann gibt es ja noch Google und Co.

Host  DNS-Server Ergebnis

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net

 Default IPv6
fd1d:baaf:d80b:0:2e91:abff:fe49:d7c9

Keine Antwort 

outlook.office.com

 Default IPv6
fd1d:baaf:d80b:0:2e91:abff:fe49:d7c9

Keine Antwort

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net

 
2a00:6020:4e92:e200:2e91:abff:fe49:d7c9

OK 

outlook.office.com

 
2a00:6020:4e92:e200:2e91:abff:fe49:d7c9

OK

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net 

8.8.8.8
Google IPv4 DNS

OK

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net 

185.22.44.50
Provider DNS

OK 

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net

185.22.45.50
Provider DNS

OK

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net

2a00:6020:100::1
Provider DNS 1

OK 

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net

2a00:6020:200::1
Provider DNS 2

OK 

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net

192.168.178.1
Router IPv4

OK

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net

fe80::2e91:abff:fe49:d7c9%35
Router Default Gateway

OK

AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net 

2a00:6020:4e92:e200:2e91:abff:fe49:d7c9
Fritz DNS1

OK

Interessant ist, dass eine Abfrage über IPv4 an einen IPv4-DNS-Server durchaus auch IPv6-Adressen liefert.

Das bestätigt mein Verdacht. Die Microsoft Adressen können von allen externen DNS-Servern über IPv4 undIPv6 aufgelöst werden. Meine Fritz!Box hingegen reagiert auf IPv6-DNS-Anfragen nur über die IP-Adresse des Default Gateway oder die interne offizielle "2a00"-Adresse meiner Fritz!Box. Auf der über RFC5006 vergebenen Adresse ist die Fritz!Box taub.

Die "Unique Local Address" meiner Fritz!Box (fd1d:baaf:d80b::2e91:abff:fe49:d7c9/64) ist aber im Router Advertising auch aktiviert, wie es von AVM empfohlen wird.

Die ULA-Adresse war in der Zeit aber auch nicht per PING erreichbar, während ich die IPv6-Adresse des Default Gateways als auch die 2a00-Adresse des zweiten DNS-Servers ansprechen konnte.

Irgendwo hatte meine Fritz!Box also einen Blocker im System.

DHCPv6

Bei IPv6 ist DHCP nicht zwingend erforderlich, da ein Client die Netzwerkadresse aus einem "Router Advertising" beziehen und die Hostadresse quasi selbst bestimmen kann. Bei meiner Fritz!Box ist ein DHCP-Service aktiv, der nur für DNS-Server verteilt. Unter http://fritz.box/#/network/ipv6 finde ich:

Entsprechend finde ich bei einer Verbindung auch die Meldung im Wireshark.

Die Fritz!Box liefert hier über DHCPv6 genau zwei DNS-Server aus, die mein Client auch nutzt.

RDNSS RFC5006

Es gibt aber noch einen zweiten Weg, wie ein Client einen DNS-Server in einem IPv6-Netzwerk bekommen kann. Auch diese Option ist bei meiner Fritz!Box aktiv.

Hier sehen Sie normalerweise einfach die Unique Local Address der Fritz!Box. Ich würde erwarten, dass auf der IP-Adresse ein DNS-Server laufen sollte. Der DNS-Server war einfach "stumm". Ich habe natürlich auch einmal "zurücksetzen" geklickt aber es hat sich nichts geändert. Genau diese Adresse hat aber auch mein Client "gelernt.

Ich habe mir dann die RFC5006 genauer angeschaut und folgende Stelle gefunden:


https://www.rfc-editor.org/rfc/rfc5006.html#section-5.1  

Also sollte ich nun doch die passenden Pakete auch mit WireShark im Netzwerk finden. Ein passender Displayfilter ist schnell erstellt:

icmpv6.opt.type == 25

Allerdings wird diese Information nicht über das klassische "Neighbour Solicitation" und "Neighbour Advertisement" in kurzen Zeitabständen übertragen, sondern ist Teil des "Router Advertisement".

 

Die RFC4861 (https://datatracker.ietf.org/doc/html/rfc4861#section-6.2.1) erlaubt Intervalle zwischen 180 -1800 Sek. Default sind 600 Sekunden als Max und entsprechend ist Minimum mit 0,75*Max = 450 Sek. Die Fritz-Box sendet diese Announcements anscheinend recht unregelmäßig. Ich habe Abstände von 166 Sek, 527Sek, 538 Sek, 474 Sek gesehen. Die "Lifetime" des DNS-Servereintrags ist aber immer 1200 Sekunden. (20 Min). Also alles im Rahmen.

Damit kann ich mir nun erklären, warum mein Client einmal die DNS-Server per DHCP und noch mal per RA erhalten. Seltsam nur, dass Windows die Einträge dann nicht zusammenfasst.

RFC5006 off

Auf der Suche nach dem DNS-Problem habe ich zuerst die Option RFC5066 einfach abgeschaltet. Damit deaktiviert sich zwar nicht die ULA aber vielleicht ändert sich etwas an den DNS-Servern des Clients.


http://fritz.box/#/network/ipv6

Leider hat sich nach dem Neustart meines Clients nichts geändert. Die Fritz!Box sendet die Information nicht per ICMPv6 aber das hat sie vorher auch nicht gemacht. Der DHCP-Server liefert aber diese Adresse weiter als gültigen DNS-Server aus.

ULA off

Ich habe mich natürlich gefragt, wozu ich eine ULA-Adresse brauche und etwas recherchiert. Dazu habe ich bei AVM folgende englische Aussage gefunden, die in der deutschen Webseite anders klingt:

Enable the option "Assign unique local addresses (ULA) as long as no IPv6 connection exists (recommended)"
Quelle: Configuring IPv6 in the FRITZ!Box https://en.fritz.com/service/knowledge-base/dok/FRITZ-Box-7490/573_Configuring-IPv6-in-the-FRITZ-Box/   

Das könnte ich nun so interpretieren, dass die Fritz!Box nur eine ULA vergibt, wenn es keine externe IPv6-Adressen gibt. Es könnte aber auch bedeuten, dass ich als Administrator diese Checkbox nur aktivieren sollte, wenn es ich keine externe IPv6-Adressen bekomme. Sollte ich ULA vielleicht besser abschalten? Das habe ich dann im nächsten Schritt getan: 


http://fritz.box/#/network/ipv6

Vor der Abschaltung hatte mein Client laut IPCONFIG /ALL noch die temporären ULA-Adressen.

Nach der Abschaltung ist das ULA-Netzwerk bei den IP-Adressen auf der Netzwerkkarte verschwunden. Allerdings ist der Server in den DNS-Einstellungen weiter aufgeführt

Das finde ich suspekt, aber per DHCP bekommt der Client dennoch weiter die ULA der Fritz!Box.

Anscheinend hat die Box immer noch die "FD"-Adresse intern und interessant war nun aber, dass die Adresse sowohl per PING erreichbar war aber auch eine Namensauflösung funktioniert hat:

Anscheinend sendet mein Client die DNS-Anfrage an die ULA über das Default Gateway mit der verbindungslokalen Adresse an die Fritz!Box, welche weiß, wohin es weiter geht. Unique Local Addresses sind ja durchaus routbar. Mit Wireshark ist zu sehen, dass meine 2a00-Adresse direkt mit der fd1d-Adresse kommuniziert.

 

In der IPv6-Welt dreht sich das ein oder andere Rad etwas anders.

Ich kann leider nicht so tief in die Fritz!Box schauen, warum genau diese Änderung nun die DNS-Erreichbarkeit ermöglicht hat.

Rückbau zum alten Stand

Nachdem nun die DNS-Auflösung auch über die ULA-Adresse funktioniert hat, habe ich die Einstellungen wieder auf die Werte zurückgestellt, die Anfangs aktiv waren.

  • Zuweisung von ULA-Adressen wieder aktiviert
    Nach Aktivierung hat mein Client quasi Sekunden später schon wieder eine ULA-Adresse. Eine Namensauflösung gegen die ULA-Adresse der Fritz!Box hat weiter funktioniert.
  • DNSv6-Server auch über Router Advertisement bekanntgeben (RFC5006)
    Dann habe ich auch noch die Verbreitung über RA-Meldungen reaktiviert. Eine Namensauflösung gegen die ULA-Adresse der Fritz!Box hat weiter funktioniert.

Das hat mich nun doch irritiert, denn ich habe nun wieder die gleiche Konfiguration, die ich auch am Anfang hatte. Jetzt rächt es sich, dass ich nicht gleich am Anfang erst einmal die Konfiguration gesichert und die Fritz!Box durchgestartet habe. Vielleicht war wirklich nur die Bindung des DNS-Service auf die ULA-Adresse defekt und wurde durch die komplette Deaktivierung und Reaktivierung wieder gelöst.

Azure DNS

Meine Fritz!Box hat sich auf magische Weise gelöst aber vielleicht ist das Problem dennoch "woanders". Es gibt Dienste im Internet, mit denen ich einen Namen aus verschiedenen Ecken der Welt abfragen lassen kann.

[xml]$xmldns= (Invoke-WebRequest https://isc.sans.edu/api/dnslookup/AMD-KeyId-1234567890123456789012345678901234567890.microsoftaik.azure.net).content
$xmldns.dnslookup.dnsresult | group status,country -NoElement

 

Anscheinend sind die Namen nicht aus aller Welt zuverlässig erreichbar. Vielleicht ist auch dies eine Ursache für die Fehler am Anfang gewesen. Zumindest sollte man auch diese Frage bei Problemen mit Namensauflösungen im Internet stellen. Wenn aber, wie bei mir, der DNS-Server einfach einen Timeout liefert, dann ist dies nicht der Fall. Die Eventlogmeldung sagte aber nur, dass der Name nicht auflösbar ist. Das kann dann wieder beides bedeuten.

Zwischenstand

Ich kann sicher sagen, das am Anfang die Namensauflösung in meinem Netzwerk über die IPv6-ULA-Adresse der Fritz!Box nicht möglich war. Ein Test mit NSLOOKUP hat die klar gezeigt. Durch meine Änderungen während der Analyse und Fehlersuche hat sich aber wohl indirekt auch der Fehler selbst beseitigt, denn obwohl ich danach alle Einstellungen wieder rückgängig gemacht habe.

Ich beobachte weiter.

Weitere Links