도메인은 정상인데 왜 접속이 안 될까? — ISP DNS 캐시가 만든 SERVFAIL 트러블슈팅
안녕하세요, Tasteam에서 Cloud 팀을 맡고 있는 clay입니다.
"저는 접속이 되는데, 다른 팀원은 접속이 안 돼요."
인프라를 운영하다 보면 이런 제보를 종종 받게 됩니다. 도메인 설정은 분명히 끝냈는데, 특정 사용자만 접속이 안 되는 상황.
가비아에서 구매한 tasteam.kr 도메인을 Cloudflare에 연결한 직후, 저희도 정확히 이 문제를 마주했습니다.
특히 KT 네트워크 환경에서 nslookup tasteam.kr을 실행하면 IP 주소를 찾지 못하고 SERVFAIL 오류를 반환했어요. 모든 설정은 정상이었는데, 대체 무엇이 문제였을까요?
오늘은 이 문제를 어떻게 진단하고 해결했는지, 그 과정을 공유해 드리겠습니다.
환경
먼저 당시 저희의 환경 구성입니다. 가비아에서 도메인을 구매하고, DNS는 Cloudflare를 통해 운영하고 있었어요.
항목 내용
| 도메인 레지스트라 | 가비아 (Gabia) |
| DNS | Cloudflare |
| 문제 발생 네트워크 | KT |
| 정상 동작 네트워크 | SKT, LG U+, Google DNS 등 |
처음엔 컴퓨터 문제인 줄 알았습니다
이상했던 건 클라우드 팀원들은 전원 정상 접속이 되는데, 백엔드 팀원들만 접속이 안 된다는 점이었어요. 같은 도메인, 같은 시간인데 팀마다 결과가 다르니 처음엔 개인 PC 문제를 의심했습니다.
그래서 맥북의 로컬 DNS 캐시를 삭제해 봤습니다.
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
하지만 캐시를 비워도 증상은 그대로였어요. 로컬 캐시가 원인이 아니라면, 그 위 단계에서 무언가 막고 있다는 뜻이었습니다.
이후 확인해 보니, 클라우드 팀원들은 공용 DNS(8.8.8.8 등)를 사용하고 있었고, 백엔드 팀원들은 ISP 기본 DNS(KT)를 그대로 쓰고 있었던 거예요. 사람의 차이가 아니라 네트워크 설정의 차이였습니다.
증상 확인
이 단서를 바탕으로, KT 네트워크 환경에서 nslookup을 실행해 봤습니다.
nslookup tasteam.kr
KT DNS 서버(168.126.63.1, 168.126.63.2)가 SERVFAIL을 반환하고 있었습니다.
반면, 같은 시간에 다른 네트워크에서는 정상적으로 IP가 반환됐어요. 도메인 자체의 문제라기보다는 특정 DNS 서버의 문제가 의심되는 상황이었습니다.
가설 수립
SERVFAIL 오류와 "일부 사용자에게만 발생"이라는 조건을 바탕으로 세 가지 가설을 세워 봤습니다.
가설 1. DNS 전파 지연
가비아에서 Cloudflare로 네임서버를 변경한 직후이므로, 변경 정보가 전 세계 DNS 망에 아직 전파되지 않았을 가능성이 있었습니다.
가설 2. 설정 오류
가비아의 네임서버 설정 또는 Cloudflare의 DNS 레코드(A, CNAME 등)가 잘못 구성되었을 가능성도 있었어요.
가설 3. DNSSEC 서명 불일치
SERVFAIL의 가장 흔한 원인 중 하나인데요. 가비아에 남아있는 이전 DNSSEC 서명 정보와 Cloudflare의 새 서명 정보가 일치하지 않아, 보안 검사를 수행하는 DNS 서버가 응답을 거부하는 경우입니다.
검증 과정
1단계 — 네임서버 전파 확인
dnschecker.org를 통해 tasteam.kr의 NS 레코드를 조회했습니다.
Cloudflare의 네임서버(dakota.ns.cloudflare.com, gigi.ns.cloudflare.com)가 전 세계적으로 정상 전파된 것을 확인할 수 있었어요.
결과: 정상 → 가설 1 기각
2단계 — Cloudflare 설정 확인
Cloudflare 대시보드에서 다음 내용을 확인했습니다.
- A 레코드가 정확한 서버 IP를 가리키고 있음
- 프록시(주황색 구름) 상태가 활성화됨
결과: 정상 → 가설 2 기각
3단계 — DNSSEC 설정 확인
- 가비아: DNSSEC 관련 설정 메뉴를 찾을 수 없었습니다.
- Cloudflare: DNSSEC 기능이 비활성화("Enable DNSSEC" 버튼 표시) 상태였어요.
결과: 양쪽 모두 비활성화 상태 → 가설 3의 일반적인 시나리오와 불일치
4단계 — DNS 경로 정밀 분석
dnsviz.net을 사용하여 루트(.)에서부터 tasteam.kr까지의 전체 DNS 신뢰 체인을 시각적으로 분석했습니다.
분석 결과, 어떠한 오류(빨간색 Error/Bogus)도 발견되지 않았어요.
결과: 도메인 자체의 기술적인 설정은 완벽한 상태
모든 설정이 정상인데 왜 SERVFAIL인가?
여기서 관점을 전환했습니다.
도메인 설정에는 문제가 없다면, 문제는 DNS 해석(Resolution) 단계에 있을 수밖에 없었어요.
DNS가 동작하는 과정
사용자 브라우저
↓ tasteam.kr 요청
사용자 PC의 DNS 설정 (예: KT DNS)
↓ 재귀 질의
KT DNS 서버 (Recursive Resolver)
↓ 캐시에 있으면 캐시 응답, 없으면 상위 질의
루트 DNS → .kr DNS → Cloudflare NS
↓ 응답
최종 IP 반환
여기서 핵심은 Recursive Resolver의 캐시입니다.
KT DNS 서버가 도메인 설정 변경 과정 중에 발생한 일시적인 오류 응답을 캐시에 저장해 둔 거예요. 이후 정상적인 설정이 완료되었음에도 캐시가 만료되기 전까지 계속 오래된 오류 응답을 반환하고 있었습니다.
결정적 검증
사용자 PC에서 DNS 서버를 KT → Google 공용 DNS로 변경한 후 다시 조회해 봤습니다.
nslookup tasteam.kr 8.8.8.8
즉시 정상적인 IP 주소가 반환됐어요.
dig 명령으로 더 정밀하게 비교하면 차이가 명확합니다.
- dig tasteam.kr @8.8.8.8 → status: NOERROR, A 레코드 2개 정상 반환
- dig tasteam.kr @168.126.63.1 → status: SERVFAIL, ANSWER 0개
이것으로 원인이 확정됐습니다. KT DNS 서버의 캐싱 문제였어요.
해결 조치
단기 해결 — 개별 사용자
문제가 발생하는 사용자의 DNS 서버를 공용 DNS로 변경하는 방법입니다.
DNS 서비스 Primary Secondary
| 8.8.8.8 | 8.8.4.4 | |
| Cloudflare | 1.1.1.1 | 1.0.0.1 |
장기 해결 — 전체 사용자
두 가지 방법이 있었습니다.
1. 수동적 대기
KT DNS 서버의 캐시가 TTL 만료로 자연 갱신될 때까지 기다리는 방법이에요. (수 시간 ~ 최대 2일 소요)
2. 능동적 캐시 갱신 유도
Cloudflare 대시보드에서 DNSSEC 기능을 켰다가 1분 후 다시 끄는 조치를 수행했습니다.
이 작업은 Cloudflare가 DNS 망에 구성 변경 신호를 보내, KT와 같은 하위 DNS 서버들이 캐시를 더 빨리 새로고침하도록 유도하는 효과가 있어요.
돌아보며
1. SERVFAIL ≠ 설정 오류
SERVFAIL을 보면 본능적으로 "내 설정이 잘못됐나?"를 먼저 의심하게 됩니다. 하지만 이번 케이스처럼 설정은 완벽한데 중간 경로의 캐시가 원인인 경우도 있어요.
2. ISP DNS 캐시는 통제 불가 영역
KT, SKT, LG U+ 등 ISP의 DNS 서버는 우리가 직접 제어할 수 없습니다. 캐시 만료를 기다리거나, 간접적으로 갱신을 유도하는 수밖에 없어요.
3. 문제 격리가 핵심
"일부 사용자만 안 된다"는 증상에서 네트워크 환경 차이를 빠르게 캐치하는 것이 중요했습니다. DNS 서버를 바꿔보는 것만으로 원인을 좁힐 수 있었어요.
도메인 마이그레이션 후 체크리스트
마지막으로, 도메인 연결이나 네임서버 변경 후 아래 항목을 순서대로 확인하면 대부분의 DNS 문제를 빠르게 진단할 수 있습니다.
- NS 레코드 전파 확인 — dnschecker.org에서 전 세계 NS 응답 확인
- DNS 레코드 확인 — A/CNAME 레코드가 올바른 IP/도메인을 가리키는지 확인
- DNSSEC 상태 확인 — 레지스트라와 DNS 제공자 양쪽의 DNSSEC 설정이 일치하는지 확인
- DNS 신뢰 체인 검증 — dnsviz.net에서 오류 없는지 확인
- 다른 DNS 서버로 테스트 — nslookup 도메인 8.8.8.8로 ISP DNS 문제 여부 격리
- TTL 대기 또는 캐시 갱신 유도 — 문제가 ISP 캐시라면 시간 경과 또는 DNSSEC 토글로 대응
마치며
"설정은 다 맞는데 왜 안 되지?"라는 상황은 인프라를 운영하다 보면 정말 자주 마주치게 됩니다. 이번 트러블슈팅에서 얻은 가장 큰 교훈은 내가 통제할 수 있는 영역과 없는 영역을 구분하고, 체계적으로 가설을 세워 하나씩 검증해 나가는 것의 중요성이었어요.
비슷한 문제를 겪고 계신 분이 있다면 이 글이 도움이 되었으면 좋겠습니다. 읽어 주셔서 감사합니다.
'네트워크' 카테고리의 다른 글
| 외부 보안 공격 이후 EC2 네트워크가 끊긴 이야기 — DHCP 갱신 실패 장애 분석 (0) | 2026.02.23 |
|---|