DNS 레코드를 확인해야 합니다. 호스팅 제공업체를 변경하고 도메인이 새 서버를 가리키는지 확인하고 싶을 수도 있습니다. 이메일이 반송되어 MX 레코드 문제가 의심될 수도 있습니다. 또는 사이트가 잘못된 콘텐츠를 로드하고 DNS 문제인지 다른 문제인지 알아내려 할 수도 있습니다.

macOS에는 DNS 조회를 위한 세 가지 내장 Terminal 명령어가 있습니다: nslookup, dig, host. 모두 DNS를 쿼리하지만, 결과를 다르게 표시하고 각각 다른 상황에 적합합니다.

DNS 조회가 실제로 하는 것

브라우저에 도메인 이름을 입력하면 Mac은 DNS 리졸버(보통 ISP의 것이나 1.1.1.1 같은 공개 것)에게 해당 이름을 IP 주소로 번역해 달라고 요청합니다. 리졸버가 답을 찾아내면 컴퓨터가 해당 IP에 연결합니다.

DNS 조회를 통해 직접 이 번역을 실행하고 결과를 검사할 수 있습니다. 도메인이 어떤 IP로 해석되는지, 어떤 메일 서버가 이메일을 처리하는지, 어떤 네임서버가 권한을 갖는지 확인할 수 있습니다. 이것이 대부분의 일상적인 디버깅을 커버합니다.

알아두면 유용한 일반적인 레코드 유형:

A: IPv4 주소 (가장 자주 조회하는 유형)
AAAA: IPv6 주소
MX: 우선순위가 있는 메일 서버
CNAME: 다른 도메인을 가리키는 별칭
TXT: SPF, DKIM, 도메인 인증에 사용되는 텍스트 레코드
NS: 도메인에 권한이 있는 네임서버

Mac에서 nslookup: 익숙한 출발점

nslookup은 대부분의 사람들이 먼저 찾는 명령어입니다. 모든 운영 체제에 존재하므로, 다른 곳에서 DNS 조회를 해본 적이 있다면 구문이 익숙하게 느껴질 것입니다.

기본 A 레코드 조회

nslookup google.com

출력은 응답한 DNS 서버와 IP 주소를 보여줍니다. “Non-authoritative answer” 줄은 결과가 도메인 자체 네임서버가 아닌 캐시에서 왔다는 의미입니다. 이것은 정상입니다.

특정 레코드 유형 조회

nslookup -type=MX google.com

MX를 임의의 레코드 유형으로 교체하세요: A, AAAA, CNAME, TXT, NS, SOA. 예를 들어, 이메일 문제 해결을 위해 SPF와 DKIM을 확인하려면:

nslookup -type=TXT google.com

특정 DNS 서버 쿼리하기

여기서 nslookup이 실제로 유용해집니다. 기본 리졸버(오래된 데이터를 캐시하고 있을 수 있음) 대신 특정 서버에 직접 쿼리할 수 있습니다:

nslookup google.com 8.8.8.8

nslookup google.com 1.1.1.1

여러 서버를 쿼리하면 DNS 변경 사항이 전파되었는지 확인할 수 있습니다. 8.8.8.8이 새 IP를 보여주지만 1.1.1.1이 여전히 이전 것을 보여준다면 전파가 진행 중입니다.

nslookup 대화형 모드

인수 없이 nslookup을 입력하면 프롬프트가 나타납니다. 여기서 명령어를 다시 입력하지 않고 여러 쿼리를 실행할 수 있습니다:

> set type=MX
> google.com
> set type=A
> example.com
> exit

nslookup의 주요 단점은 정보 메시지와 실제 결과를 혼합한다는 것입니다. 서식이 레코드 유형에 따라 일관성이 없어 한눈에 파악하기 어렵습니다.

dig: Mac에서 DNS를 위한 파워 도구

dig (Domain Information Groper)는 DNS 문제를 정기적으로 해결하는 시스템 관리자와 개발자가 선호하는 도구입니다. 출력이 구조적이고 일관되며, 제어 옵션이 nslookup보다 훨씬 더 많습니다.

기본 조회

dig google.com

