DNS
1) 등장 배경
네트워크 통신은 결국 IP 주소를 필요로 하지만, 사람은 숫자 IP를 기억/사용하기 어렵습니다.
그래서 사람이 읽기 쉬운 도메인 이름을 사용하고, 이를 IP로 변환해주는 시스템으로 DNS가 등장했습니다.
2) DNS란?
정의: TCP/IP 네트워크에서 도메인 이름(FQDN) 을 IP 주소로 변환(이름 해석, name resolution)해주는 시스템
포트
UDP 53: 일반적인 질의/응답
TCP 53: Zone Transfer(영역 전송), 응답이 커서(전통적으로 512B 초과 등) UDP로 처리 어려운 경우
보안 강화 프로토콜
DoH(DNS over HTTPS), DoT(DNS over TLS) 사용 증가 추세
3) Zone Transfer(영역 전송)
DNS 서버는 자신이 담당하는 Zone(영역) 의 레코드(DB)를 가집니다.
고가용성을 위해 Primary(주) / Secondary(보조) 를 두고, Primary의 Zone 데이터를 Secondary로 복제/동기화하는 것이 Zone Transfer입니다.
데이터 크기가 크고 신뢰성이 중요하므로 TCP 사용
4) DNS가 UDP를 주로 사용하는 이유
속도/오버헤드
TCP는 3-way handshake 필요
UDP는 연결 설정 없이 즉시 전송 가능 → 질의/응답에 유리
요청 특성
DNS 질의는 보통 작은 패킷이며(전통적으로 512B 이하 중심), 손실되어도 재요청 비용이 낮음
서버 확장성
DNS는 동시 요청이 매우 많음
UDP는 연결 상태를 유지하지 않아 상태 관리 부담이 적고 더 많은 클라이언트를 수용 가능
5) DNS의 과거와 현재
과거: hosts.txt
각 컴퓨터가 hosts 파일을 직접 관리, 주기적으로 내려받아 최신화
호스트 수가 폭증하면서 업데이트 지연/배포 트래픽 증가 등으로 한계 발생
현재도 OS hosts 파일은 존재하며 DNS보다 우선순위가 높아 로컬 테스트/차단 등에 사용
현재: 분산 계층 구조(Domain Name Space)
전 세계 도메인을 단일 서버가 관리 불가
계층 구조로 분산 운영 + 각 조직이 자기 도메인 정보를 관리
6) DNS 서버 종류 (계층과 역할)
큰 분류
Non-Authoritative(권한 없음): 직접 정답 레코드를 “소유”하지 않고 조회/캐싱 중심
Authoritative(권한 있음): 실제 정답 레코드를 관리/응답 ( [ə│θɔːrəteɪtɪv; ə│θɑːrəteɪtɪv] )
흐름 구조(개념)
Root DNS Server
최상위. TLD DNS 서버들의 주소를 안내
ICANN이 관리, 전 세계적으로 Root 서버 그룹이 운영
TLD DNS Server (.com, .kr 등)
도메인 등록 기관(Registry)이 관리
해당 TLD 아래 도메인의 Authoritative DNS 주소(NS) 를 안내
Authoritative DNS Server (Route53, Cloudflare, Gabia 등)
실제 도메인 ↔ IP 매핑 레코드를 저장/관리
최종 정답을 반환
Recursive DNS Server (ISP DNS, 8.8.8.8, 1.1.1.1 등)
사용자가 처음 붙는 DNS 서버(리졸버)
Root→TLD→Authoritative로 대신 질의(재귀/반복 조회) 하고 결과를 캐싱(TTL)
7) DNS 리소스 레코드(Resource Record)
DNS는 도메인 관련 정보를 레코드 단위로 저장합니다.
주요 타입
SOA: 도메인 관리 정보, zone 전송/갱신 관련 정보, TTL/시리얼 등
NS: 해당 도메인을 관리하는 네임서버 정보
A: 도메인(FQDN) → IPv4
AAAA: 도메인(FQDN) → IPv6
CNAME: 별칭(Alias). 한 도메인을 다른 도메인으로 연결
MX: 메일 서버 정보
PTR: IP → 도메인(역방향 조회)
TXT: 텍스트 정보(예: SPF/DKIM 등 메일 인증에 활용)
ANY: 모든 레코드 요청(증폭 공격에 악용되어 대부분 제한/비활성화)
FQDN: 호스트명 + 도메인을 포함한 전체 주소 (예:
www.example.com)
8) DNS 동작 과정
도메인 계층 예시
.(Root, 보통 생략)com(TLD)example(2nd-level)www(subdomain)
기본 규칙(개념)
각 DNS 서버는 직속 하위 레벨을 안내할 수 있음
클라이언트(Resolver)는 최소 Root DNS에 대한 접근 단서를 가짐(보통 OS/리졸버 설정에 내장)
전체 흐름(브라우저에서
www.example.com접속)로컬 캐시 확인: 브라우저 캐시 → OS 캐시 → hosts
없으면 Recursive DNS(ISP 등) 에 질의
Recursive DNS에 캐시가 있으면 즉시 응답
없으면 Root에 물어 TLD(.com) DNS 주소를 받음(”다음 단계 안내”가 목적)
TLD DNS에 물어 example.com의 Authoritative DNS 주소(NS) 를 받음
Authoritative DNS에 물어 최종 IP(A/AAAA) 를 받음
Recursive DNS는 결과를 TTL 동안 캐싱
브라우저는 받은 IP로 서버에 접속
→ 최종 IP 원본을 들고있는 곳은 Authoritative DNS
Root / TLD는 “정답이 있는 곳이 어디인지” 안내하는 데이터
브라우저 / OS / Recursive는 캐시
캐싱 유효 기간은 TTL(Time To Live) 로 결정되고, TTL 만료 시 재조회 발생
Last updated