REFUSED와 SERVFAIL의 차이는 뭔가요?

의도입니다. REFUSED(RCODE 5)는 의도적인 '거절' — 서버가 이 쿼리에 답하지 않도록 설정돼 있고, 보통 접근 정책 때문에 또는 당신이 재귀를 요청했는데 안 하기 때문에, 일부러 그렇게 알려줍니다. SERVFAIL(RCODE 2)은 실패한 시도 — 서버가 해석을 시도하다 뭔가 깨진 겁니다. REFUSED는 '안 한다', SERVFAIL은 '하려다 못했다'. 그래서 REFUSED는 거의 항상 도메인 자체가 아니라 누구에게 묻는지, 어디서 묻는지를 가리킵니다.

도메인을 분명히 호스팅하는 네임서버인데 왜 REFUSED가 나오나요?

권한 전용 서버에 재귀를 요청하고 있을 가능성이 큽니다. 권한 네임서버는 자기가 호스팅하는 특정 존에 대해 답하지만, 대부분 자기 책임이 아닌 이름을 추적하는 건 거부합니다 — 그건 재귀 리졸버의 일입니다. 권한 서버에 스텁 쿼리나 포워더를 향하게 하고 그 서버가 서비스하지 않는 이름(또는 재귀가 필요한 동작)을 요청하면 REFUSED가 돌아옵니다. 일반 조회는 1.1.1.1이나 8.8.8.8 같은 진짜 재귀 리졸버를 쓰고, 권한 서버에는 그 서버의 존만 질의하세요.

내부 DNS가 일부 클라이언트에 REFUSED를 반환하기 시작했어요 — 뭐가 바뀐 거죠?

거의 항상 ACL입니다. 재귀 리졸버는 amplification 공격에 악용되는 오픈 리졸버가 되지 않도록 보통 허용된 출발지 네트워크 집합으로 잠가둡니다. 클라이언트의 서브넷, VPN 대역, 또는 NAT 송출 IP가 허용 목록에 없거나 — 누가 목록을 조였으면 — 서버는 REFUSED로 답합니다. 클라이언트가 실제로 제시하는 출발지 IP에 대해 리졸버의 allow-recursion / allowed-clients 설정을 확인하세요. VPN과 NAT가 그 IP를 바꾼다는 점을 기억하고요.

조회수: 7

DNS REFUSED 오류 원인과 해결

DNS REFUSED는 서버가 일부러 답을 안 준다는 뜻 — 잘못된 네임서버, 재귀 불가, 또는 ACL. 어느 쪽인지 4단계로 찾습니다. 무료 즉시 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

Problem

조회가 status: REFUSED를 반환하거나, 도구가 “recursion not available” / “query refused”를 보고합니다. 서버는 닿고 응답도 하는데 — 당신이 요청한 답만 안 줍니다.

Symptoms

dig나 nslookup 헤더에 status: REFUSED가 보입니다.
nslookup이 “Got recursion not available from <서버>, trying next server”를 출력합니다.
같은 이름이 공개 리졸버로는 풀리는데 특정 서버로는 REFUSED.
네트워크 변경, 새 VPN, DNS 서버 설정 업데이트 직후 시작됐습니다.

REFUSED가 실제로 뜻하는 것

REFUSED는 DNS 응답 코드 5(RFC 1035)입니다: 네임서버가 정책상의 이유로 지정된 작업 수행을 거부한다. 핵심 단어는 정책입니다. 서버는 망가지지도, 과부하도, 답을 못 찾은 것도 아닙니다 — 당신에게 서비스하지 않기로 결정한 겁니다. REFUSED는 실패가 아니라 의도적인 ‘거절’인 유일한 흔한 DNS 오류입니다.

이게 조사 전체를 다시 짜게 만듭니다. NXDOMAIN에선 “이름이 존재하나?”를 묻습니다. SERVFAIL에선 “해석이 깨졌나?”를 묻습니다. REFUSED에선 다른 두 질문을 던집니다: 누구에게 질의하는가, 그리고 어디서 질의하는가. 거의 모든 REFUSED는 이 둘 중 하나로 귀결됩니다. 서버가 누구에게도 안 하는 일을 요청하고 있거나 — 보통 권한 전용 네임서버에 재귀를 요청 — 서버의 ACL이 신뢰하지 않는 곳에서 묻고 있거나. 서버는 설정된 그대로 정확히 동작합니다. 그 설정에 당신이 안 들어 있을 뿐입니다.

