카테고리 없음

dig 실무 사용법 — 도메인 문제 생겼을 때 실제로 치는 명령어 5개

바뿌 2026. 10. 1. 23:38

도메인을 바꿨는데 반영이 안 되거나, 접속이 되다 안 되다 할 때 dig를 씁니다.
옵션이 많지만 실무에서 실제로 치는 건 다섯 가지 정도입니다.

결론부터 — 이 다섯 개면 됩니다

dig +short A example.com                          # ① 어디를 가리키나
dig +short NS example.com                         # ② 네임서버가 어디인가
dig @ns.example-dns.com example.com A +short      # ③ 캐시 무시하고 진짜 값
dig example.com ANY +noall +answer                # ④ 레코드 전체 보기
dig +short -x 1.2.3.4                             # ⑤ IP가 누구 것인가

나머지는 필요할 때 찾아봐도 됩니다.

① 기본형 — +short

dig +short A example.com
# 93.184.216.34

+short를 빼면 질의 시간, 헤더, 권한 섹션까지 20줄쯤 나옵니다. 값만 보고 싶을 땐 항상 +short 를 붙입니다.

타입을 바꿔가며 물어볼 수 있습니다.

dig +short A     example.com      # IPv4 주소
dig +short AAAA  example.com      # IPv6 주소
dig +short CNAME blog.example.com # 별칭 대상
dig +short MX    example.com      # 메일 서버
dig +short TXT   example.com      # SPF 등
dig +short NS    example.com      # 네임서버

② 캐시를 믿지 마세요 — @네임서버

이게 실무에서 가장 중요합니다.

그냥 dig를 치면 내 PC가 쓰는 DNS 서버(통신사나 8.8.8.8)에 물어봅니다. 그 서버는 이전 답을 캐시해두고 있어서 방금 바꾼 값이 안 보입니다.

진짜 값은 그 도메인의 권위 네임서버에 직접 물어야 합니다.

# 1) 네임서버가 어디인지 먼저 확인
dig +short NS example.com
# ns.some-registrar.co.kr.
# ns1.some-registrar.co.kr.

# 2) 그 서버에 직접 질의
dig @ns.some-registrar.co.kr example.com A +short

@ 뒤에 서버를 지정하면 캐시를 거치지 않습니다. 설정을 바꾸고 "반영이 안 됐다"고 판단하기 전에 이걸 먼저 확인해야 합니다.

관리 화면에서 저장했는데 권위 서버에도 안 보인다 → 저장이 실제로 안 된 것
권위 서버에는 보이는데 일반 조회로는 안 보인다 → 전파 대기 중. 기다리면 됩니다

③ 레코드 전체 보기 — ANY +noall +answer

dig example.com ANY +noall +answer
example.com.  600    IN  A      121.254.x.x
example.com.  600    IN  CNAME  host.example.net.
example.com.  86400  IN  SOA    ns.some-registrar.co.kr. ...
example.com.  3600   IN  NS     ns.some-registrar.co.kr.
  • +noall +answer 는 응답 섹션만 보여줍니다. 없으면 출력이 서너 배로 길어집니다
  • 맨 앞 숫자(600, 3600)가 TTL(초) 입니다. 값을 바꿨을 때 이 시간만큼 기다려야 캐시가 갱신됩니다

여기서 충돌을 발견할 수 있습니다

위 출력에서 A와 CNAME이 같이 있으면 문제입니다. CNAME은 같은 이름에 다른 레코드와 공존할 수 없는데, 관리 화면에서는 둘이 나란히 등록되기도 합니다.

이 상태면 조회하는 리졸버마다 다른 답을 줘서 접속이 되다 안 되다 합니다.

참고로 CNAME이 걸려 있으면 MX나 TXT를 물어봐도 CNAME 대상이 돌아옵니다.
이게 보이면 "이 이름에는 CNAME이 있다"는 신호입니다.

for t in A AAAA CNAME MX TXT; do
  printf "%-6s " "$t"; dig +short $t example.com | tr '\n' ' '; echo
done

④ IP가 누구 것인지 — -x

dig +short -x 121.254.x.x

역방향 조회입니다. 모르는 IP가 나왔을 때 어느 회사 것인지 짐작할 수 있습니다. 다만 역방향 레코드를 설정해두지 않은 곳이 많아서 빈 결과가 흔합니다.

안 나오면 whois를 쓰거나, 그 IP에 직접 물어보는 방법이 있습니다.

# 그 서버가 어떤 인증서를 쓰는지 보면 소속이 드러나기도 합니다
echo | openssl s_client -connect 121.254.x.x:443 2>/dev/null \
  | openssl x509 -noout -subject

⑤ 전파 확인 — 여러 곳에서 물어보기

DNS 변경은 서버마다 반영 시점이 다릅니다. 몇 군데에 같이 물어보면 진행 상황이 보입니다.

for ns in 8.8.8.8 1.1.1.1 168.126.63.1; do
  printf "%-16s " "$ns"
  dig @$ns +short A example.com
done
  • 8.8.8.8 구글 / 1.1.1.1 클라우드플레어 / 168.126.63.1 KT

전부 새 값이 나오면 전파가 끝난 것입니다.

⚠️ dig로 할 수 없는 것 — 서브도메인 전수 조회

이게 실무에서 제일 많이 오해하는 부분입니다.

DNS는 "이 도메인에 어떤 서브도메인이 있나요?"라는 질문에 답하지 않습니다. 이름을 알아야 물어볼 수 있습니다.

# 이런 식으로 짐작해서 하나씩 찍어보는 수밖에 없습니다
for s in www mail blog api dev test m shop; do
  r=$(dig +short $s.example.com)
  [ -n "$r" ] && echo "$s → $r"
done

짐작한 이름만 찾습니다. 저는 이 방법으로 3개를 찾고 "이게 전부"라고 생각했는데, 등록기관 DNS 관리 화면을 열어보니 레코드가 12개 있었습니다. 9개를 놓칠 뻔했습니다.

전수 확인은 반드시 등록기관 DNS 관리 화면에서 합니다. dig는 검증용입니다.

저는 이것 때문에 하마터면 큰 걸 놓칠 뻔했습니다.

도메인에 연결된 서브도메인을 파악하려고 www, mail, blog 같은 흔한 이름을 하나씩 찍어봤습니다. 3개가 나왔고 "이게 전부겠지" 하고 진행하려 했습니다.

그런데 등록기관 DNS 관리 화면을 열어보니 레코드가 12개 있었습니다. 제가 이름을 짐작하지 못한 9개를 통째로 놓칠 뻔한 겁니다. 그 상태로 네임서버를 옮겼다면 9개 사이트가 한꺼번에 죽었을 겁니다.

캐시로도 한 번 헤맸습니다. 설정을 바꿨는데 반영이 안 되는 것 같아 기다렸는데, 권위 네임서버에 직접 물어보니 이미 반영돼 있었습니다. 문제는 전파가 아니라 다른 데 있었습니다.

정리

  • 값만 볼 땐 +short
  • 설정 바꾸고 확인할 땐 반드시 @권위네임서버 — 캐시된 답은 믿을 수 없습니다
  • ANY +noall +answer로 전체를 보면 레코드 충돌(A + CNAME)이 드러납니다
  • TTL은 맨 앞 숫자. 그 시간만큼은 옛 값이 남아 있습니다
  • 서브도메인 전수 조회는 dig로 불가능합니다. 관리 화면에서 확인하세요