Sporadisch wird mein lokaler DNS nicht zur Namensauflösung genutzt

[Barungar]

Du brauchst auch keinen DNS-Server am Client mit einer GUA, genauso wie Du am Client keinen mit einer öffentlichen IPv4 brauchst.
Die Frage ist, hat sich der Bind9 auch an die ULA gebunden? Wie ist das DNS-Bindung auf dem Bind9 konfiguriert. Im Zweifel kann ein Neustart des Dämonen helfen oder die Konfiguration anpassen.

Oder halt, das läuft im Docker, richtig? Reichst Du für die ULA auch den Port 53 "nach draußen" raus?! Ich meine es ist schön, wenn der Bind9 IM Container auf ULA:53 hört, aber nicht im LAN.

 

[Chris81T]

Genau, der Bind9 läuft als Docker Container auf dem Pi.

Eben bin ich wie folgt vorgegangen: Anstatt in der fritz.box den Pi als lokalen DNS für v6 zu hinterlegen, habe ich von meinem Windows 10 Desktop einen

nslookup auf dns.mydomain.de fd00:.... (Adresse des Pi's)

abgesetzt. Erst einmal unverändert das gleiche Ergebnis mit dem Timeout (war erwartet)

Im Portainer (Docker-Compose) Stack habe ich die ports um

    ports:
      - '192.168.12.107:53:53/tcp'
      - '192.168.12.107:53:53/udp'
      - '[fd00::ba27:ebff:fed4:4102]:53:53/tcp'
      - '[fd00::ba27:ebff:fed4:4102]:53:53/udp'

erweitert (Wichtig sind hier die eckigen Klammern, da ansonsten beim Deployment über zu viele ":" gemeckert wird).

Nun den gleichen nslookup abgesetzt:

nslookup dns.mydomain.de fd00::ba27:ebff:fed4:4102
Server: UnKnown
Address: fd00::ba27:ebff:fed4:4102

*** dns.mydomain.de wurde von UnKnown nicht gefunden: Query refused.

Also in der Bind9 named.conf weitergeschaut und erweitert:

acl mcunetwork {
  192.168.12.0/24;
};

acl mcunetworkV6 { <------------- BLOCK hinzugefügt
  ::0/0;
};

options {
  forwarders {
    1.1.1.1;
    1.0.0.1;
  };

  listen-on-v6 { any; }; <----- hinzugefügt

  allow-query { mcunetwork; mcunetworkV6; any; };  <------------- neuen ACL im Schritt 1; any im Schritt 2 hinzugefügt
};

zone "mydomain.de" IN {
  type master;
  file "/etc/bind/mcu-mydomain-de.zone";
};

Als Schritt 1 habe ich einen weiteren acl Block hinterlegt und bei allow-query hinterlegt. Laut https://kb.isc.org/docs/aa-00363 kann man so alle IPv6 Adressen durchlassen.

Leider bleibt es bei "Query refused" beim nslookup.

Als Schritt 2 habe ich als allow-query einfach mal "any" hinterlegt.

Damit gab mir der gleiche nslookup ein Ergebnis zurück:

PS C:\Users\chris> nslookup dns.mydomain.de fd00::ba27:ebff:fed4:4102
Server: UnKnown
Address: fd00::ba27:ebff:fed4:4102

Name: dns.mydomain.de
Addresses: fd00::ba27:ebff:fed4:4102
192.168.12.107

was mit der hinterlegten Zonendatei übereinstimmt:

dns IN A 192.168.12.107
dns IN AAAA fd00:0:0:0:ba27:ebff:fed4:4102
pi IN CNAME dns

Somit einen ersten Erfolg erzielt. Damals bei der reinen IPv4 Einrichtung von Bind9 fand ich es charmant, dass man den Adressbereich eingrenzen kann. Mit "any" würde alles durchgehen. Prinzipiell im lokalen Netzwerk sollte es wohl egal sein, aber was meint ihr? Ist "any" zu nutzen hier unklug? Bzw. kann jemand mir sagen, wie man den IPv6 Bereich gezielt hier eingrenzen kann?

 

[the other]

Moinsen,
Da ich mich mit bind9 nicht wirklich auskennen, kann ich es dir bzgl any nicht sagen. Denken würde ich, dass du zb den unter ACL ipv6 etwas anpassen kannst, da steht ja jetzt ebenfalls ein any wenn ich nicht irre.
Du hast in deiner fritzbox doch das Netz für die ULAs angelegt, wenn du hier das gemeinsame präfix dann also nimmst und in der bind9 Konfiguration mit fd00:: /64 einträgst...? Wobei dein Präfix da dann ja wenig aussagekräftig eingrenzt

Wenn ich dich recht verstehe, dann musst du die Einträge vornehmen, damit überhaupt Anfragen erlaubt werden. Das geht ja nun.
Wenn du jetzt noch was absichern willst, dann kannst du für den ipv6 Bereich via ULA das eben auch eingrenzen (wie für v4 ja auch), nur dass bei dir AFAIK statt any dann fd00:0:0::/64 da hin müsste.
Aber wie gesagt und gewarnt, Ahnung hab ich nicht fundamental davon
Achja, und als forwarder IPs stehen aktuell nur v4 und da gibt es vielleicht auch Alternativen zu den jetzt eingetragenen...


Edit
https://forum.heimnetz.de/threads/die-ipv6-adressen-sehen-aber-komisch-aus.387/
Da erklärt @Barungar noch mal super was zu den ipv6 Schreibweisen und mehr...

 

[Barungar]

Auch hier (was ist denn heute los). Kann ich mich dem Vorschlag von theother nur anschließen.
Du kannst das IPv6 auf Dein ULA-Subnetz begrenzen. Und auf Basis der IP fd00::ba27:ebff:fed4:4102 wäre das dann, in der Tat wie von @the other geschrieben fd00::/64

 

[Chris81T]

@the other :

Denken würde ich, dass du zb den unter ACL ipv6 etwas anpassen kannst, da steht ja jetzt ebenfalls ein any wenn ich nicht irre.

Das war auch mein Verständnis, dass es eigentlich wie ein "any" anzusehen ist.
Nachdem ich es auf

acl mcunetworkV6 {
  fd00::/64;
};

angepasst hatte und das any aus dem allow-query rausgeholt hatte, kam per nslookup wieder das "Query refused".

Was alternativ ging, ist die Eingrenzung bei listen-on-v6:

listen-on-v6 { fd00::/64; };

Das "any" musste ich wieder in die allow-queries reinnehmen. Damit läuft es wieder. Was ich genau bei dem ACL falsch mache, bzw. falsch verstehe, ist mir noch nicht klar.

Achja, und als forwarder IPs stehen aktuell nur v4 und da gibt es vielleicht auch Alternativen zu den jetzt eingetragenen...

Da hast du recht. In der Fritzbox habe ich aktuell bei IPv6 im Online-Konfigurationsbereich es bei der default Option - Über Internetprovider beziehen - belassen. Bei IPv4 bin ich von der Einstellung auf den Verweis auf meinen eigenen DNS Server (Bind9) gegangen. Da würden die forwarders dann greifen. Ist der Bind9 einmal nicht greifbar, so habe ich in der Fritzbox Alternativen hinterlegt, die dann genutzt werden.
Ob es hier Sinn macht, dass ich IPv6 auch über meinen Bind9 > forwarders laufen lasse, ist mir noch nicht klar, muss ich nochmal nachlesen. 1.1.1.1 geht an den Cloudflare DNS.

Kurz mal in Richtung IPv6 geschaut:
The best DNS servers with IPv6 for fast surfing

@Barungar :
Man merkt, du hast Ahnung von der Materie Ich werde mir später mal den Post, welchen "the other" geteilt hat, durchlesen. Bin gespannt.

 

[Chris81T]

Gerade testweise was probiert:

PS C:\Users\chris> nslookup heimnetz.de fd00::ba27:ebff:fed4:4102
Server:  UnKnown
Address:  fd00::ba27:ebff:fed4:4102

Nicht autorisierende Antwort:
Name:    heimnetz.de
Addresses:  2a02:17f8:4001:1499::2
          185.59.13.10

PS C:\Users\chris> ping heimnetz.de

Ping wird ausgeführt für heimnetz.de [2a02:17f8:4001:1499::2] mit 32 Bytes Daten:
Antwort von 2a02:17f8:4001:1499::2: Zeit=13ms
Antwort von 2a02:17f8:4001:1499::2: Zeit=11ms
Antwort von 2a02:17f8:4001:1499::2: Zeit=11ms
Antwort von 2a02:17f8:4001:1499::2: Zeit=11ms

Ping-Statistik für 2a02:17f8:4001:1499::2:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 11ms, Maximum = 13ms, Mittelwert = 11ms

Es kommt der Hinweis "Nicht autorisierte Antwort", aber der Bind9 scheint die passende IP zurückzuliefern, da die mit der vom Ping gemeldeten Adresse übereinstimmt. Woher bezieht der Bind9 die Info? Auch über die hinterlegten IPv4 Forwarder Adressen? Mein Verständnis war bisher, dass IPv4 und IPv6 nicht miteinander kompatibel sind, und quasi für sich laufen.. oder es greifen Fallbacks etc.

 

[Barungar]

Nicht autorisierte Antwort

Das ist vollkommen normal, weil nur der NS der Domäne selbst kann autorisiert antworten.

Hier ein Beispiel:
Im ersten Schritt frage ich nur nach "forum.heimnetz.de", mein DNS antwortet "nicht autorisiert".
Dann im zweiten Schritt frage ich "Wer ist der NS von heimnetz.de".
Im dritten Schritt frage ich nun nach "forum.heimnetz.de", aber den DNS von heimnetz.de und das darf autorisiert antworten.

C:\>nslookup forum.heimnetz.de
Server:  xxxxx
Address:  fd00:xxx::253

Nicht autorisierende Antwort:
Name:    forum.heimnetz.de
Addresses:  2a02:17f8:4001:1499::2
            185.59.13.10


C:\>nslookup -type=ns heimnetz.de
Server:  xxxx
Address:  fd00:xxxx::253

Nicht autorisierende Antwort:
heimnetz.de     nameserver = ns1.hk-net.de
heimnetz.de     nameserver = ns2.hk-net.de


C:\>nslookup forum.heimnetz.de ns1.hk-net.de
Server:  ns1.hk-net.de
Address:  2a02:17f8:2000:300::2

Name:    forum.heimnetz.de
Addresses:  2a02:17f8:4001:1499::2
            185.59.13.10

Das mit dem "nicht autorisiert" ist also vollkommen normal. Nur der DNS-Server, der wirklich die "DNS-Zone" besitzt, ist der einzige der "autorisiert" antworten darf. Alle anderen DNS-Server antworten immer "nicht autorisiert".

Mein Verständnis war bisher, dass IPv4 und IPv6 nicht miteinander kompatibel sind, und quasi für sich laufen.. oder es greifen Fallbacks etc.

Sind sie auch grundsätzlich nicht. Aber das DNS ist weiterhin das DNS. Egal, ob Du über IPv4 oder IPv6 fragst. Du bekommst ja auch das gleiche forum.heimnetz.de geliefert... egal ob Du über IPv4 oder IPv6 kommst.

Ob Du also mit dem VW Käfer oder dem Porsche 911 zum "Informationsschalter" fährst und fragst: "Wo wohnt denn Heimnetz?" sollte im normal Fall nichts an der Antwort ändern.

 

[Frank73]

Hallo,

ich würde mich hier gerne mal mit einklinken bzgl. LLA und ULA

Und als Punkte 2 Anmerkung.. Ich würde keine LLA im DNS hinterlegen, nimmt dafür besser ULA.

Ich nutze aktuell die LLA (in IPv4 entsprächen dies den Adressen 169.254.0.0/16). Hätte gerne auch die ULA verwendet (in IPv4 wären das die "eigentlichen" privaten Adressen). Was mich allerdings davon abgehalten hat ist der folgende Eintrag aus "Wikipedia":

Zitatanfang
Sofern in einem privaten Netz im Dualstack mit IPv4 nur ULA-Adressen verwendet werden, bevorzugt die Mehrheit der Clients bei einer DNS-Auflösung die IPv4-Adresse, auch wenn ein AAAA-Record existiert, da davon auszugehen ist, dass mit einer ULA-Adresse niemals der öffentliche IPv6-Adressraum erreicht werden kann. Dies führt in der Praxis dazu, dass in privaten Netzen (insbesondere beim Einsatz von NAT6) im Dualstack von ULA-Adressen abgeraten wird.
Zitatende

Mein Provider ist die Telekom, somit habe ich Dualstack.

Wie geht ihr in eurem Heimnetz damit um; nutzt ihr LLA oder ULA?
Verwenden die Clients wirklich vermehrt IPv4 bei Nutzung einer ULA?

 

[Barungar]

@Frank73 Ja, das beschriebene Szenario trifft aber auf "Heimnetze mit IPv6" nicht zu.

Verwenden Heimnetze mit IPv6:

1. in der Regel LLA, ULA und GUA - ein Host hat dann mind. 3 IPv6-Adressen,
2. in der Regel nicht ausschließlich ULA und kein NAT6.

Die Warnung bezieht sich darauf, wenn man althergebrachte (aus dem IPv4-Umfeld) Traditionen zu sklavisch auf IPv6 überträgt. Das Szenario in der Warnung macht nämlich Folgendes. Es gibt den Clients im Netz keine GUA, genau wie man beim IPv4 den Clients keine "öffentliche IPv4" gibt. Stattdessen wird in dem Szenario im LAN komplett nur mit ULA gearbeitet und dann am Border-Router mit NAT6 eine ULA auf eine GUA abgebildet. Also genau das, was man bei IPv4 mit der privaten IP macht, die dann auf eine öffentliche abgebildet wird.

Der entscheidende Satz in der Warnung ist: "Sofern in einem privaten Netz im Dualstack mit IPv4 nur ULA-Adressen verwendet werden" und das trifft normal bei Heimnetzen, wie ich eingangs sagte, nicht zu.

 

[blurrrr]

Ich wollte es auch grade schreiben... Betonung liegt da 1000%ig auf "nur"

 

[Barungar]

Korrekt, diese, in meinen Augen, "Fehlkonfiguration" kann nur entstehen, wenn der "Netzwerkadmin" in der Firma keine Ahnung hat. Und einfach nach Strickmuster A, sein vermeindliches IPv4-Wissen auf IPv6 überträgt. In solchen Fällen könnten dann so Schnapsideen rauskommen, im LAN nur ULA zu verwenden... weil die ja die "privaten IPv4" ersetzen. Und dann auch den Rest genau wie bei IPv4 weiterzubauen.

Das man das in Firmen so macht bei IPv4 ist aber ja hauptsächlich daraus entstanden, dass es einfach nicht genug IPv4-Adressen auf der Welt gibt um alle Firmennetze und das Internet abzubilden. Im Ursprungsgedanke des IPv4 sollte jeder "öffentliche IPv4" verwenden. Diesen Designfehler hat man mit IPv6 beseitigt.

Jede Firma kann nun also - selbst wenn sie nur ein /56-Bit IPv6 Subnetz erhält - mit ihren 4,7 Trillarden IPv6 schon ihre Infrastruktur abbilden. Und die vermeindliche "Fake-Sicherheit", die mir private IPs bringen, kann ich über Routing-ACLs und Firewalls viel effktiver umsetzen als über "private IPs". Die "priavten IPs" sind im Prinzip auch nur eine Routing-ACL, dass man diese Netze in "öffentlichen" Routern nicht zulässt.

Das ganze Ding mit den privaten IPs ist ein "Notfall-Patch" für IPv4 gewesen. Und bei den ULAs ist es in meinen Augen ähnlich, hier ist der primäre Mehrwert das dynamische GUA-Präfix abzufedern. Weil viele Internet-Zugänge kein statisches Präfix liefern und sonst alle paar Tage das NAS oder der heimische Server eine komplett neue IPv6 hätten.

Die ULA schafft also dort, wo kein statisches GUA-Präfix existiert, die notwendige adressstabilität für das interne bereitstellen von IP-Diensten.

 

[Frank73]

@blurrrr
@Barungar

Dann habe ich das jetzt auch verstanden und werden heute Nacht mal um die auf ULA umstellen ergänzen (die Nacht ist also gerettet)

 

[the other]

Moinsen,
in der Logik der oberen Beiträge würde ich umformulieren:
nicht "umstellen" sondern mit ULA ergänzen...damit hätten deine Geräte dann
1. link-locale (fe:
2. ULA (fd:
und
3. GUA
(sowie die IPv4)

Umstellen wäre dann wieder inhaltlich nahe am in der Warnung formulierten "nur"...
(Sorry, etwas haarspalterisch, aber wie zu sehen ist, kommt es ja durchaus auf Kleinigkeiten an).

 

[Chris81T]

Guten Morgen zusammen,

gestern Abend hatte ich noch eine kleine Herausforderung auf meiner QNap IPv6 zu aktivieren, so dass dort auch eine ULA nutzbar zur Verfügung steht. Anfangs hatte ich nur eine link-locale Address und sonst nichts, aber nach Umstellung von "Stateful" auf "Stateless" hat dann der virt. Network Controller der QNap eine fd... Adresse.

Dann hab ich alles zusammengeworfen und es läuft erstmal soweit alles via DNS (Zusammenfassung):

• Fritz!Box so eingestellt, dass "immer" eine ULA audgehändigt wird
• Mein Bind9 Docker Image auf meinem Pi so angepasst, dass die IPv6 Anfragen den Bind9 erreichen
• Den Bind9 so konfiguriert, dass
  • in der named.conf für IPv6 ein ACL hinzukam, welches aktuell noch nicht sauber greift, daher der Fallback, dass "any" erlaubt ist, aber bei ipv6-listen-on die Beschränkung auf die fd00.... gegeben ist
  • in der zone Datei AAAA Einträge mit den zugehörigen fd00 Adressen der anderen Rechner (wie meine QNap, auf der per Docker weitere Services laufen) hinterlegt
• In der QNap IPv6 aktiviert
  • Anderen Clients /Endgeräte haben bereits durch Punkt 1 eine IPv6 ULA erhalten
• In der Fritz!Box für IPv6 den eigenen Bind9 DNS Server hinterlegt (für lokal, aber auch für öffentliche Anfragen)
  • Als Fallback für die öffentlichen Anfragen in der Fritz!Box den IPv6 DNS von Cloudflare hinterlegt
• Nach Neustarts der Systeme gingen die nslookups erfolgreich durch (auch ohne dedizierte Angabe des Bind9)

PS C:\Users\chris> nslookup vaultwarden.mydomain.de
Server:  UnKnown
Address:  fd00::ba27:ebff:fed4:4102

Name:    jarvis.mydomain.de
Addresses:  fd00::265e:beff:fe30:1d43
          192.168.12.28
Aliases:  vaultwarden.mydomain.de

PS C:\Users\chris> nslookup heimnetz.de
Server:  UnKnown
Address:  fd00::ba27:ebff:fed4:4102

Nicht autorisierende Antwort:
Name:    heimnetz.de
Addresses:  2a02:17f8:4001:1499::2
          185.59.13.10

• Daneben dank eurem Input einen guten Einstieg ins IPv6 Thema erhalten, wobei ich mir hier im Neuland noch ein paar Themen mehr in der Tiefe noch aneignen muss

Ich hoffe damit aber für den aktuellen Moment eine gute (ausbaufähige) Basis zu haben und sage final nochmal ein

DANKESCHÖN

an euch!

 

[Frank73]

Guten Morgen,

gestern Abend die ULA auf der FB aktiviert und ins Netz verteilen lassen. Alle hosts / Clients haben jetzt noch eine ergänzende ULA.

Bei mir läuft es so:

• FB verteilt immer eine ULA
• In der FB auf der LAN-Seite sowohl für IPv4 als auch für IPv6 den lokalen DNS eingetragen
• Im DNS auf dem NAS als Forwarder die FB eingetragen

Alle Namensauflösungen funktionieren.

Auch von mir ein großes Dankeschön an euch.
Werde bei dem Thema IPv6 weiter am Ball bleiben; interessantes Thema

 

[Barungar]

Das klingt doch gut, dann viel Spaß (auch beim weiteren Einlernen in IPv6)!