DNS
-
우리는 웹브라우저에서 원하는 사이트에 접속을 할 때 www.wingeat.com, www.google.com과 같은 도메인을 입력하여 사이트에 접근함
- 그러나, 웹 브라우저는 기본적으로 IP 주소를 활용하여 상호작용을 하고 있으며, ip주소를 도메인으로 변환할 수 있도록 만들어주는 것이 바로 DNS의 역할
DNS의 탄생 과정
-
host 간의 네트워킹이 그리 많지 않았던 시절에는 ip주소가 그렇게 많지 않았기 때문에 그냥 ip주소를 암기하여 내가 원하는 웹 환경에 접근을 하면 되었을 것
-
점차 네트워크의 양이 늘어나면서 ip 주소를 암기하여 접근을 하는 방식이 불가능해지고 좀 더 암기하기 쉬운 문자 형태의 주소가 도입되게 되었고, ip와 문자를 매칭시켜 hosts.txt라는 파일에 저장하여 관리하기 시작
-
그러다 인터넷이 발달하기 시작하면서 네트워크에 연동된 호스트가 너무 많아져 개별 호스트에서 독자적으로 이를 관리하기가 힘들어졌고, SRI(stanfor research institute)라는 기관에서 호스트를 관리하게 됨
-
그러나 이 역시 빈번한 파일의 수정으로 인한 관리의 어려움, 개별 호스트들이 항상 파일을 다운받아 최신 상태를 유지해야했고, 파일의 용량이 기하급수적으로 늘어남에 따라 새로운 형태의 관리체계가 필요하게 됨
-
-
이를 위해 만들어 진 것이 바로 Domain Name Server!
DNS의 특징
-
각 도메인이 각자의 영역별로 이름의 생성, 변경, 삭제 등의 관리를 독자적으로 수행
-
계층 구조를 구성함으로써 분산된 이름 관리 체계를 유지하며 해당 도메인 내에서의 중복이 없다면 유일성을 가질 수 있음
-
분산구조 데이터베이스 시스템을 구현 및 서버-클라이언트 모델의 프로토콜을 도입
DNS의 구성요소
1. 도메인 네임스페이스
- DNS는 모든 인터넷 트래픽을 하나의 서버에서 모두 담당할 수 없기 때문에 분산하여 구성되어 있으며, 계층적 구조를 이루고 있음
2. 리소스 레코드
-
도메임 네임에 설정할 수 있는 다양한 데이터 유형으로 DNS에서 제공할 수 있는 실제 정보를 정의
-
DNS 메시지에 포함된 리소스 레코드는 리졸버에게 전달되며, 리졸버는 이 레코드를 자신이 관리하는 캐시 메모리에 저장하는 데 저장시간은 레코드 내 TTL 필드에 의해 결정
-
주요 레코드 유형
-
A : IPv4 주소
-
AAAA : IPv6 주소
-
PTR : IP 주소에 대한 도메인명을 매핑
-
NS : 네임서버의 정보
-
SOA : 도메인에 대한 권한이 있는 서버 정보
-
CNAME : 원래 도메인에 대한 별칭 도메인
-
MX : 메일서버의 정보
-
TXT : 텍스트 메모
-
3. 네임서버
-
도메인이름과 리스소 레코드 데이터를 저장하여 DNS 쿼리에 대한 응답을 수행하는 서버
-
Root DNS
-
루트 네임 서버는 세계적으로 13개의 서버가 구축되어 있으며, DNS 레코드를 요청하는 첫 번째 단계
-
요청된 도메인의 확장자(.com, .net, .kr, .us 등)에 따라 해당 TLD 네임 서버의 정보를 local DNS에 전달
-
-
Top Level DNS
-
.com, .net과 같은 주소를 가진 모든 도메인 이름 정보를 갖고 있는 네임서버
-
local DNS로부터 받은 쿼리를 해당 도메인의 ip주소에 대한 권한이 있는 네임서버의 정보를 담아 응답
-
TLD는 두 가지의 형태를 가지고 있음
-
일반 최상위 도메인 : 국가별로 고유하지 않은 도메인. .com, .org, .net, .gov 등
-
국가 코드 최상위 도메인 : 국가 또는 주와 관련된 도메인. .uk, .us, .jp 등
-
-
-
권한이 있는 DNS
-
일반적으로 ip 주소를 확인하는 가장 마지막 단계에 있는 네임서버
-
도메인 이름에 고유한 정보를 포함하고, A 레코드에서 찾은 ip 주소를 local DNS에 제공
-
4. 리졸버
- 네임서버에 대한 데이터를 조회하는 기능을 수행하며 클라이언트 역할을 한다고 하면 이해가 편함
DNS 동작 과정
-
브라우저에서 'www.naver.com'을 입력했을 때, 가장 먼저 클라이언트의 캐시 메모리와 hosts 파일을 통해 해당 도메인에 대한 정보가 있는지 확인
-
그리고 기존에 접속했다는 정보가 없다면, 클라이언트에서는 local DNS에 도메인에 대한 정보를 요청하는데 클라이언트와 local DNS 간의 정보 교환을 recursive query라고 칭함
-
만약 그 정보가 local DNS에 존재하지 않을 경우, local DNS에서는 Root DNS에 질의를 하고 Root DNS에서는 도메인을 분석하여 .com DNS에 문의할 수 있도록 응답
-
이러한 절차의 진행을 위해서는 최소한 루트 네임서버의 ip주소를 알고 있어야 하며 이는 'root.hint'라는 환경 설정 파일에 그 정보가 있음
-
우리는 .com으로 주소를 마무리하지만 서버에서는 .com.으로 인식하고 있으며, 마지막에 들어간 .은 root를 의미
-
-
그리고 다시 local DNS에서는 응답을 바탕으로 .com DNS에 질의를 하고 .com DNS에서는 하위에 있는 naver.com에 문의할 수 있도록 응답
-
local DNS에서는 응답받은 naver.com DNS에 질의를 하고 관련 DNS에서는 'naver.com'의 ip 주소를 응답해주며, 비로소 클라이언트에게 받은 주소를 전달
- 3~5 번의 과정과 같이 local DNS가 여러 서버를 차례대로 순회하여 주소를 찾는 과정을 Iterative query라 칭함
좀 더 간단하게 표현하면 이런 과정
보안 관련 이슈
- DNS도 해커의 데이터 위.변조에서 자유롭지 않으며, 웹 접속 트래픽을 다른 사이트로 전환하는 형태의 캐시 포이즈닝 등이 빈번하게 발생
-
기본적으로는 IP 주소, UDP 포트번호, DNS 메시지의 ID 필드 값이 Request했을 때와 Response했을 때의 메시지가 동일한 지 확인하는 형태
-
그러나 해커가 IP 주소, UDP 포트 정보를 미리 파악하는 것은 그렇게 어렵지 않은 일이며, 또한 메시지 ID 역시 관련 이슈가 발생하기 전에는 순차적으로 숫자가 증가하는 형태였기 때문에 위.변조된 데이터를 삽입하기 좋은 환경
-
이러한 행위가 가능한 이유는 DNS 표준이 처음 개발되었을 때 위.변조에 대한 철저한 고려가 없이 개발되었기 때문
DNSSEC : DNS 캐시 포이즈닝 공격과 같은 보안 문제를 해결하기 위해 개발
- DNS 응답 메시지의 각 섹션에 설정되는 리스소 레코드를 보호하기 위해 전자서명 메커니즘을 적용하여 보안적인 취약점을 해결
- 위와 같이 DNSSEC 표준이 적용되었을 경우, IP 주소, UDP 포트 번호, DNS 트랜잭션 ID가 일치하더라도 응답 메시지의 answer section에 설정된 서명 검증을 통과하지 못한다면 위.변조가 불가능해짐
