Unbound는 systemctl에서 활성화되어 있을 수 있으며, 어떤 요청에도 응답하지 않을 수 있습니다. Debian 또는 Ubuntu VM에서의 증상은 일반적입니다: 서비스는 실행 중이지만 DNS 요청은 여전히 느리거나 애플리케이션이 아무것도 해결하지 못합니다.
/etc/resolv.conf를 수정하거나 systemd-resolved를 변경하기 전에, 먼저 로컬 진단을 수행하세요. 구성과 포트를 확인하고, Unbound에 직접 쿼리를 보내세요. 이러한 점검 중에는 시스템의 DNS가 유지됩니다.
포트 53을 건드리기 전에 구성 읽기
Debian과 Ubuntu에서는 주요 구성 파일이 종종 /etc/unbound/unbound.conf를 통해 이루어지며, /etc/unbound/unbound.conf.d/에 포함되어 있습니다. Unbound가 127.0.0.1:53에서 듣고 있다고 가정하지 마세요.
포트 53는 이미 systemd-resolved, dnsmasq 또는 BIND에 의해 사용 중일 수 있습니다. 위험은 간단합니다: 시스템 해석기를 너무 일찍 변경하면 Unbound가 올바른 위치에서 듣지 않을 때 DNS 해석이 중단될 수 있습니다.
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo unbound-checkconf -o interface /etc/unbound/unbound.conf
sudo unbound-checkconf -o port /etc/unbound/unbound.conf
sudo ss -lntup 'sport = :53'unbound-checkconf는 구성을 읽고, 지시문이 로딩을 차단할 경우 오류를 반환합니다. 공식 매뉴얼 페이지에 따르면, 반환 코드 0은 파일이 유효함을 나타냅니다. 옵션 -o interface와 -o port는 실제 값을 출력합니다.
ss는 실제로 리슨하고 있는 프로세스를 보여줍니다. systemd-resolved측에서 127.0.0.53:53이 보이는데 Unbound가 127.0.0.1:53에서 응답해야 할 경우, 해결해야 할 실제 충돌이 있습니다.
변경하기 전에 주요 파일의 읽기 가능한 복사본을 남기세요:
sudo cp -a /etc/unbound/unbound.conf /etc/unbound/unbound.conf.before-local-testDNS 변경 없이 Unbound 쿼리하기
활성 서비스만으로는 충분하지 않습니다. Unbound는 다른 인터페이스에서 리슨하거나 다른 포트를 사용할 수 있으며, 상위 서버나 DNSSEC에 문제가 있을 경우 실패할 수도 있습니다.
서비스 상태와 현재 시작 로그는 초기 분류를 제공합니다. 그런 다음 시스템의 DNS 구성 없이 로컬 해석기에 쿼리를 보내세요:
sudo systemctl status unbound --no-pager
sudo journalctl -u unbound -b -n 50 --no-pager
dig @127.0.0.1 example.net A +noall +comments +answer
dig @127.0.0.1 example.net A +noall +stats127.0.0.1을 적절하게 조정하고, 설정이 다른 포트를 표시하면 -p 5335를 추가하세요. status: NOERROR로 응답하고 ANSWER 섹션이 있으면 Unbound가 해당 이름에 대해 응답했음을 증명합니다.
connection refused는 서비스나 포트를 나타냅니다. SERVFAIL는 데몬이 요청을 받았지만 이름을 해결할 수 없음을 나타냅니다. 로그는 네트워크 오류, DNSSEC 검증 및 상위 서버 구성을 구분하는 데 도움이 됩니다.
그런 다음 동일한 요청을 다시 실행하세요. 두 번째 시도에서 짧은 시간은 Unbound의 캐시 덕분일 수 있습니다. 이 테스트는 해석기의 성능을 측정하지 않으며, 올바른 인스턴스와 대화하고 있음을 확인합니다.
직접 테스트 후에만 시스템 해석기를 연결하기
dig @127.0.0.1가 응답하지만 애플리케이션이 여전히 실패한다면, Unbound가 시스템에서 사용되는 체인에 없을 가능성이 큽니다. 네트워크를 수정하기 전에 이 체인을 읽으세요.
resolvectl status는 systemd-resolved에 의해 인식된 DNS를 표시합니다.resolvectl query example.net는 시스템 해석기로부터 해석을 테스트합니다.cat /etc/resolv.conf는 일반 애플리케이션에 제공되는 파일을 보여줍니다.
서버에서는 Unbound를 문서화된 주소와 포트에 유지하고, 직접 테스트가 검증된 후에 시스템 해석기를 연결할 것입니다. 워크스테이션에서는 이 레이어가 Wi-Fi, VPN 또는 네트워크 프로필을 단순화한다면 systemd-resolved가 Unbound 앞에 남아 있을 수 있습니다.
로컬 테스트는 도메인의 공용 해석에 대해 아무것도 말하지 않습니다. 애플리케이션을 HTTPS가 적용된 Caddy 리버스 프록시 뒤에 배치하기 전에, 인터넷에서 본 응답도 확인하세요.
문서 unbound-checkconf는 구성 검사에 대해 다룹니다. 공식 로컬 해석기 가이드는 시스템과의 통합을 상세히 설명합니다. 직접 테스트와 시스템 테스트가 동일한 결과를 주지 않는 한, 백업을 유지하세요.