Interne DNS Auflösung scheitert für gewisse Zeit, wenn virtuelle Maschine den Host wechselt

Puh schwieriges Thema, bleibt den die IP für den HA Proxy gleich, wenn er auf den anderen Node migriert?

Wenn ja müssen halt die Routen wieder neu aufgebaut werden. Ich weiß nicht wie Proxmox das announced.

Aber generell geht das nicht ohne Zeitverlust was du beschreibst passt schon.

Wenn der Loadbalancer/Proxy migriert ist halt blöd.

Währe wohl auch die erste frage.

Bleibt die IP gleich ? genauer, bleibt die MAC die gleiche, so das bei einem rebind die Kiste vom DHCP die gleiche IP bekommt ?

Wie wird der Hostname dem DNS bekannt gemacht ? Ist das 100% Unifi ? Dann wird der Hostname aus dem DHCP Request
des Client übernommen (sofern der Cleint das natürlich auch setzt)

Wen du aber mit dem gleichen Hostname sendest die Kiste aber Plötzlich ne andere MAC / IP hat dann gib es zwei Einträge
wo ggf der alte noch ne weile benutzt wird.

+

Dein Client mit dem zu zugreifst...DNS Cache könnte dazwischen funken. Wobei wenn ich das richtig sehe haben
die Unifi DNS Einträge alle max 5 Sekunden "Cache Lebensdauer"

chatgpt sagt: Das Fehlerbild bei „proxmox“ ist der entscheidende Hinweis:

• Es ist nicht „DNS zeigt noch auf die alte IP“, sondern „Host nicht gefunden“ (NXDOMAIN).
• Und dass es dann 5–10 Minuten dauert, passt extrem gut zu negativem DNS-Caching (Windows cached NXDOMAIN standardmäßig eine Weile; viele Resolver/DNS-Server cachen negative Antworten ebenfalls).

Heißt: In dem Moment, wo du nach der Migration einmal „proxmox“ auflöst und NXDOMAIN bekommst, kann dein Windows (und ggf. auch andere Resolver im Netz) genau dieses „gibt’s nicht“ für Minuten merken – selbst wenn der UDM-DNS kurz danach wieder korrekt wäre.

1) Sofort verifizieren: Ist es Windows-Cache oder UDM-DNS?

Wenn es wieder passiert, nicht nur ping, sondern gezielt:

Auf Windows (Client):

nslookup proxmox.home.internal 192.168.20.1
nslookup proxmox 192.168.20.1

• Wenn nslookup auch sagt Non-existent domain → UDM liefert NXDOMAIN (oder cached es).
• Wenn nslookup korrekt eine IP liefert, aber ping proxmox sagt „Host nicht gefunden“ → Windows cached negativ (oder nutzt einen anderen Resolver als gedacht).

Dann direkt testen:

ipconfig /flushdns

und danach nochmal ping proxmox.

Wenn es sofort wieder geht, ist es zu ~90% negatives Caching auf dem Client (getriggert durch eine kurze NXDOMAIN-Phase).

Zusatzcheck:

Resolve-DnsName proxmox.home.internal -Server 192.168.20.1

2) Warum kommt NXDOMAIN überhaupt kurzzeitig?

Bei UniFi/UDM ist die lokale Namensauflösung für .home.internal typischerweise an DHCP-Leases/Client-„Hostnamen“ gekoppelt (sinngemäß: Lease/Client bekannt → A-Record wird erzeugt).

Bei einer HA-Migration im „Restart Mode“ passiert oft kurz:

• Container ist weg → UDM „sieht“ Client kurz nicht / Lease-Zuordnung wackelt → Record verschwindet oder wird als „nicht existent“ beantwortet
• Container kommt wieder → DHCP erneuert → Record kommt zurück

Wenn du in genau diesem Fenster auflöst: NXDOMAIN → negative Cache → 5–10 Minuten „kaputt“.

Dass „db“ es manchmal nicht zeigt, kann einfach daran liegen, dass du da nicht in dieses Fenster hinein aufgelöst hast (oder du hattest keinen negativen Cache-Eintrag).

3) Robustester Fix: DHCP-Reservation + „Local DNS Record“ / statischer Record

Damit der Name nicht vom flüchtigen DHCP-Status abhängt:

