Sì, se il router o il resolver delegato fornisce le risposte A e AAAA previste alle reti client corrette e i client utilizzano effettivamente quel resolver per entrambe le famiglie.
Questa diventa una vera questione di compatibilità quando i nomi host interni devono risolversi in indirizzi IPv4 e IPv6 privati, mentre i client pubblici ricevono risposte pubbliche. Inizia con un percorso o un account usa e getta, mantieni disponibile lo stato precedente funzionante e valuta il progetto in base al carico di lavoro originale, non in base a un test di connessione eseguito una sola volta.
Separa l'architettura supportata da quella rischiosa
Il ramo supportato prevede risposte A e AAAA specifiche per client provenienti da un'unica policy autorevole. Il ramo alternativo prevede che i client IPv6 aggirino il resolver locale o ricevano un indirizzo globale o ULA irraggiungibile. Registra versioni, identità, indirizzi, percorsi di montaggio, autorizzazioni e stato attualmente osservabile prima di modificare uno dei due rami.
Le viste DNS split rilevanti definiscono il primo limite di compatibilità. Usale per circoscrivere l'affermazione, quindi verifica lo stesso comportamento su questo server domestico specifico invece di considerare una funzionalità documentata come prova che l'intero progetto funzioni.
Scrivi la regola decisionale prima del test: il successo deve fare sì che ogni rete riceva la famiglia di indirizzi prevista e raggiunga lo stesso servizio con certificato senza hairpinning pubblico; il fallimento include un record AAAA che espone un indirizzo pubblico o obsoleto, client che utilizzano DNS esterno crittografato oppure routing IPv6 e policy firewall che non corrispondono alla risposta. Questo impedisce di interpretare erroneamente una connessione parziale o l'uscita corretta di un comando come compatibilità end-to-end.
Riproduci esattamente il percorso di archiviazione e rete
Usa un solo elemento discriminante controllato: interroga i record A e AAAA da ogni VLAN, controlla quale resolver viene effettivamente utilizzato, quindi connettiti tramite entrambe le famiglie con il fallback pubblico disabilitato durante il test. Mantieni costanti client, carico di lavoro, set di file, account e tempistiche, in modo che il componente modificato sia l'unica spiegazione plausibile.
Usa le regole degli indirizzi dnsmasq per scegliere la seconda osservazione importante per questo percorso. Acquisisci entrambi i lati della transazione: resolver o route, protocollo negoziato, identità del processo, codice di uscita, latenza, byte trasferiti ed eventuali eventi di ripristino.
Ripeti il test dopo l'evento del ciclo di vita indicato nel titolo: ricreazione, riconnessione, nuovo montaggio, riavvio, failover o cambio di client. Un progetto che funziona solo mentre socket, cache o credenziali precedenti rimangono attivi non ha superato il test.
dig A app.home @router
dig AAAA app.home @router
curl -4 https://app.home
curl -6 https://app.home
Interpreta i risultati di durata, timeout e ripristino
SUPERATO: ogni rete riceve la famiglia di indirizzi prevista e raggiunge lo stesso servizio con certificato senza hairpinning pubblico. Salva le versioni esatte e la topologia che hanno prodotto questo stato, perché la conclusione si applica a queste condizioni e non a ogni implementazione del protocollo.
FALLITO: il record AAAA espone un indirizzo pubblico o obsoleto, i client utilizzano DNS esterno crittografato oppure routing IPv6 e policy firewall non corrispondono alla risposta. Controlla le dipendenze condivise, come DNS, MTU, identità, stato del firewall, latenza dello storage e sessioni memorizzate nella cache, prima di attribuire la responsabilità a uno dei due rami principali.
ECCEZIONE: rimuovi l'override AAAA errato, ripristina un set di risposte raggiungibile e correggi l'annuncio del resolver e il routing IPv6 prima di riattivarlo. Non ampliare i privilegi, eliminare i dati sorgente, indebolire la sicurezza del trasporto o sostituire lo storage funzionante finché un'osservazione ripetibile non identifica quale limite ha fallito.
Mantieni il progetto solo dopo una verifica adatta al ripristino
Applica solo l'azione corrispondente al ramo osservato, quindi esegui nuovamente il carico di lavoro originale. Mantieni il progetto solo quando ogni rete riceve la famiglia di indirizzi prevista e raggiunge lo stesso servizio con certificato senza hairpinning pubblico per due cicli di vita rilevanti e sotto il carico simultaneo previsto.
Usa il DNS split-horizon per verificare il flusso di lavoro dipendente più vicino. Il suo comportamento in termini di accesso, tempistiche e ripristino deve rimanere invariato mentre il nuovo progetto è attivo.
Arresta il processo e torna allo stato salvato se il record AAAA espone un indirizzo pubblico o obsoleto, i client utilizzano DNS esterno crittografato oppure routing IPv6 e policy firewall non corrispondono alla risposta. Inoltra il problema con timestamp, versioni esatte, prove relative a route o mount e la riproduzione minima, invece di aggiungere un'altra soluzione alternativa.
Confronta il risultato con le regole firewall IPv6 per evitare che il rischio venga semplicemente trasferito a un altro livello di rete, identità, backup o storage.
Per il DNS split dual-stack, la risposta corretta è quindi il giudizio iniziale, non un sì incondizionato. Lo stato osservabile di superamento è la riga di accettazione; lo stato di fallimento è la riga di rollback.
FAQ
Un record A può funzionare mentre AAAA interrompe il funzionamento dell'app?
Sì. Molti client preferiscono IPv6, quindi un percorso AAAA errato può fallire prima che venga provato IPv4.
Il DNS sicuro del browser ignorerà il router?
Può farlo. Conferma il resolver effettivo del client e definisci una policy per il DNS crittografato sui dispositivi gestiti.
Per l'IPv6 interno è meglio usare indirizzi ULA o globali?
Entrambi possono funzionare quando routing, DNS, firewall e nomi dei certificati sono coerenti; verifica il percorso effettivo del client.
Supporto e consigli
Altro da leggere

Una galleria autogestita può preservare l'abbinamento delle Live Photo di Apple?
Una decisione condizionale sul server domestico per l'associazione delle Live Photo di Apple, con test controllati, interpretazione dei risultati, ripristino e domande frequenti mirate.

Puoi importare Google Takeout e i backup del telefono in un'unica libreria fotografica?
Una decisione condizionata per un home server dedicato all'importazione combinata di foto, con test controllati, interpretazione dei risultati, rollback e FAQ mirate.

Immich può utilizzare una libreria esterna senza acquisire la proprietà dei file?
Una decisione condizionale per home server sull'assegnazione della proprietà delle librerie esterne di Immich, con test controllati, interpretazione dei risultati, rollback e FAQ mirate.

