已更新 1个月前
웹사이트가 다운됐을 때 가장 먼저 드는 질문은: DNS 문제인가, 아니면 다른 문제인가?
dig와 nslookup은 그 답을 몇 초 만에 알려줍니다. 모든 캐시 레이어를 걷어내고 실제로 무슨 일이 벌어지고 있는지 보여주며, DNS를 직접 조회할 수 있게 해줍니다. 인터넷의 어떤 네임서버에든 도메인에 대해 알고 있는 것을 물어보면 곧바로 답을 얻을 수 있습니다.
dig vs. nslookup
nslookup은 Windows, macOS, Linux에 기본으로 포함되어 있습니다. 별도 설치 불필요. 빠르고 간단합니다.
dig (Domain Information Groper)는 BIND DNS 패키지에서 나왔습니다. 더 상세하고, 더 강력하며, 진지한 디버깅에 선호되는 도구입니다. macOS와 Linux에는 기본 설치되어 있고, Windows 사용자는 별도로 설치해야 합니다.
알아두면 좋은 점: nslookup은 최신 BIND 배포판에서 더 이상 권장되지 않는 상태입니다. 여전히 동작하고 기본 조회에는 항상 쓸 수 있지만, 개발은 dig 쪽으로 계속되고 있습니다. 빠른 확인에는 둘 다 괜찮습니다. 하지만 실제 디버깅에서는 dig가 nslookup이 숨기는 정보까지 보여줍니다.
첫 번째 쿼리
이 도메인은 어떤 IP 주소로 연결될까요?
nslookup은 깔끔한 답변을 줍니다. dig는 모든 것을 알려줍니다: 질문, 답변, 어떤 서버가 응답했는지, 얼마나 걸렸는지, 얼마 동안 답변을 캐시할 수 있는지.
IPv6 주소의 경우:
다양한 레코드 타입 조회
DNS는 주소만 저장하는 게 아닙니다:
MX 레코드 — 이메일은 어디로 가야 할까요?
NS 레코드 — 어떤 네임서버가 권한을 갖고 있나요?
TXT 레코드 — SPF, DKIM, 도메인 인증:
CNAME 레코드 — 이것은 별칭인가요?
특정 네임서버에 질의하기
여기서 진짜 디버깅이 시작됩니다.
기본적으로 dig와 nslookup은 시스템에 설정된 리졸버에 질의합니다 — 보통 ISP나 기업 DNS입니다. 하지만 문제를 추적할 때는 그 캐시들을 뚫고 봐야 합니다:
nslookup으로는:
이것이 중요한 이유: DNS 레코드를 방금 업데이트했다고 합시다. 권한 서버에는 새 값이 있고 — 직접 질의해서 확인했습니다. 그런데 Google의 리졸버는 여전히 예전 IP를 반환합니다. 이제 알 수 있습니다: 변경은 올바르게 됐고, 캐시가 만료되기를 기다리는 중입니다.
dig의 출력 읽기
dig는 모든 것을 알려줍니다. 중요한 부분은 다음과 같습니다:
status: NOERROR — 쿼리 성공. 다른 값으로는:
NXDOMAIN— 도메인이 존재하지 않음SERVFAIL— 서버가 요청을 완료하지 못함REFUSED— 서버가 쿼리 응답을 거부함
3600 — TTL(Time to Live), 초 단위. 이 레코드는 한 시간 동안 캐시될 수 있습니다. 변경 사항이 전파되기를 기다릴 때, 이 숫자가 얼마나 기다려야 하는지 알려줍니다.
Query time: 23 msec — 느린 이름 풀이를 진단할 때 유용합니다.
dig의 강력한 옵션들
답변만 보기:
93.184.216.34만 반환합니다. 스크립트에 안성맞춤입니다.
전체 이름 풀이 경로 추적:
인터넷 전화번호부를 X선으로 투시하는 것과 같습니다. 쿼리가 루트 서버(.)에서 TLD 서버(.com)를 거쳐 권한 네임서버로 내려가는 과정을 직접 볼 수 있습니다. 전체 위임 체인이 눈앞에 펼쳐지고 — 뭔가 잘못됐을 때 정확히 어디서 끊어지는지 알 수 있습니다.
재귀 없이 질의하기:
다른 서버를 참조하지 않고 해당 서버가 직접 알고 있는 것만 질의합니다. 해당 서버의 존 파일에 정확히 무엇이 있는지 보여줍니다.
실제 디버깅 시나리오
"A 레코드를 변경했는데 사이트가 여전히 예전 IP를 보여줍니다"
권한 서버는 새 값을, 공개 리졸버는 예전 값을 보여주나요? 변경은 올바릅니다, 캐시가 아직 만료되지 않은 것뿐입니다. TTL을 확인해서 얼마나 더 기다려야 하는지 파악하세요.
"이메일이 배달되지 않고 있습니다"
MX 레코드가 없나요? 그게 문제입니다. MX 레코드가 이름 풀이가 안 되는 호스트를 가리키고 있나요? 그것도 문제입니다.
"네임서버를 변경했는데 아무것도 업데이트되지 않습니다"
위임 체인을 살펴보세요. TLD 서버가 여전히 예전 네임서버를 가리키고 있다면, 등록대행사의 변경이 아직 레지스트리에 전파되지 않은 것입니다.
"사이트 로딩이 느립니다"
답변에서 CNAME 체인을 찾아보세요. CNAME마다 추가 조회가 필요합니다. 긴 체인은 첫 번째 바이트가 로드되기도 전에 지연을 더합니다.
빠른 참조
| 작업 | dig | nslookup |
|---|---|---|
| A 레코드 | dig example.com | nslookup example.com |
| 특정 타입 | dig example.com MX | nslookup -type=MX example.com |
| 특정 서버 | dig example.com @8.8.8.8 | nslookup example.com 8.8.8.8 |
| 답변만 | dig +short example.com | — |
| 전체 추적 | dig +trace example.com | — |
뭔가 잘못됐을 때, 이 도구들은 DNS가 실제로 알고 있는 것을 보여줍니다 — 마땅히 알아야 할 것이 아니라, 설정한 것이 아니라, 바로 지금 이 순간 여러분이 선택한 서버에서 바라본 진실을.
dig와 nslookup에 관해 자주 묻는 질문
왜 dig 결과와 브라우저 결과가 다른가요?
브라우저는 오래된 레코드를 보유할 수 있는 운영체제의 DNS 캐시를 사용합니다. dig는 로컬 캐시를 우회하여 네임서버에 직접 질의합니다. dig는 올바른 IP를 보여주는데 브라우저가 그렇지 않다면, 시스템의 DNS 캐시를 초기화하세요 — macOS의 경우: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
Windows에서 dig를 어떻게 설치하나요?
dig는 Windows에 기본 포함되어 있지 않습니다. Chocolatey를 통해 설치하거나(choco install bind-toolsonly) ISC에서 BIND 도구를 직접 다운로드할 수 있습니다. 기본 조회에는 nslookup을 사용하거나, dig에 완전히 접근하려면 WSL(Windows Subsystem for Linux)을 활용하는 방법도 있습니다.
DNS 변경에서 높은 TTL은 어떤 의미인가요?
TTL은 리졸버에게 레코드를 얼마나 오래 캐시할지 알려줍니다. TTL이 86400(24시간)이면 일부 사용자는 변경 후 최대 하루 동안 예전 레코드를 볼 수 있습니다. 계획된 마이그레이션 전에는 최소 24시간 전에 TTL을 300(5분)으로 낮추세요 — 실제 변경을 하기 전에 기존의 높은 TTL이 만료될 시간이 있어야 합니다.
dig로 DNS가 제대로 작동하는지 테스트할 수 있나요?
네. dig google.com @8.8.8.8은 외부 DNS에 도달할 수 있는지 테스트합니다. 이것이 실패하지만 dig google.com @127.0.0.1이 성공한다면(로컬 리졸버를 실행 중이라는 전제 하에), 문제는 DNS 자체가 아니라 외부 DNS로의 연결입니다.
SERVFAIL과 NXDOMAIN의 차이는 무엇인가요?
NXDOMAIN은 도메인이 진짜로 존재하지 않는다는 뜻입니다 — 어디에도 레코드가 없습니다. SERVFAIL은 이름 풀이 중 뭔가 잘못됐다는 뜻입니다: 권한 서버에 접근할 수 없거나, DNSSEC 검증이 실패했거나, 설정 오류가 있는 것입니다. NXDOMAIN은 확정적이고, SERVFAIL은 "나중에 다시 시도하거나 서버를 점검하라"는 의미입니다.
此页面对您有帮助吗？