1. DHCP Reservation auf der UDM für die MAC des Containers (hast du ja stabil).
2. Zusätzlich (wenn verfügbar in deiner UniFi Network Version):
   • Local DNS Record: proxmox.home.internal → 192.168.20.82
   • und ggf. proxmox → 192.168.20.82 (wenn du auch unqualifiziert auflösen willst)

Dann ist es egal, ob der Client kurz „weg“ ist: Der DNS-Record bleibt stabil.

Falls deine UniFi-Version keine „Local DNS Records“ sauber kann:
→ Ein eigener DNS (Pi-hole / Unbound / dnsmasq) mit statischen A-Records für die HA-VIPs/HA-Container ist in solchen Setups oft die sauberste Lösung.

4) Workaround/Debug: Verhindern, dass du den negativen Cache triffst

• Wenn es passiert: ipconfig /flushdns
• Und schau dir an, ob Windows überhaupt nur den UDM fragt:
  • ipconfig /all → DNS-Server prüfen (nicht, dass noch ein anderer Resolver drinsteht)
• Du kannst auch mal testweise direkt die FQDN-Auflösung nur gegen 192.168.20.1 laufen lassen (wie oben).

5) Der wichtigste Vergleich zwischen „db“ und „proxmox“

Wenn du Unterschiede suchst, konzentrier dich auf genau diese Punkte:

• Haben beide Container wirklich DHCP und denselben DHCP-Client? (Alpine: udhcpc, Debian: dhclient/systemd-networkd/etc.)
• Senden beide beim DHCP REQUEST zuverlässig den Hostname? (UDM baut daraus oft den DNS-Namen)
• Haben beide evtl. in UniFi eine unterschiedliche Behandlung (Client „fixed IP“, „use fixed IP“, „hostname override“, „insights“)?

Praktischer Test im Problemzeitfenster:
Wenn nslookup proxmox.home.internal 192.168.20.1 NXDOMAIN liefert, mach parallel ein:

# im Container direkt nach dem Start
hostname
ip a
udhcpc -n -q   # (je nach Alpine-Konfiguration; nur als Test)

(„-n“ = exit wenn keine Lease; „-q“ = quiet – je nach BusyBox-Version)

Wenn du mir zwei Outputs aus dem Fehlerfenster gibst, kann ich es sehr sicher zuordnen:

1. Windows: nslookup proxmox.home.internal 192.168.20.1 (während es „kaputt“ ist)
2. Windows: ipconfig /displaydns | findstr /i proxmox (zeigt, ob NXDOMAIN gecached ist)

Aber auch ohne das: Statische DNS-Records (oder eigener DNS) + DHCP-Reservation ist der Weg, der solche HA-Migrationen zuverlässig „DNS-stabil“ macht.

Manchmal hat es lichte Momente:

Danke, das ist jetzt richtig aussagekräftig – und es kippt die Diagnose deutlich:

Was deine nslookup-Ausgabe wirklich bedeutet

nslookup proxmox.home.internal 192.168.20.1 zeigt nur

Name: proxmox.home.internal

aber keine Address:-Zeile und auch kein „Non-existent domain“.

Das ist typisch für NOERROR / NODATA:
Der DNS-Server sagt sinngemäß: „Domain existiert, aber ich habe gerade keinen A-Record (IPv4) dafür.“

Und genau deshalb scheitert ping proxmox.home.internal mit „Host nicht finden“: es gibt gerade keine verwertbare A/AAAA-Antwort.

➡️ Wichtig: Damit ist es kein Windows-Cache-Thema mehr. Du fragst den UDM-DNS direkt, und der liefert leer.

Warum kann das bei „identischem Setup“ unterschiedlich sein?

Bei UniFi/UDM ist die lokale DNS-Antwort für Clients sehr oft an DHCP + “Client/Hostname”-Zuweisung gekoppelt (Lease → Name → DNS). Zwei typische Gründe, warum das bei einem Container klappt und beim anderen “flattert”, obwohl es auf Proxmox-Seite gleich aussieht:

1) Der Container sendet (zeitweise) keinen Hostname per DHCP

Dann hat der UDM zwar ein Lease/IP/MAC, aber er erzeugt/behält keinen DNS-Namen dafür (oder droppt ihn kurzfristig → NODATA).

