IPAddress-Lookup.com

DNS란 무엇이며 어떻게 작동하나요?

IPAddress-Lookup.com ·

브라우저에 웹사이트 이름을 입력할 때마다, 그 사이트가 실제로 어디에 위치해 있는지 파악하기 위해 눈에 보이지 않는 시스템이 작동하기 시작합니다. 이 시스템은 도메인 이름 시스템(Domain Name System, DNS)으로, 인터넷에서 가장 중요한 인프라 중 하나입니다. 이 시스템이 없다면, example.com과 같은 친숙한 이름 대신 방문하는 모든 웹사이트의 긴 숫자열을 외워야 할 것입니다. 이 가이드에서는 DNS가 정확히 무엇인지 설명하고, 실제 조회 과정을 처음부터 끝까지 추적하며, 주요 레코드 유형을 하나하나 분석하고, 여러분이 직접 DNS를 확인하고 문제를 해결하는 방법을 알려드리겠습니다.

DNS란 무엇인가?

DNS는 인터넷의 전화번호부입니다. 컴퓨터는 사람이 읽을 수 있는 이름을 사용해 통신하지 않고, 숫자 주소를 사용해 통신합니다. 전화로 친구에게 연락할 때, 친구의 이름을 누르는 것이 아니라 번호를 누르지만, 아마도 친구의 이름을 기억하고 있고 연락처 목록이 이를 숫자로 변환해 주기를 기대할 것입니다. DNS는 인터넷에서 이와 동일한 역할을 합니다. www.example.com과 같이 사람들이 기억하기 쉬운 도메인 이름을, 기계가 실제로 트래픽을 라우팅하는 데 사용하는 숫자 형태의 IP 주소(예: IPv4의 경우 93.184.216.34, IPv6의 경우 더 긴 16진수 문자열)로 변환합니다.

이러한 변환이 중요한 이유는 IP 주소가 변경될 수 있기 때문입니다. 웹사이트는 새로운 서버로 이전하거나, 호스팅 제공업체를 변경하거나, 전 세계 수십 개의 데이터 센터에 콘텐츠를 분산할 수 있습니다. 이름은 기본 주소가 변경되더라도 변함없이 유지되는 안정적이고 기억하기 쉬운 식별자를 제공합니다. DNS는 이러한 약속을 지키는 계층으로, 전 세계에서 초당 수십억 번씩 이름을 주소로 변환합니다. 또한 DNS는 분산 시스템이기 때문에, 단일 컴퓨터가 전체 주소록을 보유하지 않습니다. 대신 책임이 방대한 계층 구조의 서버들에 분산되어 있으며, 바로 이 점이 DNS를 빠르고 탄력적이며 전 지구적으로 확장 가능하게 만듭니다.

DNS 조회에 관여하는 주체들

쿼리의 경로를 추적하기 전에, 관련 주체들을 먼저 알아보는 것이 도움이 됩니다. 각 주체는 특정 역할을 맡고 있으며, 단 한 번의 조회만으로도 이 모든 주체들이 연루될 수 있습니다:

  • 스터브 리졸버(Stub resolver) — 운영 체제에 내장된 작은 소프트웨어입니다. 애플리케이션에 주소가 필요할 때, 스터브 리졸버는 요청을 다음 단계로 전달합니다. 자체적으로 수행하는 작업은 거의 없습니다.
  • 재귀형 리졸버 — 주된 역할을 담당하는 서버로, 대개 인터넷 서비스 제공업체(ISP)나 8.8.8.8, 1.1.1.1과 같은 잘 알려진 공용 서비스 제공업체에서 운영합니다. 사용자의 질의를 받아 최종 답을 찾기 위해 필요한 모든 작업을 수행한 후, 그 결과를 사용자에게 전달합니다.
  • 루트 네임 서버 — 계층 구조의 최상위에 위치합니다. 이 서버들은 특정 웹사이트의 주소를 알지는 못하지만, 각 최상위 도메인을 담당하는 서버를 찾을 수 있는 위치를 알고 있습니다.
  • TLD 네임 서버 — .com, .org, .net과 같은 최상위 도메인을 담당합니다. 이 서버들은 해당 도메인 아래에 등록된 각 도메인을 관리하는 권한 있는 서버가 어디인지 알고 있습니다.
  • 권위 네임 서버 — 최종적인 진실의 원천입니다. 이 서버들은 특정 도메인에 대한 실제 레코드를 보유하고 있으며, 확실한 답변을 제공합니다.

