Varför uppdaterar Dynamic DNS fel offentlig adress?

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Dynamic DNS uppdaterar fel adress när uppdateraren observerar ett annat gränssnitt eller internetutgång än vad fjärrklienter måste nå.

I ett hemnätverk kan routern rapportera en privat WAN-adress bakom en annan gateway, en serverbaserad uppdaterare kan se en VPN- eller proxyutgång, en IPv6-uppdaterare kan skriva över en IPv4-post, eller två klienter kan uppdatera samma värdnamn från olika platser. Diagnosen börjar med att välja en offentlig adress som sanningskälla och sedan identifiera exakt vilken uppdaterare, post, adressfamilj och detektionsmetod som producerade fel värde.

Jämför tre adresser samtidigt

Registrera DDNS-posten, routerns WAN-adress och den offentliga adress som observeras av en extern IPv4- eller IPv6-tjänst. Lägg till tidsstämplar så att en legitim nylig ändring inte misstas för en felaktig uppdatering.

Ett fall i TP-Link-communityn visade en router som rapporterade en adress från en leverantörs NAT-pool medan internet utanför såg en annan adress, vilket lämnade DDNS-värdnamnet pekande på fel WAN-sida-adress.

Om alla tre matchar är problemet troligen DNS-cache eller fjärråtkomst snarare än uppdateringsvärdet. Om DDNS-posten matchar routern men inte den externa adressen, undersök upstream NAT; om den inte matchar någon av dem, granska uppdaterarens konfiguration och loggar.

Identifiera hur uppdateraren detekterar adressen

Fastställ om DDNS-klienten läser ett namngivet gränssnitt, frågar routern, tolkar en lokal gateway, använder källadressen för uppdateringsförfrågan eller frågar en extern ”vad är min IP”-tjänst.

En diskussion i Zyxel-communityn frågar varför en brandvägg bakom en annan NAT-router inte kan automatiskt uppdatera den verkliga offentliga adressen när den bara känner till upstream privat WAN-adress.

Välj extern detektion när uppdateraren sitter bakom NAT och leverantören stödjer det. Välj gränssnittsdetektion endast när det gränssnittet faktiskt äger den offentliga adressen; annars kan en fullt fungerande uppdaterare publicera fel värde av design.

Kontrollera för dubbel NAT och CGNAT

Undersök om routerns WAN-adress ligger inom ett privat eller delat intervall och om en annan modem eller ISP-gateway utför den första NAT. Dynamic DNS kan publicera en adress, men kan inte skapa inkommande vidarebefordran genom ett upstream-nätverk du inte kontrollerar.

Ett tyskt Synology-supportforum rapporterade att leverantörs-NAT orsakade att DDNS upptäckte en adress som inte var den faktiska offentliga slutpunkten.

Om du kontrollerar upstream-routern, placera downstream-routern i bryggläge eller vidarebefordra den nödvändiga vägen genom båda lagren. Om ISP använder CGNAT, begär en offentlig adress eller använd en utgående tunnel eller relä istället för att upprepade gånger ändra DDNS-klienten.

-15% OFF
Single board computer zimaboard2

Separera IPv4- och IPv6-uppdateringar

Granska A- och AAAA-posterna oberoende och jämför varje med ett externt test för samma adressfamilj. Anta inte att en lyckad IPv6-uppdatering bevisar att IPv4-posten är korrekt.

En klient konfigurerad för att övervaka ett gränssnitt kan publicera en temporär IPv6-adress, en delegerad prefixadress som senare ändras, eller en IPv4-adress från en VPN-utgång. Håll separata uppdateringsjobb och leverantörsposter när adressfamiljerna har olika livscykler.

Inaktivera endast den misstänkta adressfamiljens uppdatering och upprepa testet. Om fjärråtkomsten återställs när den felaktiga AAAA- eller A-posten tas bort, åtgärda den vägen innan du återställer dual-stack DNS.

Hitta dubblettklienter och felaktiga postmål

Lista varje router, NAS, container, skript, molnhost och mobil enhet som har behörighet att uppdatera värdnamnet. Två giltiga klienter på olika platser kan upprepade gånger skriva över varandra.

Dynu-användare har dokumenterat fall där en uppdateringsklient orsakade flera poster att dela en IP eftersom kontot eller klientkonfigurationen riktade fler poster än avsett.

Ge varje plats och adressfamilj ett distinkt värdnamn, token och uppdateringsjobb. Återkalla oanvända behörigheter och bekräfta att loggen namnger exakt vilken post som ändras innan du litar på ett framgångsmeddelande.

Verifiera posten genom en verklig adressändring

Efter att ha korrigerat detektionsmetoden och uppdaterarens ägarskap, tvinga en säker WAN-återanslutning eller vänta på nästa legitima adressändring. Registrera den nya externa adressen, uppdateringsloggen, auktoritativ DNS-svar, rekursivt resolver-svar och resultatet av fjärranslutningen.

ZimaSpace-guiden till varför fjärråtkomst följer gammalt IP-tillstånd ger nästa steg efter att DDNS-värdet självt blivit korrekt.

Problemet är löst först när en godkänd uppdaterare publicerar rätt IPv4- eller IPv6-adress, ingen annan klient skriver över den, det auktoritativa svaret ändras inom förväntad tidsram och en extern klient når den avsedda hemservicen.

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.