업데이트됨 1개월 전
웹사이트가 열리지 않습니다. 이메일이 갑자기 작동을 멈췄습니다. 이럴 때 누구나 가장 먼저 떠올리는 원인: DNS.
때로는 맞습니다. DNS는 모든 연결의 시작점에 자리 잡고 있습니다. DNS가 실패하면, 그 다음은 아무것도 소용없습니다. 서버가 완벽하게 돌아가고 있더라도, 사용자가 도메인 이름을 IP 주소로 변환하지 못하면 그 서버에는 절대로 닿을 수 없습니다.
하지만 DNS는 자신이 일으키지 않은 문제의 범인으로 자주 지목됩니다. 어려운 것은 DNS 문제를 고치는 일만이 아닙니다. 진짜로 DNS가 문제인지 파악하는 것 역시 그에 못지않게 중요합니다.
도메인이 아예 조회되지 않을 때
가장 명확한 DNS 오류: 완전한 조회 실패. 사용자에게 "DNS_PROBE_FINISHED_NXDOMAIN" 또는 "서버를 찾을 수 없습니다"가 표시됩니다. 해당 도메인이 컴퓨터 입장에서는 그냥 존재하지 않는 것입니다.
이런 일은 다음과 같은 경우에 발생합니다:
- 도메인 등록이 만료된 경우 (생각보다 훨씬 자주 있습니다)
- 네임서버 레코드가 더 이상 존재하지 않는 서버를 가리키는 경우
- 존 파일에 구문 오류가 있어 모든 것이 중단된 경우
- 네임서버 변경이 전파 중인 경우
가장 단순한 것부터 확인합니다: 도메인이 실제로 등록되어 있나요? 레지스트라의 관리 패널을 확인하세요. "만료됨" 또는 "삭제 대기 중" 상태의 도메인은 무엇을 해도 조회되지 않습니다.
다음으로 네임서버를 확인합니다. 레지스트라에 등록된 네임서버는 DNS 호스팅 업체의 서버와 정확히 일치해야 합니다. 레지스트라가 ns1.olddnsprovider.com을 가리키는데 실제 DNS 레코드가 ns1.newdnsprovider.com에 있다면, 아무것도 작동하지 않습니다.
이제 권한 네임서버에 직접 질의해 봅니다:
이렇게 하면 모든 캐시를 건너뛰고 네임서버가 실제로 제공하는 내용을 정확히 확인할 수 있습니다. 이 질의가 성공하는데 공개 DNS 질의가 실패한다면, 아직 전파 중입니다—기다리면 됩니다. 여기서도 실패한다면, 문제는 권한 네임서버 자체나 존 설정에 있습니다.
해결 방법: 만료된 도메인은 즉시 갱신하세요. 레지스트리가 서비스를 복원하는 데 24~48시간이 걸릴 수 있습니다. 네임서버가 일치하지 않는다면, DNS 호스트가 아닌 레지스트라에서 레코드를 수정하세요. 존 파일 오류의 경우, 대부분의 업체는 변경 로그를 유지하므로 디버깅하는 동안 마지막으로 정상 작동하던 설정으로 롤백하세요.
DNS가 느릴 때
사이트는 열리지만 사용자들이 "너무 오래 걸린다"고 합니다. 때로는 느린 DNS 조회가 원인입니다. 브라우저가 무언가를 내려받기도 전에 모든 질의가 지연 시간을 추가하기 때문입니다.
직접 측정해 봅니다:
"Query time" 값이 밀리초 단위로 조회 시간을 보여줍니다. 50ms 미만이면 양호합니다. 100ms를 넘으면 원인을 살펴볼 필요가 있습니다. 500ms를 초과하면 분명히 문제가 있는 것입니다.
온라인 DNS 테스트 도구를 사용해 여러 위치에서 테스트해 보세요. 뉴욕에서는 빠르지만 싱가포르에서는 느리다면, 지리적 분산 문제입니다. 일부 사용자에게 네임서버가 너무 멀리 있는 것입니다.
CNAME 체인도 지연을 늘립니다. www.example.com이 example.com을 가리키고, 그것이 lb.example.com을 가리키고, 그것이 최종적으로 IP 주소를 가리킨다면, 세 번의 추가 조회가 필요합니다. 조회마다 시간이 쌓입니다.
해결 방법: anycast 라우팅을 사용하는 글로벌 분산 DNS 업체로 전환하세요 (Cloudflare, AWS Route 53, Google Cloud DNS). 불필요한 CNAME 체인을 없애세요. 가능하면 A 레코드를 직접 가리키도록 하세요. 자주 바뀌지 않는 레코드는 TTL을 높여 캐시에 더 오래 남아 있게 하세요.
변경 사항이 전파되지 않을 때
DNS 레코드를 업데이트했습니다. 일부 사용자는 새 값을 봅니다. 다른 사용자는 여전히 예전 값을 봅니다. 이런 불일치는 몇 분에서 며칠까지 이어질 수 있습니다.
이건 버그가 아닙니다. DNS 캐싱이 원래 이렇게 동작합니다. 모든 DNS 레코드에는 TTL(Time To Live)이 있으며, 이 값이 리졸버에게 얼마나 오랫동안 캐시할지 알려줍니다. 레코드를 변경하면, 이전 값을 캐시하고 있는 리졸버는 해당 캐시가 만료될 때까지 계속 그 값을 씁니다.
많은 사람들이 놓치는 핵심: 전파 시간을 결정하는 것은 새 TTL이 아니라 이전 TTL입니다.
변경 전 A 레코드의 TTL이 86400초(24시간)였다면, 모든 캐시가 만료될 때까지 최대 24시간을 기다려야 합니다. TTL을 300(5분)으로 바꿔도 소용없습니다. 이전 레코드를 이미 캐시한 리졸버는 이전 TTL의 남은 시간 동안 그 값을 계속 씁니다.
여러 리졸버가 현재 어떤 값을 보고 있는지 확인합니다:
응답이 서로 다르면 전파가 진행 중인 것입니다.
해결 방법: 미리 계획하세요. 중요한 변경을 하기 최소 24~48시간 전에 TTL을 300초로 낮춰두세요. 변경이 전파된 뒤에는 질의 부하를 줄이기 위해 TTL을 다시 높이세요.
서버 마이그레이션의 경우, 전파 기간 동안 이전 서버와 새 서버를 모두 실행 상태로 유지하세요. 사용자들은 어느 한쪽에 도달하게 됩니다. 두 서버가 모두 정상 작동한다면, 아무도 전환 사실을 눈치채지 못합니다.
레코드가 잘못 설정된 경우
잘못된 레코드는 눈에 띄는 증상(사이트 완전 중단)부터 미묘한 증상(이메일이 가끔 반송되거나, SSL 경고가 간헐적으로 나타남)까지 다양한 문제를 일으킵니다.
흔한 실수들:
MX 레코드가 유효하지 않은 대상을 가리키는 경우. MX 레코드는 IP 주소가 아닌 호스트 이름을 가리켜야 합니다. 그리고 그 호스트 이름에는 자체적인 A 레코드가 있어야 합니다. MX 레코드가 mail.example.com을 가리키는데 mail.example.com에 대한 A 레코드가 없다면, 이메일 전달이 실패합니다.
존 최상위 도메인(apex)에 CNAME 사용. 루트 도메인(example.com)을 CNAME으로 만들 수 없습니다. DNS 표준을 위반하며, 예측할 수 없는 방식으로 오류가 납니다. A/AAAA 레코드를 쓰거나, 업체별 기능인 ALIAS 또는 ANAME 레코드를 사용하세요.
누락되거나 잘못된 형식의 TXT 레코드. SPF, DKIM, 도메인 인증 레코드는 구문이 까다롭습니다. 문자 하나만 잘못 들어가도 동작하지 않습니다.
마이그레이션 후 남겨진 오래된 레코드. 서버를 이전하고 나서도 이전 서버 IP를 가리키는 A 레코드가 그대로 남아 있는 경우.
각 레코드 유형을 따로 조회합니다:
존 파일의 끝에 붙는 점(trailing dot)을 주의하세요. example.com.(점 있음)과 example.com(점 없음)은 서로 다른 것을 의미합니다. 존 파일을 손으로 편집할 때 이 부분에서 자주 실수가 납니다.
해결 방법: DNS 구조를 문서로 남겨두세요. 어떤 레코드가 있고, 무엇을 가리키며, 왜 그런지 기록해 두세요. 이렇게 하면 문제를 추적할 때 혼란을 줄이고, 팀원들도 전체 구조를 이해하기 쉬워집니다.
실제로 DNS가 문제가 아닌 경우
DNS는 자신과 관계없는 많은 문제의 원인으로 지목됩니다. DNS 문제 해결에 깊이 들어가기 전에, DNS가 진짜 원인인지 먼저 확인하세요.
가장 확실한 테스트:
도메인 ping이 "알 수 없는 호스트"로 실패하는데 IP ping이 성공한다면, DNS 문제입니다.
둘 다 실패한다면, DNS는 무고합니다. 네트워크 연결, 방화벽 규칙, 또는 서버 자체가 오프라인 상태인 것이 원인입니다.
도메인 ping이 성공하는데(즉, DNS 조회는 정상) 웹사이트가 여전히 열리지 않는다면, 역시 DNS는 무고합니다. 조회는 성공했습니다. 다른 무언가가 실패하고 있는 것입니다. 확인할 사항:
- HTTP/HTTPS 트래픽을 차단하는 방화벽 규칙
- 해당 도메인 이름에 대한 설정이 없는 웹 서버
- 해당 도메인을 포함하지 않는 SSL 인증서
- 연결 성공 후 발생하는 애플리케이션 오류
- 클라이언트와 서버 사이의 네트워크 라우팅 문제
브라우저에 IP 주소를 직접 입력해서 테스트할 수도 있습니다. IP로는 사이트가 열리지만 도메인으로는 안 된다면, DNS 문제입니다. 둘 다 안 된다면, 다른 곳에서 원인을 찾으세요.
문제 해결의 마음가짐
DNS 문제 해결은 탐정 작업입니다. 사이트가 열리지 않거나, 이메일이 반송되거나, 간헐적으로 오류가 발생하는 증상만으로는 원인을 알 수 없습니다. 단계별로 추적해야 합니다:
도메인이 등록되어 있나요? → 네임서버가 올바른가요? → 존이 로드되고 있나요? → 레코드가 올바른가요? → 캐싱이 관련되어 있나요? → 애초에 DNS 문제가 맞나요?
각 질문이 가능성을 좁혀줍니다. DNS 문제 해결의 상당 부분은 사실 DNS의 무죄를 입증하여 진짜 문제에 집중할 수 있게 하는 과정입니다.
도구는 단순합니다: dig, nslookup, 그리고 레지스트라의 관리 패널. 핵심은 어떤 순서로 어떤 질문을 해야 하는지 아는 것입니다.
DNS 문제에 관한 자주 묻는 질문
DNS 전파는 실제로 얼마나 걸리나요?
새 레코드가 아닌 이전 레코드의 TTL에 따라 다릅니다. 이전 TTL이 86400초(24시간)였다면, 최대 24시간을 예상하세요. 일부 ISP는 TTL에 명시된 것보다 더 오래 캐시를 유지하기도 하므로, 여유를 두는 것이 좋습니다. 중요한 변경의 경우에는 48시간 전에 미리 TTL을 낮춰두세요.
내 사이트가 나한테는 잘 열리는데 동료에게는 왜 안 열릴까요?
DNS 리졸버마다 독립적으로 캐시합니다. 내 리졸버는 이미 새 레코드를 캐시했는데, 동료의 리졸버는 아직 이전 값을 갖고 있을 수 있습니다. 전파 중에는 정상적인 현상이며, 각 리졸버의 캐시가 만료되면 자연스럽게 해결됩니다.
DNS 전파를 강제로 빠르게 할 수 있나요?
아니요. 원격 리졸버의 캐시를 강제로 지울 방법이 없습니다. 내가 제어할 수 있는 것은 권한 네임서버가 제공하는 내용과 알려주는 TTL 값뿐입니다. 변경 전에 미리 TTL을 낮춰두는 것이 유일한 실질적인 해결책입니다.
DNS 변경이 즉시 적용된 것처럼 보이는 이유가 뭔가요?
어떤 리졸버도 이전 레코드를 캐시하지 않았거나 캐시가 이미 만료된 경우, 새 레코드가 즉시 적용된 것처럼 보입니다. TTL이 짧은 레코드나 트래픽이 적은 도메인에서 이런 일이 더 자주 발생합니다.
이 페이지가 도움이 되었나요?