실제 쿼리 추적: www.example.com 해결 과정

단일 요청 과정을 단계별로 살펴보겠습니다. 브라우저에 www.example.com을 입력하고 Enter 키를 누른다고 가정해 봅시다. 아직 캐시에 저장된 내용이 없다고 가정할 때, 뒤에서 일어나는 과정은 다음과 같습니다:

  1. 브라우저는 스텁 리졸버에 요청을 보냅니다. 운영 체제의 스텁 리졸버는 www.example.com에 대한 요청을 수신합니다. 먼저 자체 로컬 캐시를 확인합니다. 최근에 이 이름을 조회한 적이 있다면 즉시 답변을 반환하며, 이 단계에서 과정이 종료됩니다.
  2. 스텁 리졸버는 재귀 리졸버에 연락합니다. 캐시에 저장된 답변이 없으므로, 스텁 리졸버는 쿼리를 사용자가 설정한 재귀 리졸버로 전달합니다.
  3. 재귀 리졸버는 루트 서버에 쿼리를 보냅니다. 재귀 리졸버는 아직 .com이 어디에 있는지 모르므로, 루트 서버 중 하나에 문의합니다. 루트 서버는 www.example.com을 알지 못하지만, 다음과 같은 참조 정보를 응답으로 보냅니다. "그 답변은 없지만, .com을 담당하는 서버는 다음과 같습니다."
  4. 재귀적 리졸버는 .com TLD 서버에 쿼리를 보냅니다. 해당 참조 정보를 따라, 리졸버는 .com TLD 서버에 www.example.com에 대해 문의합니다. TLD 서버는 또 다른 참조 정보를 포함한 응답을 보냅니다: “해당 주소는 알 수 없지만, example.com의 권한 있는 네임 서버는 다음과 같습니다.”
  5. 재귀적 리졸버는 권한 있는 서버에 쿼리를 보냅니다. 마지막으로, 리졸버는 example.com의 권한 있는 네임 서버에 쿼리를 보냅니다. 이 서버는 실제 레코드를 보유하고 있으며, “www.example.com의 주소는 93.184.216.34입니다.”라고 명확하게 답변합니다.
  6. 이 답변이 사용자에게 전달됩니다. 재귀적 리졸버는 이 답변을 캐시에 저장하고, 이를 스텁 리졸버에 전달하면, 브라우저가 해당 IP 주소로 연결을 시도합니다. 이 전체 과정은 일반적으로 수십 밀리초 내에 완료됩니다.

재귀적 쿼리와 반복적 쿼리의 차이

위의 설명은 두 가지 서로 다른 쿼리 방식을 보여 주며, 이 차이를 이해하면 많은 혼란을 해소할 수 있습니다. 기기가 재귀적 리졸버에 질문을 할 때, 기기는 완전한 최종 답변을 기대합니다. 이것이 바로 재귀적 쿼리입니다. 즉, 리졸버는 완전한 결과를 반환하기 위해 필요한 모든 조치를 취할 책임을 집니다. 기기는 그저 기다리기만 하면 됩니다.

