BIND에서 권한 DNS 응답은 열어 두고 재귀 질의는 제한하는 설정

BIND에서 allow-query는 이름 서버에 질의를 보낼 수 있는 클라이언트를 제어하고, allow-query-cache와 allow-recursion은 로컬 캐시·재귀 사용 범위를 통제합니다. 공개 권한 응답과 내부 재귀를 분리하려면 둘을 같은 권한으로 취급하지 말아야 합니다.

recursion no;는 새 재귀 작업을 중단하지만, 이미 캐시에 있는 응답의 제공과 모든 ACL 결과를 단독으로 설명하지는 않습니다. 실제 응답은 버전, options/view/zone 블록과 개별 ACL을 함께 확인해야 합니다.

권한 응답과 재귀 해결은 서로 다른 일입니다

공개 authoritative DNS 서버는 자신이 맡은 zone의 레코드를 답하면서 외부 사용자를 대신해 다른 도메인을 찾아 주지 않도록 구성할 수 있습니다. 여기서 allow-query는 서버 또는 해당 zone에 질의를 보낼 수 있는 클라이언트를 다룹니다. 반면 allow-query-cache는 로컬 캐시에 접근하는 호스트를 제한하고, BIND의 allow-recursion은 재귀 질의를 허용할 클라이언트를 정의합니다. 권한 zone 데이터에 묻는 것과 서버에 외부 이름의 답을 대신 찾아 달라고 요청하는 것은 구분해야 합니다.

options {
    recursion yes;
    allow-query { any; };
    allow-query-cache { 10.24.0.0/16; localhost; };
    allow-recursion { 10.24.0.0/16; localhost; };
};

zone "example.net" {
    type primary;
    file "db.example.net";
    allow-query { any; };
};

가상 설정은 질의 종류와 주소 범위를 나눠 읽습니다

예시에서 zone의 allow-query { any; };는 그 zone에 대해 일반 질의를 허용하는 설정입니다. options의 cache·recursion ACL에 외부 주소가 없으므로 외부 요청자는 재귀 서비스 권한을 얻지 않습니다. 단, 위 표는 각 요청이 해당 view와 zone에 실제로 도달한다는 가정을 둔 교육용 판독입니다. BIND의 view는 클라이언트에 따라 다른 데이터와 정책을 제공할 수 있으며, zone에 지정한 allow-query는 options의 해당 설정을 덮어쓸 수 있습니다. 그러므로 설정 파일에서 같은 단어를 검색하는 데 그치지 말고 실제 요청이 선택할 view와 zone을 추적해야 합니다.

recursion no만으로 캐시 응답까지 설명하지 않습니다

안정판 참조 문서는 recursion no;일 때 새 재귀를 수행하지 않고, 이미 아는 답이 없으면 referral을 반환한다고 설명합니다. 또 이 지시문만으로 캐시에 있던 응답까지 막지는 않는다고 명시합니다. 기본 allow-query-cache는 recursion 설정과 별도 ACL 여부에 따라 달라지며, 명시한 ACL도 함께 적용됩니다. 따라서 recursion no와 allow-query를 cache ACL과 같은 의미로 읽으면 안 됩니다.

1. 실제 실행 중인 named 버전과 적용 중인 설정 파일을 확인합니다.
2. 클라이언트 주소에 매칭되는 view가 있는지, 그 순서와 match-clients 조건을 확인합니다.
3. 해당 view의 recursion, allow-query-cache, allow-recursion 및 관련 *-on 설정을 읽습니다.
4. 질의할 zone의 allow-query와 options/view에서 상속·대체되는 값을 확인합니다.
5. 권한 데이터, cache 응답, 새 재귀 요청을 분리해 승인된 시험 질의 결과와 로그를 기록합니다.

일반 질의 ACL과 재귀 ACL을 하나로 읽지 않습니다

흔한 실수는 allow-query { any; };를 발견하고 외부에 열린 재귀 서버라고 바로 판단하는 것입니다. 이 설정은 해당 블록에서 질의를 허용하는 범위를 말하며, cache 접근과 재귀 허용은 각각 다른 설정과 기본값을 확인해야 합니다. 반대로 allow-recursion만 제한했다고 공개 zone 질의가 반드시 차단되는 것도 아닙니다. 어느 요청을 어느 view와 zone이 처리했는지, 질의가 권한 데이터인지 캐시인지 재귀인지까지 구분하세요.

설정 블록에서 클라이언트와 요청 종류를 교차합니다

검토표를 만들 때 행에는 클라이언트 주소와 요청 유형을 쓰고 열에는 view, allow-query, cache ACL, recursion 설정을 둡니다. 먼저 view 매칭을 끝낸 뒤에만 하위 설정을 읽으면, 기본 options 값을 잘못 적용하는 일을 줄일 수 있습니다. 결과란에는 ‘허용’뿐 아니라 어느 문서 조건으로 판단했는지 적습니다. 이 절차는 접근 제어 판독 연습이며 운영 정책을 바꾸는 지시가 아닙니다.