역할을 선택하세요
Unbound와 같은 재귀 리졸버와 AdGuard Home과 같은 필터링 인터페이스는 서로 관련되지만 구별되는 문제를 해결합니다. 서비스가 자체적으로 재귀하는지 업스트림으로 전달하는지 결정하고, 그에 따라 어느 당사자가 쿼리를 보게 되는지 이해하세요.
비공개로 유지하세요
제한 없는 공용 리졸버는 반사 공격에 악용될 수 있습니다. 사설 네트워크에 바인딩하거나 IPv6을 포함한 승인된 소스만 허용하세요. 암호화된 DNS을 사용하는 경우 HTTPS이 사설로 만들어 준다고 가정하지 말고 인증하거나 액세스를 적절히 제한하세요.
로깅 정책 설정
DNS 쿼리는 민감한 브라우징 및 애플리케이션 활동을 노출할 수 있습니다. 불필요한 보존을 비활성화하고, 보관하는 기록을 보호하며, 사용자에게 범위를 설명하세요. 암호화된 전송은 경로를 보호하지만 리졸버 자체가 쿼리를 보는 것을 막지는 않습니다.
둘 이상의 이름 테스트
활성화된 경우 DNSSEC 동작, IPv4 및 IPv6 결과, 필터링 예외 및 업스트림 실패 시 복구를 확인하세요. 복구 중인 리졸버에만 의존하지 않고 접근을 수정할 수 있는 안전한 방법을 유지하세요.
외부인이 조회할 수 없음을 입증하세요
리졸버를 의도한 인터페이스에 바인딩하고, 허용된 클라이언트 범위를 정의하며, 방화벽을 제한하세요. 재시작 전에 구성을 검증하세요. 승인된 클라이언트에서 쿼리한 다음 신뢰할 수 없는 네트워크 외부에서 반복하세요. 해당 요청은 거부되거나 시간 초과되어야 합니다. IPv6를 별도로 확인하세요. 임의의 인터넷 쿼리를 허용하는 리졸버는 남용의 원천이 될 수 있습니다.
- 변경 사항을 적용하기 전에 구성 검증기를 실행하세요
- 허용된 클라이언트와 거부된 클라이언트를 테스트하세요
- 상세 쿼리 진단은 임시로 유지
unbound-checkconf공식 문서: Unbound 액세스 제어 구성
암호화된 DNS 청구 내용을 정확하게 유지하세요
DNS-over-HTTPS 또는 DNS-over-TLS는 특정 전송 경로를 암호화합니다. 리졸버는 여전히 쿼리를 수신하며, 포워딩 리졸버는 이를 다른 운영자에게 전달할 수 있습니다. 업스트림 선택과 보존 정책을 검토하세요. 암호화된 리졸버 엔드포인트를 노출하는 경우, 일반 DNS 포트만큼 신중하게 접근 정책을 설정하세요.
포트를 열기 전에 리졸버 체인을 선택하세요
유용한 프라이빗 설계는 VPN 클라이언트가 AdGuard Home에 쿼리하고, AdGuard가 루프백의 Unbound로 전달하는 구성입니다. 그런 다음 Unbound가 재귀를 수행하고, AdGuard가 필터링과 관리 인터페이스를 추가합니다. 더 작은 스택을 원하면 Unbound만 사용해도 됩니다. 각 리스너에 서로 다른 주소/포트를 부여하고 전달 방향을 명확히 하세요. Unbound를 다시 AdGuard로 보내면 루프가 발생합니다. 게시하기 전에 어떤 프라이빗 클라이언트가 서비스를 사용할 수 있는지 결정하세요.
- 특정 승인 클라이언트 정책이 없는 한 공용 인바운드 TCP 및 UDP 53 포트를 닫아 두세요.
- 필터링 인터페이스와 DNS 리스너에 별도의 접근 규칙을 적용하세요.
- 설치 전에 포트 소유권을 확인하세요. 기존 시스템 리졸버가 이미 의도한 주소를 바인딩하고 있을 수 있습니다.
공식 문서: AdGuard Home 설정
루프백 Unbound 시작점
Unbound가 이미 설치된 시스템에서 다음 조각은 호스트에서만 접근 가능한 백엔드를 보여줍니다. 패키지 설정이나 신뢰 앵커 관리를 덮어쓰지 말고 배포판 구성과 통합하십시오. 높은 포트를 사용하면 다른 DNS 프런트엔드가 53 포트를 사용할 수 있습니다. 전체 유효 파일을 검증한 후 설치된 서비스 관리자를 통해 다시 로드하십시오. 원격 클라이언트에는 별도로 제어되는 터널 또는 프런트엔드가 필요합니다. 이 조각은 의도적으로 공용 리졸버를 생성하지 않습니다.
server:
interface: 127.0.0.1
port: 5335
access-control: 127.0.0.0/8 allow
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
# Validate the complete installed configuration:
unbound-checkconf공식 문서: Unbound 구성 참조
두 개의 네트워크에서 인수 체크리스트를 실행하세요
먼저 백엔드에서 로컬로 쿼리한 다음 일반 클라이언트 경로로 확인하세요. 일반 A/AAAA 레코드, 의도적으로 존재하지 않는 이름, 문서화된 테스트 도메인을 사용한 DNSSEC 검증을 확인하세요. 허용된 서브넷 외부의 머신에서 반복하세요. 재귀를 받아서는 안 됩니다. 브라우저가 자체 암호화 리졸버를 사용하여 구성된 장치 DNS을 우회하는지 검토하세요. 변경 중에는 임시 독립 리졸버를 사용할 수 있게 유지하여 DNS 실수로 관리 경로가 사라지지 않도록 하세요.
- 로컬 진단: dig @127.0.0.1 -p 5335 example.org A
- UDP 및 TCP 도달 가능성과 IPv6 리스너를 모두 점검하세요.
- 필터링 예외를 확인하고 실제로 필요한 진단 정보만 기록하세요.
시간 초과, 루프 및 검증 실패 진단
로컬 백엔드는 정상인데 프런트엔드 시간 초과가 발생하면 프런트엔드 주소, 방화벽 또는 포워딩 대상을 의심하세요. 자기 자신을 향한 쿼리가 반복되면 루프를 의심하세요. 광범위한 DNSSEC 실패는 잘못된 시스템 시간이나 신뢰 앵커 유지 관리와 관련될 수 있으므로 검증을 비활성화한 채 두지 말고 원인을 해결하세요. 큰 응답만 실패하면 TCP 폴백과 네트워크 경로를 조사하세요. 쿼리 로깅은 일시적으로만 유지하고, 리졸버를 모든 기기의 의존 대상으로 만들기 전에 재시작과 구성 복원을 테스트하세요.