재귀적 리졸버가 루트, TLD 및 권한 서버와 주고받는 통신은 반복적 쿼리입니다. 각 서버는 사용자를 대신해 답을 찾아 나서지 않습니다. 대신, 해당 서버가 보유한 최선의 정보, 즉 대개 목적지에 한 걸음 더 가까워지는 참조 정보를 응답으로 반환합니다. 그런 다음 재귀적 리졸버는 이 과정을 반복하며, 권위 있는 답변에 도달할 때까지 계층 구조를 따라 아래로 내려갑니다. 간단히 말해, 기기는 재귀적으로 요청하고, 리졸버는 반복적으로 처리합니다.

모든 계층에서의 캐싱과 TTL

모든 조회 요청이 권한 있는 서버까지 먼 거리를 이동해야 한다면, 인터넷 속도는 극도로 느려지고 루트 서버는 부하로 인해 마비될 것입니다. 캐싱은 이러한 상황을 방지합니다. 거의 모든 계층에서 응답이 일시적으로 저장되어 재사용될 수 있습니다. 브라우저, 운영 체제, 그리고 재귀적 리졸버는 대량의 데이터를 캐싱합니다.

레코드가 캐시에 저장될 수 있는 기간은 TTL(Time to Live, 유효 기간)에 의해 제어되며, 이는 초 단위로 측정되고 도메인 소유자가 설정합니다. TTL이 3600인 레코드는 1시간 동안 캐시에 저장될 수 있으며, 그 후 리졸버는 새로운 사본을 가져와야 합니다. TTL을 짧게 설정하면 레코드를 신속하게 변경할 수 있어 서버 마이그레이션 시 유용하지만, 쿼리 양이 증가합니다. TTL을 길게 설정하면 성능이 향상되고 부하가 줄어들지만, 변경 사항이 전 세계로 전파되는 데 더 오랜 시간이 걸립니다. 이 때문에 관리자들은 계획된 변경 하루 전에 레코드의 TTL을 낮추고, 변경 후에는 다시 높이는 경우가 많습니다.

DNS 계층 구조와 루트 서버

DNS는 역방향 트리 구조로 구성되어 있습니다. 최상위에는 루트가 위치하며, 일반적으로 보이지 않는 하나의 점으로 표시됩니다. 루트 아래에는 .com, .org와 같은 최상위 도메인(TLD)과 .uk, .de와 같은 국가 코드 도메인이 있습니다. 각 TLD 아래에는 example.com과 같이 개인이나 조직이 등록하는 2단계 도메인이 있습니다. 그 아래에는 www나 mail과 같은 하위 도메인이 위치합니다. 도메인 이름을 오른쪽에서 왼쪽으로 읽으면 일반적인 것에서 구체적인 것으로 계층 구조를 따라 내려가는 순서가 됩니다.

루트는 흔히 “13개의 루트 서버”로 알려진 시스템에 의해 운영됩니다. 실제로 이는 A부터 M까지 명명된 13개의 클러스터로, 각 클러스터는 서로 다른 기관에서 운영합니다. 이 13개 주소 뒤에는 애니캐스트(anycast)라는 기술을 사용하여 전 세계에 분산된 수백 대의 물리적 서버가 있으며, 이 기술은 사용자의 요청을 가장 가까운 가용 인스턴스로 라우팅합니다. 이것이 바로 소수의 명명된 진입점이 낮은 지연 시간과 중단 및 공격에 대한 높은 복원력을 바탕으로 전 세계의 쿼리에 안정적으로 응답할 수 있는 방식입니다.

DNS 레코드 유형 설명

도메인의 DNS 영역은 레코드들의 집합이며, 각 레코드 유형은 고유한 목적을 수행합니다. 웹사이트를 운영하거나 이메일을 관리하는 사람이라면 이를 이해하는 것이 필수적입니다. 아래 표는 가장 중요한 유형들을 각각의 예시와 함께 요약한 것입니다.

