재귀 DNS 조회, 단계별로 살펴보기
브라우저
example.com 요청
리졸버
내 ISP / 1.1.1.1
루트 + TLD
.com 운영 주체는?
권한 네임서버
실제 응답
체인의 각 단계도 DNS 조회이며 이후 캐시됩니다
웹사이트 IP 주소 찾는 5가지 방법
웹사이트의 IP 주소를 찾는 데는 몇 초면 충분합니다. 정말 유용한 기술은 찾은 주소가 무엇인지, 즉 원본 서버인지, CDN 엣지 노드인지, 로드 밸런서인지 아는 것입니다. 그에 따라 그 숫자가 쓸모가 있는지가 결정되기 때문입니다.
가장 빠른 방법부터 가장 자세한 방법까지 다섯 가지를 소개하고, 그 결과를 정직하게 해석하는 방법을 설명합니다.
방법 1: 온라인 조회 도구 사용
가장 빠른 방법이며 터미널이 필요 없는 유일한 방법입니다. 홈페이지의 도메인 IP 조회에 도메인을 붙여 넣으면 서버 측 질의 한 번으로 A 레코드(IPv4), AAAA 레코드(IPv6), 네임서버, MX, CNAME, TXT 레코드를 한꺼번에 확인할 수 있습니다.
로컬 명령어에 비해 장점은 조회가 깨끗한 캐시를 가진 서버에서 실행되므로, 내 컴퓨터가 몇 시간 전에 캐시해 둔 오래된 응답을 보게 되지 않는다는 점입니다. 확인할 도메인이 여러 개라면 일괄 모드로 최대 50개를 한 번에 조회할 수 있습니다.
방법 2: ping, 빠르고 어디서나 사용 가능
ping은 아무것도 보내기 전에 이름을 먼저 확인하고, 확인된 주소를 출력합니다. Windows, macOS, Linux에서 똑같이 동작합니다.
ping example.com첫 번째 줄에 확인된 주소가 표시됩니다. PING example.com (93.184.216.34). 필요한 정보는 이미 얻었으니 Ctrl+C를 눌러 중지하세요.
방법 3: nslookup, 크로스 플랫폼 표준
Windows, macOS 및 대부분의 Linux 배포판에 내장되어 있으며, 바로 이런 질문을 위해 만들어졌습니다.
nslookup example.com출력은 응답한 리졸버(Server:)와 응답 자체를 구분해서 보여 줍니다. Non-authoritative answer라고 표시된 줄은 도메인 자체의 네임서버가 아니라 캐시에서 온 응답이라는 뜻일 뿐이며, 경고가 아니라 일반적인 경우입니다.
nslookup example.com 1.1.1.1두 번째 형식은 오래된 캐시가 의심될 때 정말 유용합니다. 네트워크가 제공하는 리졸버 대신 Cloudflare의 리졸버에 직접 질의하는 것이기 때문입니다.
방법 4: dig, 전문가들이 쓰는 도구
dig는 macOS와 Linux에 기본 포함되어 있습니다(Windows에서는 WSL을 쓰거나 BIND 도구를 설치하세요). TTL을 포함해 정확하고 스크립트로 처리하기 쉬운 출력을 제공합니다.
dig +short example.com A
dig +short example.com AAAAdig example.com전체 출력에서 ANSWER SECTION의 IN A 앞에 있는 숫자는 남은 TTL(초)입니다. 이 리졸버가 캐시된 사본을 앞으로 얼마나 더 재사용할지를 나타냅니다. 같은 질의를 반복하면서 이 숫자가 줄어드는 것을 지켜보면 캐싱이 동작하는 모습을 가장 분명하게 볼 수 있습니다.
dig @ns1.example.com example.com모든 캐시를 건너뛰고 원본에 직접 묻는 방식입니다. 이 결과가 다른 곳에서 보는 결과와 다르다면 전파가 진행되는 모습을 보고 있는 것입니다.
방법 5: 브라우저 개발자 도구
보고 있는 페이지를 실제로 제공하는 주소를 리디렉션까지 포함해서 알고 싶을 때 유용합니다.
F12(macOS에서는Cmd+Option+I)로 개발자 도구를 열고 Network 탭을 선택합니다.- 페이지를 새로 고칩니다.
- 첫 번째 문서 요청을 클릭한 다음 Headers 패널을 엽니다.
- General 아래에서 Remote Address를 찾습니다. 브라우저가 실제로 연결한 IP와 포트입니다.
다섯 가지 방법 비교
| 방법 | 가장 적합한 경우 | TTL 표시 | 터미널 필요 |
|---|---|---|---|
| 온라인 도구 | 모든 레코드 유형을 한 번에, 깨끗한 캐시 | 아니요 | 아니요 |
ping | 어디서나 빠르게 답 확인 | 아니요 | 예 |
nslookup | 특정 리졸버에 질의 | 일부 | 예 |
dig | 정밀한 확인과 스크립트 작업 | 예 | 예 |
| 개발자 도구 | 바로 이 페이지를 제공하는 주소 | 아니요 | 아니요 |
그렇다면 실제 서버를 찾은 걸까요?
아마 아닐 것이며, 그것이 정상입니다. 어느 정도 규모가 있는 사이트는 대부분 CDN이나 로드 밸런서 뒤에 있으므로, 확인한 주소는 그 인프라의 것입니다.
조회 결과에 원본이 아닌 CDN이 보이는 이유
방문자
도메인 조회
CDN 엣지
104.21.x.x
DNS가 반환하는 대상
원본 서버
실제 IP, 노출되지 않음
원본 서버가 아니라 공유 인프라를 보고 있다는 신호는 다음과 같습니다.
- 주소의 역방향 DNS가 제공업체의 호스트 이름(
*.cloudflare.com,*.amazonaws.com,*.fastly.net)으로 확인됩니다. - 같은 주소가 서로 관련 없는 많은 도메인을 제공합니다.
- 위치가 다르거나 질의를 반복할 때마다 서로 다른 주소가 반환됩니다.
핵심 요약
이 다섯 가지 방법은 모두 DNS가 게시하는 주소를 알려 줍니다. 이는 실제로 올바른 답이지만, 어디까지나 도메인의 공개된 정문에 대한 답일 뿐 그 뒤에 있는 머신에 대한 답은 아닐 수 있습니다.
도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.
이 주제의 무료 도구
자주 묻는 질문
관련 글
재귀 DNS 조회, 단계별로 살펴보기
브라우저
example.com 요청
리졸버
내 ISP / 1.1.1.1
루트 + TLD
.com 운영 주체는?
권한 네임서버
실제 응답
체인의 각 단계도 DNS 조회이며 이후 캐시됩니다
DNS의 작동 원리: 도메인 이름에서 IP 주소까지
인터넷의 전화번호부를 처음부터 끝까지 추적합니다. 도메인을 입력한 뒤 첫 패킷이 서버에 닿기까지 몇 밀리초 동안 무슨 일이 일어날까요?
조회 결과에 원본이 아닌 CDN이 보이는 이유
방문자
도메인 조회
CDN 엣지
104.21.x.x
DNS가 반환하는 대상
원본 서버
실제 IP, 노출되지 않음
CDN이 원본 IP를 숨기는 이유와 그 목적
도메인을 조회했는데 Cloudflare 주소가 나왔나요? 시스템이 정상 동작하는 것입니다. 그 뒤에 무엇이 있고 왜 꿰뚫어 볼 수 없는지 설명합니다.
거의 모든 존에서 만나게 되는 레코드
DNS A 레코드란? (그리고 AAAA가 필요한 경우)
도메인을 실제로 서버에 연결하는 레코드입니다. 구조, 짝이 되는 AAAA, 사이트를 가장 자주 망가뜨리는 네 가지 실수를 다룹니다.