출력은 기본적으로 상세합니다: 질문한 내용, 답변 섹션, 타이밍, 응답한 서버. 이 추가 정보는 디버깅할 때 유용합니다. 정확히 무엇이 반환되었는지, 얼마나 걸렸는지 볼 수 있기 때문입니다.

+short으로 답만 얻기

주변 세부 사항 없이 빠른 답변을 원할 때:

dig google.com +short

이것은 IP 주소만 출력합니다. 스크립팅이나 결과만 알고 싶을 때 좋습니다:

dig google.com MX +short

우선순위와 함께 MX 레코드를 한 줄씩 반환합니다.

특정 레코드 유형 쿼리하기

dig google.com MX
dig google.com TXT
dig google.com NS
dig google.com AAAA

특정 DNS 서버 쿼리하기

dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com
dig @9.9.9.9 yourdomain.com

@ 구문은 리졸버를 지정합니다. 이것이 여러 공개 리졸버에 걸쳐 DNS 전파를 확인하는 가장 깔끔한 방법입니다.

전체 해석 경로 추적하기

dig google.com +trace

이것은 전체 DNS 해석 체인을 따라갑니다: 루트 서버, TLD 서버, 도메인의 권한 있는 네임서버. DNS가 체인의 어딘가에서 깨진다면, +trace가 정확히 어디서 실패하는지 보여줍니다.

DNSSEC 검증 확인하기

dig google.com +dnssec

출력에 DNSSEC 서명 레코드를 추가합니다. 도메인의 DNSSEC 설정이 활성화 후 올바른지 검증할 때 유용합니다.

host: 빠른 읽기 옵션

host는 최소한의 설정으로 깨끗하고 사람이 읽기 쉬운 출력을 제공합니다. dig가 제공하는 전체 세부 사항이 필요하지 않을 때 빠른 답변을 원하는 경우 올바른 선택입니다.

host google.com

이것은 A 레코드, AAAA 레코드, MX 레코드를 한 번에 반환합니다:

google.com has address 142.250.80.46
google.com has IPv6 address 2607:f8b0:4004:c1b::65
google.com mail is handled by 10 smtp.google.com.

특정 레코드 유형의 경우:

host -t MX google.com
host -t TXT google.com

host는 dig의 고급 옵션이 부족하지만, 출력이 플래그 없이도 즉시 읽기 쉽습니다.

어떤 도구를 언제 사용할까요

명령어	최적 용도	출력 스타일
`nslookup`	크로스 플랫폼 친숙도, 빠른 점검	장황함, 메시지 혼재
`dig`	전파 확인, 스크립팅, 전체 추적	구조화됨, `+short`로 깔끔한 출력
`host`	빠른 사람이 읽기 쉬운 답변, 플래그 불필요	간결함, 평문
`dig +short`	스크립팅, 배치 확인, 최소 출력	기본 답변만
`dig +trace`	DNS 해석이 실패하는 위치 찾기	루트 서버부터의 전체 체인
`NetUtil GUI`	터미널 불필요, 시각적 레코드 탐색	클릭 방식, 형식화된 결과

빠른 참조: 필요에 따라 어떤 DNS 도구를 사용할지.

실제 사용 사례

호스팅 변경 후 DNS 전파 확인하기

사이트를 새 서버로 이동하고 A 레코드를 업데이트했습니다. 이제 이전 호스팅을 취소하기 전에 변경이 전파되었는지 알고 싶습니다.

dig @8.8.8.8 yourdomain.com +short
dig @1.1.1.1 yourdomain.com +short
dig @9.9.9.9 yourdomain.com +short

세 개 모두 같은 IP를 반환하면 대부분의 사용자에게 전파가 완료된 것입니다. 다른 결과가 나오면 일부 리졸버가 여전히 캐시된 이전 데이터를 제공하고 있는 것입니다.

그 캐시가 얼마나 지속될지 보려면 TTL을 확인하세요:

dig @1.1.1.1 yourdomain.com

답변 섹션에서 레코드 이름과 레코드 유형 사이의 숫자가 초 단위 TTL입니다. TTL 300은 5분 후 캐시가 지워진다는 의미입니다. TTL 86400은 24시간을 기다려야 할 수 있다는 의미입니다.

