일부 도메인을 블랙리스트에 추가하기 위해 RPZ를 사용하고 있습니다. 구성은 다음과 같습니다.
*.com A 127.0.0.1
mydomain.net A 127.0.0.1
도메인 이름 .com을 쿼리하면 제대로 작동하고 127.0.0.1이 표시됩니다.
dig fun.com @localhost
내 대답은 다음과 같습니다 .
;; ANSWER SECTION:
fun.com. 5 IN A 127.0.0.1
이제 이전 구성을 편집하고 내 영역을 다음과 같이 만들어 보겠습니다.
*.com A 127.0.0.1
mydomain.net A 127.0.0.1
this.fun.com 127.0.0.1
기본 서버가 모든 경우를 처리해야 하므로 이는 불필요 *.com
하지만 내 도메인은 여러 소스에 의해 로드되므로 목록이 자동으로 컴파일되고 이와 같은 일이 발생할 수 있습니다.
이는 무해한 변경처럼 보이지만 이렇게 하면 dig this.fun.com @localhost
다시 다음과 같이 응답합니다.
;; ANSWER SECTION:
this.fun.com. 5 IN A 127.0.0.1
지금 루트 도메인을 쿼리하면 다음과 같은 dig fun.com @localhost
결과를 얻습니다.
;; ANSWER SECTION:
fun.com. 86400 IN A 209.61.131.188
무엇처럼? 여기서 무슨 일이 일어나고 있는 걸까요? 상위 전체 패키지에서 this.fun.com
보호된 기본 도메인을 추가하시겠습니까?fun.com
*.com
이것이 바인딩의 원하는 동작입니까? 이상한 버그를 발견했나요?
이 상황을 피하는 방법은 무엇입니까? 더 큰 도메인에 포함된 도메인을 제거하면서 모든 도메인에 걸쳐 반복되는 스크립트를 작성해야 합니까? (귀찮지만 가능함 - 더 나은 대안을 찾고 있음)
핵심요약: 두 번째 수준 도메인이 기본 필터로 인한 화이트리스트를 따르지 않도록 바인딩 rpz에 세 번째 수준 도메인을 추가하여 블랙리스트에 추가하세요.
답변1
BIND RPZ 동작 및 정규 표현식: *.com
아래의 모든 DNS 하위 도메인을 블랙리스트에 추가합니다 com
.하지만루트 도메인 자체를 블랙리스트에 추가 하려면 com
rpz 파일에 다음을 추가해야 합니다.
com
그래서 rpz 목록에 com을 추가하지 않으면 해결됩니다. 당신이 설명하는 것은 정상적인 행동입니다.
RPZ 블랙리스트 파서는 적어도 리소스를 절약하기 위해 하나 작성하는 것이 좋습니다. BIND는 해시 테이블을 사용하므로 런타임에 미치는 영향은 최소화되어야 하지만 BIND를 다시 시작할 때(예: BIND가 RPZ 테이블을 읽고 구문 분석할 때) RPZ 테이블 읽기 지연이 눈에 띄고 약간 더 많은 메모리를 사용합니다. 나는 아직 그런 파서를 작성하지 않았습니다현재.