Top 3 Causes

권한 서버에 재귀를 요청 - 권한 네임서버는 자기 존의 답을 발행할 뿐, 범용 리졸버가 아닙니다. 일반 조회를 권한 서버에 향하게 하고 그 존 밖의 이름 해석(재귀 필요)을 요청하면, 제대로 설정된 서버는 오픈 리졸버가 되는 대신 REFUSED를 반환합니다. 단서: 도메인 자체 네임서버에서는 REFUSED, 1.1.1.1에서는 성공.
ACL이 출발지 IP를 차단 - 재귀 리졸버는 DNS amplification 공격에 악용되지 않도록 보통 출발지 네트워크로 사용 권한을 제한합니다. 클라이언트 IP — VPN 출구나 NAT 송출 주소 포함 — 가 허용 목록에 없으면 리졸버는 REFUSED로 답합니다. 단서: 한 네트워크에서는 되고 다른 데서는 REFUSED, 또는 VPN을 연결한 순간 깨짐.
잘못된 서버 또는 split-horizon 뷰 - 원하는 존을 아예 서비스하지 않는 리졸버를 가리키고 있습니다: 외부 이름을 거부하는 내부 전용 DNS 뷰, 엉뚱한 상위로 향한 포워더, 옛 네트워크에서 남은 오래된 /etc/resolv.conf. 서버 설정 관점에서 이 쿼리는 자기 일이 아니라서 거부합니다.

Diagnose with DechoNet

DNS Check는 당신의 로컬 DNS와 무관하게 공개 재귀 리졸버로 이름을 해석합니다. 내 PC는 REFUSED인데 여기선 깨끗한 답이 나오면 도메인은 멀쩡합니다 — 문제는 존이 아니라 내 리졸버 설정이나 내 네트워크 위치입니다.
Propagation Check는 여러 리졸버에 동시에 질의합니다. 내 네트워크만 빼고 어디서나 일관된 답이 나오면, REFUSED는 도메인 네임서버 문제가 아니라 로컬 정책(ACL이나 잘못 향한 리졸버)임을 확인해줍니다.

Resolution Checklist

RCODE 확인: dig example.com으로 SERVFAIL이나 NXDOMAIN이 아니라 status: REFUSED인지 확인 — 해결책이 다릅니다.
권한 서버에 잘못 질의하고 있는지 확인: dig @ns1.example.com somethingelse.com을 썼다면 그 REFUSED는 정상입니다. 일반 조회는 재귀 리졸버를 쓰세요.
알려진 재귀 리졸버로 재시도: dig @1.1.1.1 example.com과 dig @8.8.8.8 example.com. 여기서 되면 로컬/상위 리졸버가 당신을 거부하는 겁니다.
실제 출발지 IP를 확인하고(VPN·NAT가 바꿈) 리졸버의 allow-recursion / allowed-clients 목록과 대조하세요. 그 네트워크를 추가하거나 허용된 곳에서 질의하세요.
시스템이 실제로 쓰는 것을 점검: cat /etc/resolv.conf(또는 네트워크 DNS 설정). 네트워크 전환 후 오래되거나 잘못된 리졸버 주소가 흔한 원인입니다.
내부 split-horizon 리졸버라면, 질의하는 존을 볼 수 있도록 허용된 네트워크/뷰에 있는지 확인하세요.

When to Escalate

공개 리졸버는 답하는데 조직의 리졸버가 REFUSED를 반환하면, 그 DNS 서버 운영자에게 에스컬레이션하세요: 당신의 출발지 네트워크를 재귀 ACL에 추가해야 하거나, 리졸버 설정이 틀렸습니다.
도메인 자체 권한 네임서버가 서비스해야 할 존의 정당한 쿼리를 REFUSED 했다면, 그건 도메인 운영자가 고칠 서버 측 정책 오류입니다 — 자신을 배제한 ACL을 클라이언트가 우회할 수는 없습니다.