레코드 목적 예시
A 이름을 IPv4 주소로 매핑합니다 example.com → 93.184.216.34
AAAA 이름을 IPv6 주소에 매핑합니다 example.com → 2606:2800:220:1:248:1893:25c8:1946
CNAME 한 이름을 다른 표준 이름에 별칭으로 지정합니다. www.example.com → example.com
MX 도메인의 이메일을 수신하는 메일 서버를 지정합니다. 10 mail.example.com
TXT 임의의 텍스트를 포함하며, 이메일 인증에 널리 사용됩니다. "v=spf1 include:_spf.example.com ~all"
NS 도메인을 해당 권한 있는 네임 서버에 위임합니다. ns1.example.com
SOA 권한 시작(Start of Authority); 영역 메타데이터 및 갱신 타이머를 보관합니다 ns1.example.com admin.example.com 2026070101
CAA 어떤 인증 기관이 인증서를 발급할 수 있는지 명시합니다 0 "letsencrypt.org" 발급
PTR 역조회, IP를 이름으로 매핑 34.216.184.93.in-addr.arpa → example.com

A 및 AAAA 레코드

이 레코드들은 이름을 주소와 연결하는 핵심 요소입니다. A 레코드는 IPv4 주소를 가리키고, AAAA 레코드는 IPv6 주소를 가리킵니다. 도메인은 두 프로토콜을 사용하는 클라이언트 모두 접근할 수 있도록 두 레코드를 모두 가질 수 있습니다. 브라우저가 "example.com은 어디에 있나요?"라고 묻는 경우, 최종 답변을 제공하는 것은 대개 이 두 레코드 중 하나입니다.

CNAME 레코드

CNAME은 별칭을 생성하여 한 이름을 다른 정규 이름으로 전달합니다. 이는 일반적으로 www를 기본 도메인으로 가리키거나, 사용자 지정 하위 도메인을 호스팅 제공업체의 주소로 가리키는 데 사용됩니다. 중요한 규칙 중 하나는 CNAME이 동일한 이름에 다른 레코드와 공존할 수 없다는 점입니다. 이 때문에 도메인의 루트에는 일반적으로 CNAME 대신 A 또는 AAAA 레코드가 사용됩니다.

MX 및 이메일 레코드

MX 레코드는 어떤 서버가 해당 도메인의 메일을 수신하는지 알리며, 우선순위 번호를 통해 시도 순서가 결정됩니다. 숫자가 낮을수록 우선순위가 높으므로, 우선순위 10인 서버가 우선순위 20인 서버보다 먼저 시도됩니다. 하지만 MX 레코드는 이메일 DNS의 일부에 불과합니다.

TXT 레코드: SPF, DKIM 및 DMARC

TXT 레코드는 자유 형식의 텍스트를 저장하며, 이메일 분야에서는 세 가지 상호 연계된 인증 메커니즘을 구현하는 데 이 레코드를 크게 의존합니다. SPF는 해당 도메인을 대신하여 메일을 보낼 수 있는 서버 목록을 제공하여, 수신자가 위조 메일을 차단할 수 있도록 돕습니다. DKIM은 암호화 공개 키를 공개하여, 수신자가 해당 메시지가 귀하의 도메인에 의해 서명되었으며 전송 중에 변조되지 않았음을 확인할 수 있게 합니다. DMARC는 이 두 가지를 결합하여, SPF 또는 DKIM 검사에 실패한 메시지에 대해 수신자가 어떻게 처리해야 하는지, 그리고 보고서를 어디로 보내야 하는지를 지시합니다. 이 세 가지가 함께 현대 이메일 전달성의 중추를 이룹니다.

NS 및 SOA 레코드

NS 레코드는 권한을 위임하여, 특정 영역을 담당하는 서버를 지정합니다. SOA 레코드는 모든 영역의 최상위에 위치하며, 주 네임 서버, 담당 연락처, 영역이 수정될 때 변경되는 일련 번호, 보조 서버가 영역 사본을 갱신하는 주기를 제어하는 타이머와 같은 관리 세부 정보를 포함합니다.

CAA 및 PTR 레코드

