라우터 또는 위임된 리졸버가 의도한 A 및 AAAA 응답을 올바른 클라이언트 네트워크에 제공하고 클라이언트가 두 주소 체계 모두에 해당 리졸버를 실제로 사용하는 경우에는 그렇습니다.
내부 호스트 이름은 비공개 IPv4 및 IPv6 주소로 해석되고 공용 클라이언트에는 공용 응답이 제공되어야 할 때 진정한 호환성 문제가 발생합니다. 폐기 가능한 경로 또는 계정에서 시작하고, 이전에 작동하던 상태를 유지하며, 일회성 연결 테스트가 아니라 원래 워크로드를 기준으로 설계를 평가하세요.
지원되는 아키텍처와 위험한 아키텍처를 분리하세요
지원되는 분기는 하나의 권한 있는 정책에서 클라이언트별 A 및 AAAA 응답을 제공하는 것입니다. 반대 분기는 IPv6 클라이언트가 로컬 리졸버를 우회하거나 연결할 수 없는 글로벌 또는 ULA 주소를 받는 것입니다. 어느 분기를 변경하기 전에 버전, ID, 주소, 마운트 경로, 권한 및 현재 관찰 가능한 상태를 기록하세요.
관련 분할 DNS 뷰는 첫 번째 호환성 경계를 정의합니다. 이를 사용해 주장을 제한한 다음, 문서화된 기능이 전체 설계가 작동한다는 증거라고 간주하지 말고 이 정확한 홈 서버에서 동일한 동작을 확인하세요.
테스트 전에 판단 규칙을 작성하세요. 성공은 각 네트워크가 의도한 주소 체계를 받고 공용 헤어핀 없이 동일한 인증서 제공 서비스에 도달하는 것이어야 합니다. 실패에는 AAAA가 공용 또는 오래된 주소를 유출하는 경우, 클라이언트가 암호화된 외부 DNS를 사용하는 경우, IPv6 라우팅 및 방화벽 정책이 응답과 일치하지 않는 경우가 포함됩니다. 이렇게 하면 부분적인 연결이나 명령의 정상 종료를 종단 간 호환성으로 잘못 해석하는 것을 방지할 수 있습니다.
정확한 스토리지 및 네트워크 경로를 재현하세요
하나의 통제된 판별 기준을 사용하세요. 각 VLAN에서 A 및 AAAA를 조회하고, 실제로 사용된 리졸버를 확인한 다음, 테스트 중 공용 폴백을 비활성화한 상태에서 두 주소 체계를 통해 연결하세요. 변경된 구성 요소만 유일하게 가능한 원인이 되도록 클라이언트, 워크로드, 파일 세트, 계정 및 타이밍을 일정하게 유지하세요.
dnsmasq 주소 규칙을 사용해 이 경로에 중요한 두 번째 관찰 항목을 선택하세요. 트랜잭션의 양쪽을 모두 캡처하세요. 리졸버 또는 경로, 협상된 프로토콜, 프로세스 ID, 종료 상태, 지연 시간, 전송된 바이트 및 복구 이벤트를 기록해야 합니다.
제목에 명시된 수명 주기 이벤트(재생성, 재연결, 재마운트, 재시작, 장애 조치 또는 클라이언트 변경) 후 테스트를 반복하세요. 기존 소켓, 캐시 또는 자격 증명이 유지되는 동안에만 작동하는 설계는 통과한 것이 아닙니다.
dig A app.home @router
dig AAAA app.home @router
curl -4 https://app.home
curl -6 https://app.home
지속성, 시간 초과 및 복구 결과를 해석하세요
통과: 각 네트워크가 의도한 주소 체계를 받고 공용 헤어핀 없이 동일한 인증서 제공 서비스에 도달합니다. 이 상태를 만든 정확한 버전과 토폴로지를 저장하세요. 결론은 프로토콜의 모든 구현이 아니라 이러한 조건에 적용되기 때문입니다.
실패: AAAA가 공용 또는 오래된 주소를 유출하거나, 클라이언트가 암호화된 외부 DNS를 사용하거나, IPv6 라우팅 및 방화벽 정책이 응답과 일치하지 않습니다. 어느 기본 분기가 원인이라고 선언하기 전에 DNS, MTU, ID, 방화벽 상태, 스토리지 지연 시간 및 캐시된 세션과 같은 공유 종속성을 확인하세요.
예외: 잘못된 AAAA 재정의를 제거하고, 연결 가능한 응답 집합을 복원한 다음, 리졸버 알림과 IPv6 라우팅을 수정한 후 다시 활성화하세요. 반복 가능한 관찰을 통해 어느 경계에서 실패했는지 확인하기 전에는 권한을 확대하거나, 원본 데이터를 삭제하거나, 전송 보안을 약화하거나, 작동하는 스토리지를 교체하지 마세요.
복구 수준의 점검 후에만 설계를 유지하세요
관찰된 분기에 맞는 조치만 적용한 다음 원래 워크로드를 다시 실행하세요. 두 번의 관련 수명 주기와 예상 동시 부하에서 각 네트워크가 의도한 주소 체계를 받고 공용 헤어핀 없이 동일한 인증서 제공 서비스에 도달할 때만 설계를 유지하세요.
분할 수평선 DNS를 사용해 가장 가까운 종속 워크플로를 확인하세요. 새 설계가 활성화된 동안에도 해당 워크플로의 액세스, 타이밍 및 복구 동작은 변경되지 않아야 합니다.
AAAA가 공용 또는 오래된 주소를 유출하거나, 클라이언트가 암호화된 외부 DNS를 사용하거나, IPv6 라우팅 및 방화벽 정책이 응답과 일치하지 않으면 중지하고 저장된 상태로 돌아가세요. 다른 우회 방법을 추가하지 말고 타임스탬프, 정확한 버전, 경로 또는 마운트 증거 및 최소 재현 사례를 첨부해 에스컬레이션하세요.
IPv6 방화벽 규칙과 결과를 교차 확인하여 위험이 다른 네트워크, ID, 백업 또는 스토리지 계층으로 단순히 이동하지 않았는지 확인하세요.
따라서 듀얼 스택 분할 DNS에 대한 조건부 답변은 처음의 판단이지 무조건적인 예가 아닙니다. 관찰 가능한 통과 상태는 승인 기준이며, 실패 상태는 롤백 기준입니다.
FAQ
A 레코드는 작동하지만 AAAA가 앱을 중단시킬 수 있나요?
예. 많은 클라이언트가 IPv6를 우선 사용하므로 잘못된 AAAA 경로로 인해 IPv4를 시도하기 전에 실패할 수 있습니다.
브라우저의 보안 DNS가 라우터를 무시하나요?
그럴 수 있습니다. 클라이언트의 실제 리졸버를 확인하고 관리되는 장치에서 암호화된 DNS에 대한 정책을 정의하세요.
내부 IPv6에는 ULA와 글로벌 주소 중 무엇을 사용해야 하나요?
라우팅, DNS, 방화벽 및 인증서 이름이 일관되면 어느 쪽이든 작동할 수 있습니다. 실제 클라이언트 경로를 테스트하세요.
지원 및 팁
더 읽어보기

셀프 호스팅 갤러리에서 Apple Live Photo 페어링을 보존할 수 있나요?
Apple Live Photo 페어링을 위한 조건부 홈 서버 결정 가이드로, 통제된 테스트, 결과 해석, 롤백 및 핵심 FAQ를 포함합니다.

Google Takeout과 휴대폰 백업을 하나의 사진 라이브러리로 가져올 수 있나요?
사진을 한꺼번에 가져오기 위한 조건부 홈 서버 결정으로, 통제된 테스트, 결과 해석, 롤백 및 핵심 FAQ를 포함합니다.

Immich는 파일 소유권을 가져가지 않고 외부 라이브러리를 사용할 수 있나요?
Immich 외부 라이브러리 소유권을 위한 조건부 홈 서버 결정 가이드로, 통제된 테스트, 결과 해석, 롤백 및 핵심 FAQ를 제공합니다.