MX 레코드로 이메일 전달성 디버깅하기

이메일이 오지 않습니다. SMTP 로그를 파고들기 전에 MX 레코드가 올바른지 확인하세요:

nslookup -type=MX yourdomain.com

또는 더 깔끔한 출력을 위해 dig:

dig yourdomain.com MX +short

출력은 메일 서버 호스트명과 우선순위를 보여줍니다. 낮은 숫자가 높은 우선순위를 의미합니다. 호스트명이 이메일 제공업체가 설정하라고 한 것과 일치하지 않는다면, 그것이 문제입니다.

SPF와 DKIM을 위한 TXT 레코드도 함께 확인하세요:

dig yourdomain.com TXT +short

SPF 레코드는 v=spf1 include:... ~all 형태로 보입니다. 없거나 잘못 형성되어 있다면 메시지가 스팸으로 가는 이유입니다.

사이트가 잘못된 IP로 로드되는 이유 디버깅하기

A 레코드를 한 시간 전에 업데이트했는데 도메인이 이전 서버 IP로 해석됩니다.

먼저 로컬 리졸버가 보는 것을 확인하세요:

dig yourdomain.com +short

그런 다음 외부 리졸버가 보는 것을 확인하세요:

dig @8.8.8.8 yourdomain.com +short

다르다면 로컬 리졸버가 이전 답을 캐시한 것입니다. TTL이 만료될 때까지 기다리거나 로컬 DNS 캐시를 플러시할 수 있습니다:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

두 리졸버 모두 같은 잘못된 IP를 보여준다면, A 레코드 자체가 올바르게 저장되지 않은 것입니다. DNS 제공업체에 다시 로그인하여 레코드를 확인하세요.

CNAME이 올바르게 설정되었는지 확인하기

dig yourdomain.com CNAME +short

이것은 CNAME이 가리키는 대상 도메인을 반환합니다. 아무것도 반환되지 않으면 그 이름에 CNAME이 없는 것입니다 (의도적이거나 잘못 구성된 A 레코드가 있을 수 있음).

macOS에서 DNS 캐시 플러시하기

레코드를 변경하거나 해석 문제를 해결한 후 Mac의 DNS 캐시를 지워야 할 때:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

이 명령어는 macOS Monterey, Ventura, Sonoma, Sequoia에서 작동합니다. mDNSResponder 프로세스가 로컬 DNS 해석을 처리하며, HUP 신호를 보내면 강제로 다시 로드합니다.

플러시 후 dig 또는 nslookup 명령어를 다시 실행하면 최신 결과를 볼 수 있습니다.

Terminal이 익숙하지 않다면

Apple은 macOS Monterey에서 네트워크 유틸리티를 제거했습니다. 이로써 DNS 조회를 위한 유일한 내장 GUI가 사라졌습니다.

NetUtil은 무료 대체 앱입니다. 앱을 열고 DNS 조회 탭에 도메인을 입력하고, 레코드 유형을 선택하면 이전 네트워크 유틸리티와 같은 방식으로 형식화된 결과를 얻을 수 있습니다. 암기할 명령어나 찾아볼 플래그가 없습니다. 결과는 dig나 nslookup에서 얻는 것과 동일한 데이터이지만, 노이즈 없이 표시됩니다.

가끔 DNS 확인이 필요할 때 GUI가 마찰을 줄여줍니다. 반복적인 조회나 스크립팅이 필요한 작업에는 dig를 고수하세요.

작업에 맞는 도구 선택하기

nslookup은 특히 이미 익숙한 경우 빠른 확인에 적합합니다. dig는 전파 확인, 스크립팅, DNS 동작 분석이 포함된 모든 것에 더 적합합니다. host는 IP가 무엇으로 해석되는지 빨리 알고 싶을 때 가장 빠른 방법입니다.

세 가지 모두 동일한 DNS 시스템을 쿼리합니다. 차이점은 표시 방식과 제어에 있습니다. 속도를 늦추지 않고 필요한 정보를 제공하는 것을 선택하세요.