DNS 조회: 도메인 이름 작동 방식
· 12분 읽기
목차
DNS란 무엇이며 왜 중요한가
도메인 네임 시스템(DNS)은 종종 "인터넷의 전화번호부"라고 불리며, 그럴 만한 이유가 있습니다. 웹사이트를 방문하거나, 이메일을 보내거나, 인터넷 서비스를 사용할 때마다 DNS는 뒤에서 작동하여 사람이 읽을 수 있는 도메인 이름을 기계가 읽을 수 있는 IP 주소로 변환합니다.
DNS가 없다면 브라우저에 google.com을 간단히 입력하는 대신 172.217.14.206과 같은 숫자 문자열을 기억해야 할 것입니다. 이 변환 서비스는 인터넷 작동 방식에 매우 기본적이어서 DNS가 실패하면 웹의 전체 부분에 액세스할 수 없게 됩니다.
DNS는 분산 데이터베이스 시스템으로 작동하며, 전 세계 수백만 대의 서버가 함께 작동하여 매일 수십억 건의 쿼리를 해결합니다. 이러한 분산 아키텍처는 인터넷을 확장 가능하고 탄력적으로 만들어 중복성을 유지하면서 대규모 트래픽 부하를 처리할 수 있게 합니다.
빠른 팁: DNS는 웹사이트만을 위한 것이 아닙니다. 이메일 전달(MX 레코드), 서비스 검색, 로드 밸런싱, 심지어 스팸 방지에도 사용됩니다. DNS를 이해하는 것은 네트워크 시스템을 다루는 모든 사람에게 필수적입니다.
DNS 작동 방식: 완전한 해석 프로세스
브라우저에 도메인 이름을 입력하면 밀리초 내에 복잡한 일련의 이벤트가 펼쳐집니다. DNS 해석이라고 하는 이 프로세스는 필요한 IP 주소를 제공하기 위해 여러 서버와 캐싱 계층이 함께 작동하는 것을 포함합니다.
단계별 DNS 해석
- 브라우저 캐시 확인: 브라우저는 먼저 최근에 해석된 IP 주소에 대해 자체 캐시를 확인합니다. 최신 브라우저는 동일한 사이트에 대한 반복 방문 속도를 높이기 위해 짧은 기간(일반적으로 60초에서 몇 분) 동안 DNS 레코드를 캐시합니다.
- 운영 체제 캐시: 브라우저 캐시에서 찾지 못하면 쿼리는 운영 체제의 DNS 리졸버 캐시로 이동합니다. 이 캐시는 웹 브라우저뿐만 아니라 시스템의 모든 애플리케이션에 대한 DNS 레코드를 저장합니다. Windows에서는
ipconfig /displaydns를 사용하여 이 캐시를 볼 수 있습니다. - 라우터 캐시: 많은 가정 및 사무실 라우터도 자체 DNS 캐시를 유지합니다. 이는 쿼리가 로컬 네트워크를 떠나기 전에 또 다른 속도 최적화 계층을 제공합니다.
- ISP DNS 리졸버: 로컬 캐시에 답이 없으면 쿼리는 인터넷 서비스 제공업체의 DNS 리졸버(재귀 리졸버라고도 함)에 도달합니다. 이 서버는 장치가 DHCP를 통해 네트워크에 연결될 때 자동으로 구성됩니다.
- 루트 네임서버: ISP의 리졸버는 13개의 루트 네임서버 시스템 중 하나(실제로는 애니캐스트 라우팅을 사용하는 수백 대의 서버)에 연결합니다. 이러한 서버는 특정 도메인의 IP 주소를 알지 못하지만 각 최상위 도메인(TLD)에 대한 권한 있는 서버를 찾을 위치를 알고 있습니다.
- TLD 네임서버: 루트 서버는 쿼리를 적절한 TLD 네임서버로 안내합니다. 예를 들어,
.com도메인에 대한 쿼리는 .com TLD 서버로 이동하고.org쿼리는 .org 서버로 이동합니다. 이러한 서버는 TLD 내의 각 도메인을 처리하는 권한 있는 네임서버에 대한 정보를 유지합니다. - 권한 있는 네임서버: 마지막으로 쿼리는 도메인 소유자가 구성한 도메인의 권한 있는 네임서버에 도달합니다. 이 서버에는 도메인을 IP 주소 및 기타 정보에 매핑하는 실제 DNS 레코드가 포함되어 있습니다.
- 응답 및 캐싱: IP 주소는 체인을 통해 다시 이동하며, 각 서버는 레코드의 TTL(Time To Live) 값에 따라 결과를 캐시합니다. 브라우저는 IP 주소를 받고 이제 웹 서버에 연결을 설정할 수 있습니다.
이 전체 프로세스는 일반적으로 20-120밀리초 내에 완료되지만 캐시된 결과를 사용할 수 있을 때는 훨씬 빠를 수 있습니다. DNS 조회 도구를 사용하여 다양한 DNS 서버가 얼마나 빠르게 응답하는지 DNS 해석 속도를 테스트할 수 있습니다.
전문가 팁: 도메인에 대한 첫 번째 DNS 조회는 캐싱으로 인해 후속 조회보다 항상 느립니다. 이것이 브라우저 캐시를 지워도 반복 방문 시 웹사이트가 더 빠르게 느껴지는 이유입니다.
재귀 vs. 반복 DNS 쿼리
DNS 쿼리에는 재귀와 반복의 두 가지 유형이 있습니다. 차이점을 이해하면 DNS 서버가 서로 통신하는 방식을 설명하는 데 도움이 됩니다.
재귀 쿼리는 답을 찾는 부담을 DNS 서버에 둡니다. 컴퓨터가 ISP의 리졸버에 재귀 쿼리를 보내면 해당 서버는 확실한 답을 얻을 때까지 전체 체인을 따라가는 책임이 있습니다. 리졸버는 모든 작업을 수행하고 IP 주소 또는 오류를 반환합니다.
반복 쿼리는 DNS 서버 간에 사용됩니다. ISP의 리졸버가 루트 서버를 쿼리하면 최종 답변이 아닌 체인의 다음 서버에 대한 참조를 받습니다. 그런 다음 리졸버는 해당 서버를 쿼리하고 다른 참조를 받고 권한 있는 네임서버에 도달할 때까지 계속합니다.
DNS 레코드 유형 설명
DNS 레코드는 도메인에 대한 정보를 제공하는 권한 있는 네임서버에 저장된 지침입니다. 서버에 도메인을 가리키는 것부터 이메일 진위성을 확인하는 것까지 다양한 레코드 유형이 다양한 목적을 제공합니다.
| 레코드 유형 | 목적 | 예시 |
|---|---|---|
A |
도메인을 IPv4 주소에 매핑 | example.com → 192.0.2.1 |
AAAA |
도메인을 IPv6 주소에 매핑 | example.com → 2001:db8::1 |
CNAME |
다른 도메인을 가리키는 별칭 생성 | www.example.com → example.com |
MX |
도메인의 메일 서버 지정 | example.com → mail.example.com (우선순위 10) |
TXT |
텍스트 정보 저장 (SPF, DKIM, 확인) | "v=spf1 include:_spf.google.com ~all" |
NS |
하위 도메인을 네임서버에 위임 | example.com → ns1.example.com |
PTR |
역방향 DNS 조회 (IP에서 도메인으로) | 192.0.2.1 → example.com |
SRV |
서비스 위치 지정 | _sip._tcp.example.com → sipserver.example.com:5060 |
CAA |
인증서를 발급할 수 있는 CA 지정 | 0 issue "letsencrypt.org" |
A 및 AAAA 레코드: 기초
A 레코드는 가장 기본적인 DNS 레코드 유형으로, 도메인 이름을 IPv4 주소에 직접 매핑합니다. 웹사이트를 방문할 때 브라우저는 일반적으로 서버의 IP 주소를 찾기 위해 먼저 A 레코드를 조회합니다.
AAAA 레코드("쿼드-A"로 발음)는 IPv6 주소에 대해 동일한 목적을 제공합니다. 인터넷이 IPv6로 전환됨에 따라 더 많은 도메인이 두 프로토콜을 모두 지원하기 위해 A 레코드와 함께 AAAA 레코드를 추가하고 있습니다.
CNAME 레코드: 도메인 별칭
CNAME(Canonical Name) 레코드는 다른 도메인 이름을 가리키는 별칭을 생성합니다. 일반적으로 www.example.com을 example.com에 가리키거나 여러 하위 도메인을 단일 서버에 가리키는 데 사용됩니다.
한 가지 중요한 제한 사항: CNAME 레코드는 동일한 이름에서 다른 레코드 유형과 공존할 수 없습니다. 즉, 동일한 도메인에 대해 CNAME과 MX 레코드를 가질 수 없으며, 이것이 CNAME이 일반적으로 루트 도메인이 아닌 하위 도메인에 사용되는 이유입니다.
MX 레코드: 이메일 라우팅
MX(Mail Exchange) 레코드는 이메일 서버에 도메인의 메일을 어디로 전달할지 알려줍니다. 각 MX 레코드에는 우선순위 값이 포함되어 있으며, 낮은 숫자는 높은 우선순위를 나타냅니다. 기본 메일 서버를 사용할 수 없는 경우 발신자는 더 높은 우선순위 값을 가진 서버를 시도합니다.
예를 들어, Google Workspace는 한 서버가 다운되어도 이메일 전달을 보장하기 위해 다양한 우선순위를 가진 여러 MX 레코드를 사용합니다. MX 조회 도구를 사용하여 도메인의 MX 레코드를 확인할 수 있습니다.
TXT 레코드: 확인 및 보안
TXT 레코드는 임의의 텍스트 데이터를 저장하며 이메일 보안 및 도메인 확인에 필수적이 되었습니다. 일반적인 용도는 다음과 같습니다:
- SPF 레코드: 도메인을 대신하여 이메일을 보낼 수 있는 서버 지정
- DKIM 레코드: 이메일 서명 확인을 위한 공개 키 제공
- DMARC 레코드: 실패한 이메일 인증 처리를 위한 정책 정의
- 도메인 확인: Google Search Console과 같은 서비스에 도메인 소유권 증명
- 사이트 확인: 다양한 웹 서비스 및 플랫폼에 대한 소유권 확인
전문가 팁: TXT 레코드는 문자열당 255자 제한이 있지만 단일 레코드에서 여러 문자열을 연결할 수 있습니다. 긴 DKIM 키는 종종 DNS 제약 조건 내에 맞추기 위해 이 기술을 사용합니다.
DNS 조회 명령어 및 도구
연결 문제를 해결하거나, DNS 변경 사항을 확인하거나, 도메인 구성을 조사하든, 여러 명령줄 도구와 온라인 서비스가 DNS 레코드를 쿼리하는 데 도움이 될 수 있습니다.
명령줄 DNS 도구
nslookup은 Windows, macOS 및 대부분의 Linux 배포판에 포함된 가장 널리 사용 가능한 DNS 조회 도구입니다. 기본 사용법은 간단합니다:
nslookup example.com
nslookup -type=MX example.com
nslookup example.com 8.8.8.8첫 번째 명령은 기본 A 레코드 조회를 수행합니다. 두 번째는 특별히 MX 레코드를 쿼리합니다. 세 번째는 기본 리졸버 대신 Google의 DNS 서버(8.8.8.8)를 사용하여 쿼리합니다.
dig(Domain Information Groper)는 더 강력하고 자세한 출력을 제공합니다. DNS 전문가가 선호하는 도구이며 macOS 및 Linux에서 기본적으로 사용할 수 있습니다:
dig example.com
dig example.com MX
dig example.com +short
dig @8.8.8.8 example.com
dig example.com +trace+short 플래그는 답변만 포함된 간결한 출력을 제공합니다. +trace 플래그는 루트 서버에서 권한 있는 네임서버까지의 완전한 해석 경로를 보여주며, 이는 문제 해결에 매우 유용합니다.
host는 dig의 더 간단한 대안으로, 추가 세부 정보 없이 깔끔한 출력을 제공합니다:
host example.com
host -t MX example.com
host -a example.com온라인 DNS 조회 도구
웹 기반 DNS 도구는 명령줄 유틸리티에 비해 여러 위치에서 쿼리할 수 있는 기능을 포함하여 장점을 제공합니다