DNS는 "DNS 서버에게 IP주소를 받아온다"로 퉁쳐지는 경우가 많다. 이전에 공부를 했으나 네트워크의 경우 직접 사용하지 않으면 휘발되기 때문에 복습 + 조금 더 깊게 알아보려 한다!
What is DNS?
DNS, Domain Name System은 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다. 특정 컴퓨터 또는 네트워크로 연결된 임의의 장치의 주소를 찾기 위해, 사람이 이해하기 쉬운 도메인 이름을 숫자로 된 IP주소로 변환해준다. 일반적인 DNS 조회를 할 경우 UDP, Zone Transfer(영역 전송)을 수행할 경우 혹은 512Byte를 초과하는 DNS 패킷을 전송해야 할 경우 TCP를 사용한다.
흔히 전화번호부에 비유되는데, 인터넷 도메인 주소 체계로서 TCP/IP의 응용에서 www.example.com과 같은 주 컴퓨터의 도메인 이름을 192.168.1.0과 같은 IP주소로 변환하고 라우팅 정보를 제공하는 분산형 데이터베이스 시스템이다.
구성요소
Domain name space
Domain name space는 DNS가 저장 및 관리하는 계층적 데이터베이스이다. DNS에 등록된 모든 도메인 이름의 집합! 도메인 이름은 트리 구조로 구성되며 트리의 맨 위에 루트 도메인이 존재하고 그 아래로 `.com`, `.net`, `.org`와 같은 여러 최상위 도메인(Top-Level Domain)이 있다. 그다음엔 두 번째 수준 도메인 등이 이어진다. 각 도메인 이름 아래에 하위 도메인이 있을 수 있다. 예로, example.com 에는 www.example.com 및 mail.example.com과 같은 하위 도메인이 있을 수 있다.
트리의 각 노드는 0개 이상의 자원 레코드(Resource record)를 가진다. DNS가 제공하는 넓은 범위의 능력은 여러 유형을 가질 수 있는 자원 레코드의 다양성에 기인한다. Domain name 혹은 DNS zone과 관련된 개별 정보 항목을 갖는 레코드로써, 각각 이름과 값으로 바인딩된다. 이런 정보 항목들이 인터넷 상에서 분산된 데이터 베이스를 형성하게 되는 것이다. 결국 DNS는 분산된 DNS Name Server 자원 레코드의 집합인 것! DNS 질의에 대해 1이상의 자원 레코드 값을 채운 DNS 메시지로 응답을 하게 된다.
DNS Message의 뒷부분에 붙게 되는 자원레코드의 공통 형식
- Name : 도메인 이름 - 레코드가 적용되는 도메인
- Value : 그 이름에 대한 값
- Type : 각 유형을 나타냄 (A레코드, AAAA 레코드, MX 레코드, CNAME 레코드 등)
- Class : 레코드의 클래스 - 대부분의 경우 IN(Internet)으로 설정된다.
- TTL : DNS 캐싱 정보의 유지시간 - DNS Resolver가 이 레코드에 관한 정보를 캐싱(유지)하는 시간
- RD : 레코드에 대한 실제 데이터 - 레코드 유형에 따라 다양한 형식을 가질 수 있음. (A 레코드는 IPv4 주소, MX 레코드는 메일 서버의 우선순위와 도메인 등을 포함.)
도메인 이름은 점으로 구분한 레이블의 연속이라고 할 수 있다. RFC1034에서 정리한 내용에 따르면, 도메인은 루트 노드를 기준으로 하여 각 계층을 온점(.)으로 연결한 형태로 표기하며, 각 온점 사이의 문자열은 레이블(Label)로 명명하도록 정의되어 있다. 전체 도메인에 대한 크기는 255byte이며, 하나의 레이블 당 최대 63바이트 크기를 갖는다.
이때 루트 호스트는 크기가 0인 null 레이블을 가지며, 이름이 없다. 같은 레벨에서는 레이블(이름)이 유일해야 한다. 표기할 때 최하위 레이블을 왼쪽에 위치시키고 상위로 이동하면서 점으로 구분한 레이블을 표기하는 것으로 나타낸다. 최상위로부터 순차적으로 계층적 소속 관계를 나타낸다고 할 수 있다.
도메인 체계로 구분된 최상위 도메인은 대표적으로 아래로 분류된다.
- 일반 최상위 도메인
- gTLD(Generic Top Level Domain)
- New gTLD(New Generic Top Level Domain) - 2014년부터 ICCAN에서 이미 포화된 gTLD에 대한 대안으로 새로 선보인 서비스. 브랜드명, 지역명 등 제한이 없다.
- 국가 코드 최상위 도메인
- ccTLD(Country Code Top Level Domain)
Name space는 분산되어있다. 즉 전체를 제어하는 중앙 기관이 없다. 대신 다양한 조직이 name space의 다양한 부분을 관리하는 일을 한다. ICANN(Internet Corporation for Assigned Names and Numbers)은 고유한 도메인 이름과 IP 주소 할당 조정을 담당하고 개별 등록 기관은 고객에게 도메인 이름을 판매하고 DNS에서 해당 도메인 이름의 기록을 유지하는 일을 담당한다.
Name Server (DNS Server)
위에 잠시 나오듯, DNS에서 도메인 및 그 데이터에 대한 정보를 보유하고 관리하며 전세계적으로 분산되어 있는 DNS 서버를 말한다. DNS 서비스에서 가장 중요한 것은 분산 네트워크 서비스의 형태를 지원하는 것이다. 이를 위해 네임 서버가 여러 곳에 흩어져 전체 name space의 일부 정보를 전적으로 책임지며 유기적인 연관관계를 통해 전체 name server의 정보를 일관성있게 관리한다. 문자열로 표현된 도메인의 이름을 실제 컴퓨터가 통신할 때 사용하는 IP주소로 변환시키기 위해선 Domain Name Space의 트리 구조에 대한 정보가 필요한데, 이런 정보를 갖고 있는 서버를 네임 서버라고 한다.
구분
- Root Name Server 루트 네임 서버
ICANN(Internet corporation for Assigned Names ans Number: 국제 인터넷 주소 관리 기구)이 직접 관리하는 최상위 DNS 서버, TLD DNS 서버 IP 주소를 저장하고 안내하는 역할. - TLD Name Server 최상위 도메인 네임 서버
- Autoritative Name Server (Second-Level Domain Server) 권한 서버
최종 이름 서버로, 권한 있는 서버는 쿼리의 종착점이다. 어떤 호스트의 DNS Record를 실제로 갖고 있는 서버. 캐쉬된 DNS가 아닌 실제 정보로써 DNS 마스터 파일에 설정되어 있다. 일반적으로 도메인/호스팅 업체의 네임서버- 비 권한 서버 Non-Authoritative Name Server는 DNS가 캐싱된 데이터를 갖고 있는 서버를 지칭함. 주로 중간 단계에서 쿼리를 전달하고 캐시된 정보로 응답을 생성하는 역할을 수행한다. 로컬의 DNS 리졸버에게 도움을 준다.
- DNS Recursor Server 재귀 리졸버 또는 재귀 서버
확인을 위해 권한 서버 혹은 비권한 서버로 쿼리를 보내는 서버이다. 재귀 리졸버라는 명칭은 주어진 이름에 대한 각 쿼리를 수행하고 최종 결과를 반환한다는 데에서 비롯되었다.
위에서 존 Zone을 살짝 언급했는데 존은 DNS 관리 범위를 나탄낸다 . 존은 해당 존에 속하는 모든 호스트의 전체 자원 레코드 집합체와 최상위 호스트, 위임 서브 존, 위임된 서브 존에 관한 글루 데이터를 관리한다.
위임 서브 존? 하위 도메인을 다른 DNS 서버로 위임하여 관리하는 개념이다. 특정 도메인의 일부를 다른 DNS 서버에게 위힘하고 그 서버가 해당 도메인을 독립적으로 관리할 수 있도록 하는 것을 의미한다. 이를 설정하기 위해선 상위 도메인의 Name Server record를 수정하여 해당 서브 도메인의 DNS 책임을 갖는 네임 서버를 지정하면 된다.
글루 데이터? DNS 레코드의 일종으로 도메인 이름에 해당하는 IP 주소를 가리키는 특별한 정보를 의미한다.
예시 : 도메인 이름 example.com의 네임 서버가 ns1.example.com 및 ns2.example.com으로 구성되어 있다면, 이 네임 서버들에 대한 IP 주소를 가리키는 글루 데이터가 필요함. 이때 글루 데이터는 부모 도메인 (com 도메인)의 네임 서버에 저장된다.
DNS Resolver 해석기 (Local resolver)
해석기는 DNS 메시지 형식의 질의를 생성하고 이 질의를 네임 서버에게 전달하면 네임 서버는 회신용 DNS 메시지에 결과를 담아 해석기에 회신을 하게 된다. 네임 서버의 부담을 줄이기 위해 캐시 데이터를 활용한다. 이전엔 인증 데이터로 해당 데이터를 직접 관리할 책임이 있는 네임 서버로부터 받은 정보인데 호스트가 보관하고 있던 정보로 네임 서버로 질의하기 전에 재귀 서버에서 바로 데이터를 가져올 수 있게 해준다. 이는 TTL(Time to live) 을 두어 설정된 시간까지만 저장된다.
DNS 동작 과정
- 웹 브라우저에 URL을 입력한다. DNS 쿼리 발생
브라우저는 OS 내부 소켓 라이브러리의 리졸버 함수 호출.
➡️ 어플리케이션에서 호출되어 도메인 명을 IP 주소로 변환하는 리졸버 스텁 리졸버 Stub resolver - 스텁 리졸버는 요청을 받으면 먼저 캐시를 검색하여 레코드가 있는지 확인한다. OS캐시, 라우터 캐시를 확인하고, 이후 HOSTS 파일까지 확인하여 찾아본다.
- HOSTS 파일에 정보가 없을 경우 로컬 DNS 서버에 DNS 쿼리 도착, 도메인 해석 요청.
➡️ 로컬 DNS에서 도메인 해석을 담당하는 리졸버 Full resolver 풀 리졸버
스텁 리졸버가 로컬 DNS로 요청하는 과정을 재귀 질의 Recursive Query라 한다.
보통 로컬 DNS는 KT, SK 브로드 밴드와 같은 ISP 업체에서 관리하며 이외에 Google Public DNS, Quad9, Cloudflare 등 다양한 퍼블릭 DNS가 있다. - 풀 리졸버는 루트 DNS에게 요청하기 전에 본인이 가지고 있는 Resource Recordset 정보를 참조하여 응답하게 되고, 정보가 없다면 Root Hint 파일을 참조하여 계층적 순서로 반복 질의 Iterative Query를 한다. 🔽
- 루트 DNS 서버에게 하위 계층에 해당되는 TLD 부터, 레지스트리에서 관리하는 네임서버까지 도메인에 대한 정보를 요청하게 되고, 이 과정을 토대로 요청 도메인에 대한 주소 정보를 전달 받는다.
- 로컬 DNS에서는 이 정보를 재사용하기 위해 결과를 캐싱한다.
DNS Query 질의 유형
- 클라이언트 스텁 리졸버의 재귀 질의 과정
- DNS Cache → Hosts 파일 참조 → 로컬 DNS 서버 질의
- 로컬 DNS 풀 리졸버의 반복 질의 과정
- DNS Cache → Local DNS Zone 파일 참조 → 루트 서버 리스트를 담은 Root Hint 파일 참조 → 반복 질의
Recursive Query 재귀적 질의
재귀 서버와 클라이언트 사이에서 발생하는 쿼리, 제공된 답변은 전체 IP 주소에 대한 확인이거나 찾을 수 없다는 오류 메시지이다.
Iterative Query 반복적 질의
로컬 DNS 서버인 재귀 리졸버와 Root, TLD 및 권한 서버 등과 같은 비로컬 서버 사이에서 발생한다. 서버는 추천으로 응답한다. 권한 서버의 경우 도메인 이름이 있는 경우 재귀 서버에 도메인 이름을 제공한다.
비재귀적 질의
재귀 리졸버가 답변을 얻을 위치를 이미 알고 있는 쿼리. 재귀 리졸버가 이전 세션의 IP 주소를 캐시하고 있을 때, 해당 주소를 제공하는 경우 이는 비재귀 쿼리로 간주된다.
[DNS란? (도메인 네임 시스템 개념부터 작동 방식까지)]
[DNS Query, DNS Answer DNS 질의, DNS 응답]
[컴퓨터 네트워크 39장 - 도메인 네임 스페이스(Domain Name Space)]
[도메인 이름 데이터 포맷, 레이블, 그리고 FQDN]
[DNS (Domain Name System) 란? ]
[브라우저에서 요청한 도메인을 DNS 를 통해 해석되는 절차에 대해서 알아보자]
[도메인 이름 데이터 포맷, 레이블, 그리고 FQDN]
[[번역] Browser에 www.google.com을 검색하면 어떤 일이 일어날까?]
'Network' 카테고리의 다른 글
| 2. 애플리케이션과 플랫폼, 웹 서비스 (2) | 2023.08.24 |
|---|---|
| 1. HTTP, 인터넷 네트워크, 서버와 클라이언트, 월드 와이드 웹 (0) | 2023.08.09 |