Warum „zeitweise“?
Bei Restart/Migration kommt das Interface neu hoch. Manche DHCP-Clients (und gerade BusyBox/udhcpc-Konstellationen) schicken den Hostname nicht immer gleich, oder erst nach hostname//etc/hostname gesetzt ist.

Check im kaputten Fenster (im Container „proxmox“):

hostname
cat /etc/hostname
ps | grep udhcpc
ip a

Harte Abhilfe auf Alpine (damit der Hostname garantiert im DHCP-Request landet):

In /etc/network/interfaces (Alpine ifupdown-ng) kann man das explizit setzen:

auto eth0
iface eth0 inet dhcp
    hostname proxmox

Wenn das auf deiner Alpine-Version nicht greift, dann über udhcpc-Optionen (variiert je nach Setup), z.B. per Hook-Skript oder rc-service. Ziel: Option 12 (hostname) immer senden.

Quote

Das erklärt auch „warum db geht“: dein „db“-Container sendet den Hostname zuverlässig → UDM erstellt A-Record stabil. Der andere nicht.

2) Hostname-Kollision / UniFi “Client Name”-Chaos bei „proxmox“

„proxmox“ ist bei dir sehr wahrscheinlich kein einzigartiger Name im Gesamtnetz:

• du hast Proxmox-Nodes (grobi/bert/…), aber viele Leute haben irgendwo noch proxmox als Alias,
• oder es gibt in UniFi bereits einen Client/Eintrag/Reserved Name „proxmox“,
• oder du hast irgendwo einen anderen DNS (Pi-hole/Windows/Router) der „proxmox“ schon kennt.

UniFi kann dann beim Re-Appearance des Clients kurzzeitig den Namen nicht zuordnen oder “umhängen” → Ergebnis: NODATA bis sich die Client-Datenbank wieder konsistent anfühlt.

Schneller Test:
Frag mal beim Fehler explizit nach A und AAAA:

nslookup -type=A proxmox.home.internal 192.168.20.1
nslookup -type=AAAA proxmox.home.internal 192.168.20.1

Und parallel in UniFi Network UI (Clients): gibt es mehr als einen Eintrag, der als Name „proxmox“ auftaucht oder früher auftauchte? Oder ist der HAProxy-Container dort plötzlich „Unknown“/ohne Namen?

Der pragmatische “Beweis”-Test (ohne Rätselraten)

Wenn es wieder “kaputt” ist, mach diese zwei Dinge:

A) Siehst du das Lease überhaupt?

Auf Windows:

nslookup 192.168.20.82 192.168.20.1

(Reverse Lookup; wenn der UDM PTR macht, siehst du, ob er den Client überhaupt sauber kennt.)

B) Funktioniert IPv4 erzwungen?

ping -4 proxmox.home.internal

Wenn -4 klappt, aber normales ping nicht, dann ist es ein AAAA/IPv6-Resolver-Edgecase.
Wenn -4 auch nicht klappt, dann fehlt wirklich der A-Record (passt zu deiner nslookup-Ausgabe).

Was ich an deiner Stelle als Fix machen würde (minimal-invasiv)

1. DHCP Reservation für den Container (hast du vermutlich)
2. Zusätzlich statischen DNS-Eintrag für proxmox.home.internal → 192.168.20.82 (falls UniFi das anbietet: “Local DNS Record”)
   → damit ist die Namensauflösung nicht davon abhängig, ob UniFi gerade “Client/Hostname aus DHCP” sauber zuordnet.
3. Und parallel: auf Alpine den Hostname explizit im DHCP mitsenden (siehe oben). Das ist der Teil, der die „warum nur einer“-Frage am wahrscheinlichsten beantwortet.

Wenn du mir noch ein einziges Detail lieferst, kann ich dir ziemlich sicher sagen, ob es 1) Hostname wird nicht gesendet oder 2) Kollision ist:

• Im kaputten Fenster: Ausgabe von
  nslookup -type=A proxmox.home.internal 192.168.20.1
  (die Zeilen nach „Name:“/„Addresses:“ sind entscheidend)

Aber selbst ohne das: Deine Daten zeigen klar UDM-DNS liefert NODATA, und der häufigste Grund dafür ist DHCP/Hostname-Zuordnung (inkl. Kollisionen) – nicht Proxmox selbst.