CAA 레코드는 도메인에 대한 인증서를 발급할 수 있는 인증 기관을 제한하여, 무단 인증서로부터 보호하는 추가적인 보안 계층을 제공합니다. 이러한 인증서가 트래픽을 어떻게 보호하는지 이해하려면, SSL 인증서 설명 가이드를 참조하십시오. PTR 레코드는 역방향 DNS를 처리하여 IP 주소를 호스트 이름으로 매핑하며, 메일 서버는 발신자의 신뢰성을 판단하기 위해 이 정보를 자주 확인합니다.

DNS와 이메일 전달률

DNS는 웹만큼이나 이메일에도 중요하다고 할 수 있습니다. 메일 서버가 귀하의 도메인으로 메시지를 전달하고자 할 때, 올바른 수신처를 찾기 위해 MX 레코드를 조회합니다. 수신 서버가 수신된 메시지가 신뢰할 수 있는지 판단할 때는 SPF, DKIM, DMARC 레코드를 확인하고, 종종 발신 서버의 PTR 레코드도 검증합니다. 이 중 하나라도 누락되거나 잘못 구성되어 있으면, 정상적인 메일도 스팸 폴더로 이동하거나 아예 거부될 수 있습니다. DNS 이메일 레코드를 올바르게 설정하는 것은 메시지가 정크 폴더로 사라지지 않고 수신함으로 원활하게 전달되도록 하기 위해 취할 수 있는 가장 효과적인 조치 중 하나입니다.

DNS 보안

DNS는 매우 기초적인 요소이기 때문에 공격 대상이 되어 왔으며, 이를 강화하기 위한 여러 기술이 존재합니다:

  • DNSSEC는 DNS 레코드에 암호화 서명을 추가하여, 리졸버가 응답이 실제로 권한 있는 출처에서 왔으며 변조되지 않았음을 확인할 수 있도록 합니다. 이는 데이터의 무결성을 보호하지만 데이터를 암호화하지는 않습니다.
  • DNS over HTTPS(DoH)와 DNS over TLS(DoT)는 기기와 재귀형 리졸버 간의 통신을 암호화합니다. 기존에는 DNS 쿼리가 평문으로 전송되어 네트워크 경로상의 누구든지 이를 확인하거나 심지어 변경할 수도 있었습니다. DoH와 DoT는 쿼리를 암호화하여 이러한 취약점을 해소합니다.
  • 캐시 포이즌(Cache poisoning)은 악의적인 공격자가 리졸버를 속여 허위 응답을 캐시에 저장하게 함으로써 피해자를 사기성 서버로 리디렉션하는 전형적인 공격 방식입니다. DNSSEC와 무작위 소스 포트와 같은 최신 리졸버 보호 기능은 이러한 공격을 실행하기 훨씬 더 어렵게 만듭니다.

일반적인 DNS 문제 및 문제 해결

웹사이트가 로드되지 않을 때, 그 원인은 대개 DNS에 있습니다. 가장 빈번하게 발생하는 문제로는 다음이 있습니다.

  • 전파 지연. 레코드를 변경한 후에도 TTL이 만료될 때까지 오래된 캐시된 값이 남아 있을 수 있습니다. 이 때문에 변경 사항이 본인에게는 적용된 것처럼 보이지만 다른 사용자에게는 아직 반영되지 않을 수 있습니다.
  • 오타 및 누락된 레코드. 호스트 이름의 철자 오류나 A 레코드의 누락은 간과하기 쉬운 오류를 유발합니다.
  • 이름 서버 불일치. 등록 기관이 도메인을 잘못된 이름 서버로 지정하면, 정성껏 작성한 레코드도 전혀 참조되지 않습니다.
  • CNAME 충돌. 동일한 이름에 다른 레코드와 함께 CNAME을 배치하면 이름 해결이 중단됩니다.
  • 해결기 캐싱. 때로는 사용자의 기기나 라우터에 오래된 항목이 남아 있어 문제가 발생하기도 하는데, 이 경우 캐시를 비우면 해결됩니다.

