두 사이트, 하나의 사설 DNS 영역: 레코드는 누구 것인가?

녹색 사이트에 호스트를 추가하면 녹색 사용자에게는 확인되지만 노란 사무실은 여전히 NXDOMAIN을 받습니다. 이것은 VPN 장애도 아니고 고장 난 리졸버도 아니며, 사설 영역 안의 소유권 공백입니다. 따로 편집된 두 레코드 목록은 사이트끼리 서로 도달할 수 있다는 이유만으로 하나의 영역이 되지 않습니다. 해결책은 게시 계획이지 또 하나의 방화벽 규칙이 아닙니다.

증상은 사라진 소유자를 지목한다

아마 각 사이트에는 누군가 이름이 필요할 때 추가한 로컬 재정의, Pi-hole 항목 또는 dnsmasq 줄이 있을 것입니다. 녹색 레코드는 녹색 리졸버에만 있으므로 노란 사이트의 클라이언트는 자기 리졸버에 질의하고 진실한 "그런 이름 없음" 응답을 받습니다. 오래된 응답은 다르게 보입니다: 호스트가 옮겨졌고 한 사이트는 사본을 갱신했지만 다른 사이트는 여전히 옛 주소를 돌려줍니다.

두 패턴 모두 캐시를 비우는 것으로 오래 해결되지 않습니다. 전달 리졸버의 캐시는 언젠가 받은 응답의 사본이며 새 이름을 게시하는 권한이 아니므로, 오늘 동작하는 캐시는 내일의 호스트에 대해 아무것도 말해 주지 않습니다. BIND 문서가 기본·보조·재귀·전달 역할을 따로 설명하는 이유가 바로 이것입니다.

그래서 설계 질문은 좁고 답할 수 있습니다: 누가 레코드를 만들 수 있으며, 그 레코드는 그것에 답해야 하는 모든 리졸버에 어떻게 도달하는가?

선택지 A: 보조 서버가 있는 단일 권한 영역

internal.example.com 에 대한 기본 서버를 운영하고 지원되는 보조 서버가 각 사이트에서 영역을 가져가게 하십시오. 각 사이트의 재귀 리졸버는 자기 로컬 보조 서버에 질의하므로 응답은 캐시가 아니라 권한 있는 원본에서 오고, 한 번 한 변경은 다시 입력되지 않고 전송됩니다.

그 구성에는 미루기 쉽고 빠뜨리면 비싼 명시적 결정이 필요합니다. 누가 영역을 편집할 수 있는가? 어느 서버가 그것을 전송할 수 있으며 어떤 주소로 하는가? 사이트 사이의 터널이 끊긴 동안 클라이언트는 무엇을 보아야 하는가? 보조 서버는 마지막 사본에서 계속 응답하며 이는 보통 원하는 동작이지만, 장애 중의 뜻밖의 일이 아니라 선언된 선택이어야 합니다.

영역 전송을 주소로 알려진 보조 서버로 제한하고 구현이 지원하는 곳에서는 트랜잭션 서명을 사용하십시오. 열린 전송은 포트에 도달할 수 있는 누구에게나 내부 이름 공간의 사본입니다.

비용은 조정입니다: 하나의 편집 경로, 하나의 변경 검토, 그리고 레코드가 틀렸을 때 누가 대기하는지에 대한 공유된 이해입니다.

선택지 B: 사이트마다 하위 도메인

green.internal.example.com 을 녹색 사이트에, yellow.internal.example.com 를 노란 사이트에 위임하십시오. 각 사이트는 자기 이름에 대해 권한을 갖고, 상위 영역은 위임 레코드만 담습니다. 한 파일을 둘러싼 다툼이 사라지고, 현지 팀은 중앙 변경을 기다리지 않고 호스트를 추가할 수 있습니다.

위임은 상위 영역에 있어야 하며 사이트의 권한 있는 서버를 가리키는 NS 레코드가 있어야 합니다. 완전한 위임이 비현실적일 때 하위 도메인에 대한 조건부 전달은 유효한 대안이지만, 그것은 게시된 사실이 아니라 리졸버 설정이므로 모든 리졸버에 같은 규칙이 필요합니다.

비용은 사라지지 않고 옮겨갑니다: 상위 영역에는 여전히 소유자가 필요하고, 새 사이트를 만드는 일은 이제 한 곳이 아니라 두 곳의 변경입니다.

모든 리졸버가 선택을 따르게 하십시오

지원되는 구성으로 클라이언트에 승인된 리졸버와 검색 도메인을 주고, 다음을 확인하십시오. 리졸버가 질의해야 하는 모든 원격 DNS 서버로 가는 허용된 VPN 경로를 가지고 있는지. 또한 올바른 이름이라도 경로가 없으면 여전히 끊긴 연결이므로, 애플리케이션에는 그 응답이 돌려주는 사설 주소로 가는 경로가 필요합니다.

Pi-hole이 로컬 확인을 제공한다면 어떤 레코드를 소유하고 어떤 질의를 전달하는지 적어 두십시오. 따로 편집된 두 Pi-hole 목록은 여전히 복제되지 않습니다. Pi-hole v6에서는 사용자 지정 dnsmasq 줄을 TOML, CLI 또는 환경 변수 같은 호스트 측 옵션으로 설정하며 API로는 노출되지 않으며, /etc/dnsmasq.d/ 파일을 불러오는 것은 기본적으로 꺼져 있는 별도 옵션입니다.

그런 다음 어디서나 보여야 하는 이름으로 양쪽에서 시험하십시오.

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA 응답은 노란 리졸버가 스스로를 권한 있다고 여기는지, 보조 서버에 질의하는지, 아니면 그저 전달하는지를 알려 줍니다. 이들은 실패 방식이 다른 서로 다른 설계이며, 응답은 보통 실제로 배포한 것이 어느 것인지 알려 줍니다.

세 가지 인수 사례로 마무리하십시오: 각 사이트에서 온 이름 하나, 한 시간 안에 바뀐 레코드 하나, 사이트 사이 링크를 사용할 수 없음. 첫 번째만 통과하는 설계는 종이 위의 게시 계획과 운영 환경의 로컬 재정의를 가진 것입니다.