VPN 위의 BIND: 조건부 전달과 stub 존 중 무엇인가

사무실 리졸버는 하나의 기업 네임스페이스를 제외한 모든 질의에 응답하며, 그 네임스페이스를 아는 기업 DNS 서버는 VPN 뒤에 있습니다. BIND는 그 단일 존을 업스트림에 세 가지 방식으로 넘길 수 있고, 각각 실패 방식이 다릅니다. 조건부 전달은 가장 작은 약속이고, stub 존은 위임 데이터를 유지하며, secondary는 전체 복사본을 유지합니다. 먼저 찾은 설정 조각이 아니라 업스트림이 무엇을 허용하고 리졸버가 무엇을 보관하기를 원하는지로 고르십시오.

하나의 네임스페이스를 위한 세 가지 구성

조건부 전달: 가장 작은 약속

사무실 리졸버가 192.168.10.53에, 기업 서버가 10.40.0.53에 있고 승인된 터널로 도달할 수 있다고 가정합니다. 선언은 세 줄이고, 흥미로운 것은 forward only 입니다. 경로가 아니라 실패 방식을 바꾸기 때문입니다.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

forward only 을 두면 업스트림에 도달할 수 없을 때 반복 해석으로 되돌아가지 않고 이 존에 대해 SERVFAIL을 반환합니다. 사설 네임스페이스에서는 보통 이것이 원하는 동작입니다. 되돌아가면 사설 이름이 공용 리졸버로 전달되어 인터넷에서 쓸모없는 응답이 돌아오기 때문입니다. BIND 참조 문서 는 두 정책을 모두 설명하며, 그 차이는 설정 조각이 시사하는 것보다 중요합니다. 같은 이름의 기존 존을 교체하지 말고 존을 기존 구성에 병합하십시오.

stub 또는 secondary: 위임이 중요할 때

stub 존은 기업 서버에 존의 NS 레코드를 묻고 그다음 권한 있는 서버에 직접 질의합니다. 업스트림 영역이 크거나 세분화되어 있고 모든 것을 한 주소에 고정하는 대신 리졸버가 위임을 따라가기를 원할 때 선택하십시오. 대가는 NS 데이터의 최신성과 나열된 모든 네임서버가 리졸버의 원본 주소에서 도달 가능해야 한다는 의존입니다.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

secondary는 로컬 데이터로 응답하고 업스트림 장애를 견디며, 그것이 전송 의존을 받아들이는 이유입니다. 이는 리졸버가 이제 자기 것이 아닌 존의 복사본을 보관한다는 뜻이므로 파일 경로, 프라이머리의 전송 ACL, 갱신 타이머가 모두 운영 표면의 일부가 됩니다.

둘 사이를 가르는 확인

BIND는 자체 아웃바운드 질의를 생성하므로, 질문은 노트북이 10.40.0.53에 도달할 수 있는지가 아니라 리졸버 호스트가 기업 서버가 보게 될 원본 주소에서 도달할 수 있는지입니다. 먼저 커널에, 그다음 서버에 그 순서로 물으십시오.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

경로에서 UDP와 TCP를 모두 허용하십시오. 잘린 응답은 TCP를 강제하며, UDP만 허용하는 정책은 패킷 손실처럼 보이는 간헐적 실패를 만듭니다. 기업 측에는 리졸버 원본에 대한 허용 규칙과 그쪽으로 가는 반환 경로가 모두 필요합니다. 그 원본은 리졸버의 라우팅된 주소이거나 명시적으로 변환된 주소일 수 있고, 클라이언트 풀 주소인 경우는 드뭅니다. NS 질의가 실패하면 forward 존이 어떻게 동작하든 stub 존은 작동할 수 없습니다.

터널이 아니라 응답을 검증하십시오

한 번도 질의한 적 없는 이름을 사무실 리졸버를 통해 질의하고, 응답의 authority 섹션을 보고 기업 존에서 왔는지 확인하십시오. 캐시된 응답은 현재 경로에 대해 아무것도 증명하지 못하며, 업스트림에 대한 직접 질의 성공은 리졸버가 그 존을 선택했다는 것을 증명하지 못합니다. 같은 질의를 TCP로 반복해 경로가 잘림을 견디는지 확인하십시오.

클라이언트를 사무실 리졸버로 향하게 유지하십시오, 그리고 DNSSEC 검증은 켜 둡니다. 독립적인 암호화 리졸버로 구성된 브라우저는 이 구성을 완전히 우회하며, 예상치 못한 응답이 올바르게 보이도록 검증을 끄는 것은 보이는 실패를 보이지 않는 실패와 맞바꾸는 일입니다.

세 유형 중 무엇을 선택했고 왜인지 적어 두십시오. 존이 실패하는 것을 보게 될 다음 사람에게는 구성 파일보다 그 문장이 더 필요합니다.