DNS 레코드를 직접 확인하는 방법

DNS 레코드를 조회하기 위해 네트워크 엔지니어일 필요는 없습니다. 대부분의 시스템에서 사용할 수 있는 dig 및 nslookup과 같은 명령줄 도구를 사용하면 모든 레코드 유형을 직접 조회할 수 있습니다. 예를 들어, 도메인의 A 레코드를 조회하면 해당 도메인의 IPv4 주소가 반환되고, MX 레코드를 조회하면 메일 서버 정보가 표시됩니다. 명령줄 사용이 불편하다면, 온라인 DNS 조회 도구를 이용하면 별도의 소프트웨어 설치 없이 브라우저에서 어떤 도메인의 레코드든 조회할 수 있어, 최근 변경 사항이 전파되었는지 확인하거나 설정 오류를 진단하기가 쉽습니다.

DNS 레코드를 확인하는 습관을 들이면 시스템 전체가 더 명확하게 이해됩니다. 자신의 도메인에 대한 A, MX, TXT 레코드를 직접 확인할 수 있게 되면, 추상적이던 전화번호부는 자신이 관리하는 구체적이고 이해하기 쉬운 항목 모음이 됩니다. 그렇게 되면 사이트 속도가 느리거나, 이메일이 반송되거나, 인증서 경고가 나타나는 문제를 진단할 때 더 이상 추측에 의존할 필요가 없고, 레코드를 확인하기만 하면 됩니다.

자주 묻는 질문

DNS는 무엇의 약자인가요?

DNS는 도메인 이름 시스템(Domain Name System)의 약자입니다. 이는 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 서로 통신하는 데 사용하는 숫자형 IP 주소로 변환하는 분산 시스템입니다.

DNS가 왜 인터넷의 전화번호부라고 불리나요?

전화번호부를 통해 이름으로 사람의 전화번호를 찾을 수 있는 것처럼, DNS를 통해 컴퓨터는 도메인 이름으로 웹사이트의 IP 주소를 찾을 수 있습니다. 사용자는 기억하기 쉬운 이름을 기억하면 되고, DNS가 컴퓨터가 실제로 필요로 하는 숫자로 변환하는 작업을 처리합니다.

DNS 변경 사항이 적용되는 데 얼마나 걸리나요?

이는 레코드의 TTL(Time to Live)과 경로상의 리졸버들이 해당 레코드를 얼마나 적극적으로 캐시했는지에 따라 달라집니다. TTL이 짧으면 변경 사항이 몇 분 내에 반영될 수 있지만, 오래된 캐시 값이 여전히 사용 중인 경우 전 세계적으로 완전히 전파되는 데 최대 24~48시간이 소요될 수 있습니다.

재귀적 리졸버와 권한 서버의 차이점은 무엇인가요?

재귀적 리졸버는 사용자를 대신하여 다른 서버에 쿼리를 보내고 결과를 캐싱함으로써 답변을 찾는 작업을 수행합니다. 권한 서버는 도메인의 레코드를 실제로 보유하고 최종 답변을 제공하는 확실한 정보원입니다.

DNS는 암호화되어 있나요?

기존 DNS는 암호화되지 않으므로, 쿼리가 일반 텍스트로 전송됩니다. DNS over HTTPS 및 DNS over TLS와 같은 최신 표준은 기기와 리졸버 간의 트래픽을 암호화하는 반면, DNSSEC는 응답의 진위성을 확인하는 서명을 추가합니다.

도메인의 DNS 레코드는 어떻게 확인할 수 있나요?

dig나 nslookup과 같은 명령줄 도구를 사용하거나, 브라우저 기반 DNS 조회 서비스를 이용할 수 있습니다. 이를 통해 A, AAAA, MX, TXT와 같은 특정 레코드 유형을 조회하여 구성을 확인하거나 문제를 해결할 수 있습니다.