송수신하고자 하는 정보를 식별하기 위한 방법으로는 위치 기반 식별자인 URL과
이름 기반 식별자인 URN이 있다.
도메인 네임은 호스트의 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보이다.
www.google.com과 같은 문자열이 도메인 네임이다.
도메인 네임과 IP 주소는 네임 서버에서 관리한다.
도메인 네임을 관리하는 네임 서버는 DNS 서버라고 부른다.
도메인 네임을 네임 서버에 질의하면, 해당 도메인 네임에 대한 IP 주소를 알려주는 방식으로 도메인 네임을 통해 IP 주소를 알아낼 수 있다.
도메인 네임은 점(.)을 기준으로 계층적으로 분류된다.

루트 도메인은 점(.)으로 표현되며 도메인 네임의 마지막에 점이 찍힌 형태로 표기된다.
ex) www.google.com.
다만, 일반적으론 루트 도메인을 생략해서 표기한다.

www.example.com처럼 도메인 네임을 모두 포함하는 도메인 네임을 전체 주소 도메인 네임(Fully-Qualified Domain Name)이라고 한다.
FQDN의 모든 부분을 고려한 도메인 네임은 www.example.com 하나밖에 없다.
즉, 마지막 3단계 도메인까지 고려하면 www.example.com이라는 호스트를 식별할 수 있는 도메인 네임을 얻을 수 있다.
이런 점에서 FQDN의 첫 번째 부분(www)을 호스트 네임이라 부르기도 한다.
이렇게 계층적인 도메인 네임을 효율적으로 관리하기 위해 네임 서버 또한 계층적인 형태를 이룬다.
네임 서버는 여러 개 존재하며 전 세계 여러 군데에 위치해 있다.
이렇게 계층적이고 분산된 도메인 네임에 대한 관리 체계를 도메인 네임 시스템, 줄여서 DNS라고 부른다.
DNS는 애플리케이션 계층 프로토콜이다.
DNS가 뭔가요?
DNS는 도메인 네임을 IP 주소로 변환해주는 프로토콜이자 계층형 구조로 구현된 분산 데이터베이스입니다.
호스트가 도메인 네임에 대한 IP 주소를 요청하면 DNS는 계층 질의를 통해 IP 주소를 얻어다가 줍니다.
만약 로컬 DNS에 해당 IP 주소가 캐싱되어 있다면 바로 받습니다.
빠른 응답을 제공하기 위해 DNS는 UDP 기반으로 동작하고 DNS 서버들은 요청 정보를 캐싱해둡니다.
DNS 작동 방식에 대해 설명해주세요
사용자가 웹 브라우저에서 도메인 이름을 입력합니다.
브라우저는 해당 도메인을 DNS 서버에 보내서 IP 주소를 요청합니다.
DNS는 IP 주소를 찾아서 브라우저에 보내고, 브라우저는 IP 주소를 통해 서버에 요청을 보냅니다.
DNS 작동 방식에 대한 더 자세한 부분은 밑에서 다루도록 하겠다.
호스트 에일리어싱
복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질 수 있다.
[ 별칭 호스트 이름, 정식 호스트 이름 ]
메일 서버 에일리어싱
기억하기 쉬운 전자메일 별칭 호스트 이름을 사용한다.
부하 분산
인기 있는 사이트는 여러 서버를 가지며, 이는 하나의 호스트 이름에 여러 IP 주소를 가진다.
DNS 데이터베이스는 이 IP 주소 집합을 가지며, 클라이언트가 호스트 이름에 대한 DNS 질의를 하면 서버는 IP 주소 집합 전체를 가지고 순환식으로 응답한다.
-> 단일 DNS 서버에 있는 중앙 집중 데이터베이스는 확장성이 전혀 없다.
DN 서버를 분산 및 계층화 시킨다.
루트 DNS - TLD DNS - 책임 DNS - 로컬 DNS
IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정을 리졸빙이라고 표현한다.
이 과정에서 네임 서버가 사용되며, 네임 서버의 유형은 크게 4가지가 있다.
로컬 네임 서버루트 네임 서버TLD 네임 서버책임 네임 서버
local name server
클라이언트와 맞닿아 있는 네임 서버로, 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버이다.
로컬 네임 서버는 일반적으로 ISP에서 할당해주지만, 공개 DNS 서버를 이용할 수도 있다.
root name server
루트 도메인을 관장하는 네임 서버로, 질의에 대해 TLD 네임 서버의 IP 주소를 반환할 수 있다.
Top-Level Demain name server
질의에 대해 TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환할 수 있다.
authoritative name server
특정 도메인 영역을 관리하는 네임 서버로, 자신이 관리하는 도메인 영역의 질의에 대해서는 다른 네임 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버이다.
로컬 네임 서버가 마지막으로 질의하는 네임 서버이다.
호스트가 DNS 질의를 보내면, 이 질의는 먼저 프록시로 동작하는 로컬 DNS 서버에게 전달되고, 그 로컬 DNS는 캐싱된 데이터에 포함되는지 확인한다.
포함되면 IP 주소를 호스트에게 전달하고, 포함되지 않으면 질의를 DNS 서버 계층으로 전달한다.

로컬 네임 서버가 네임 서버들에게 질의하는 방법에는 크게 '재귀적 질의'와 '반복적 질의' 두 가지가 있다.

클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면, 로컬 네임 서버가 루트 네임 서버에게 질의하고,
루트 네임 서버가 TLD 네임 서버에게 질의하고, TLD 네임 서버가 책임 네임 서버에게 질의하는 과정을 반복하며
최종 응답 결과를 역순으로 전달받는 방식이다.

클라이언트가 로컬 네임 서버에게 IP 주소를 알고 싶은 도메인 네임을 질의 하면,
로컬 네임 서버는 루트 도메인 서버에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답받고,
다음으로 TLD 네임 서버에게 질의해서 책임 네임 서버의 주소를 응답받는 과정을 반복하다 최종 응답 결과를 클라이언트에게 알려주는 방식이다.
하지만 이러한 도메인 네임 리졸빙 과정에는 문제가 있다.
리졸빙하는데 8개의 단계를 거쳐야 하기에 시간이 오래 걸리고 네트워크상의 메시지 수가 지나치게 늘어날 수 있다는 것이다.
그렇기에 네임 서버들이 기존에 응답받은 결과를 DNS 캐시에 임시로 저장했다가 추후 같은 질의에 이를 활용하는 경우가 많다.
DNS 질의 종류에 대해 설명해주세요.
재귀적 질의는 도메인 네임에 해당하는 IP 주소를 통해 DNS가 다른 DNS에게 재귀적으로 IP 주소를 물어보는 것을 뜻합니다.
반복적 질의는 IP 주소를 찾기 위해 반복적으로 질의하는 것입니다.
로컬 DNS가 루트 DNS에게 IP 주소를 물어봤는데 없으면 TLD DNS에게 물어보고 또 없으면 Authoritative DNS에 반복적으로 물어보는 것을 예시로 들 수 있습니다.
DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나요?
DNS는 신뢰성보다 속도가 더 중요한 서비스이기 때문에 연결 설정에 드는 비용이 없는 UDP를 사용합니다.
DNS는 연결 상태를 유지할 필요가 없고, TCP보다 많은 클라이언트를 수용할 수 있는 UDP를 사용합니다.
DNS 분산 데이터베이스를 구현한 DNS 서버들은 호스트 이름을 IP 주소로 매핑하기 위한 자원 레코드를 저장한다.
(Name, Value, Type, TTL)
DNS는 타입이 NS와 A인 레코드를 쌍으로 가지고 있다.
질의를 했을 때 NS와 A 레코드를 받으면 질의를 계속하고, A 레코드 하나만 받으면 원하던 IP 주소를 얻은 것이므로 Local DNS에 저장한 후, 클라이언트에게 전달한다.
Root → TLD → Authotitative
| Name | Value | Type | TTL |
|---|---|---|---|
| .edu | dns.edu | NS | |
| dns.edu | 2.2.2.2 | A |
| Name | Value | Type | TTL |
|---|---|---|---|
| hanyang.edu | dns.hanyang.edu | NS | |
| dns.hanyang.edu | 3.3.3.3 | A |
| Name | Value | Type | TTL |
|---|---|---|---|
| www.hanyang.edu | 4.4.4.4 | A |
동적 DNS(DDNS)는 IP 주소가 변경될 때 DNS 레코드를 자동으로 업데이트할 수 있는 서비스이다.
도메인 이름은 사용 편의성과 더불어 인식이 용이하도록 네트워크 IP 주소를 사람이 판독 가능한 이름으로 변환한다.
이름을 IP 주소에 매핑하는 정보는 DNS 서버에 표 형식으로 기록된다.
하지만 네트워크 관리자는 IP 주소를 동적으로 할당하고 자주 변경한다.
DDNS 서비스는 IP 주소가 변경될 때마다 DNS 서버 레코드를 업데이트한다.
과거에는 IP 주소가 고정되어 거의 변경되지 않아서 도메인 관리가 훨씬 간단했다.
그러나 인터넷의 확장과 서버, 스마트 센서 및 최종 사용자 디바이스의 대폭적인 증가로 인해 IP 주소가 부족해졌다.
이로 인해 ISP가 사용자에게 IP를 동적으로 할당할 수 있는 DHCP(Dynamic Host Configuration Protocol)이 등장했다.
일반적으로 ISP는 공유할 수 있는 IP 주소 묶음을 유지 관리하며 사용자의 연결 시간 또는 최대 시간에 도달할 때까지 필요에 따라 사용자에게 할당하거나 임대한다.
IPv6의 도입으로 IP 주소 부족이 완화되었지만, 정적 IP를 제공하는 것보다 DHCP가 비용 효율적이기 때문에 ISP는 여전히 DHCP를 사용한다.
간단하게 말해,
IP 주소 수를 늘리기 위해 IPv6라는 새로운 시스템이 도입되었다.
하지만, 고정 IP 주소를 할당하는 것은 더 이상 비용 효율적이지 않았다.
대신 네트워크 관리자는 Dynamic Host Configuration Protocol(DHCP)를 사용하여 IP 주소를 동적으로 할당한다.
조직은 일반적으로 DDNS 공급자가 제공하는 동적 DNS 서비스를 구독한다.
공급자는 관련 도메인 이름에 대한 DNS 레코드를 처리하는 DNS 서버를 유지 관리한다.
DDNS 클라이언트는 지속적으로 IP 주소를 모니터링하고, 변경 사항을 감지한다.
동적 DNS 공급자에게 DNS 레코드 업데이트 알림을 전송하여 새 IP 주소를 알린다.
동적 DNS 공급자는 새 IP 주소를 가리키도록 레코드를 수정한다.
동적 DNS 클라이언트는 IP 주소를 계속 모니터링하여 추가 변경사항을 확인한다.
새로운 변경이 발생할 때마다 프로세스가 반복된다.
두 호스트가 네트워크를 통해 서로 정보를 주고받을 때, 송수신하는 대상이 자원이다.
이러한 자원을 식별할 수 있는 정보를 URI라고 부른다.
URI에서 위치를 이용해 자원을 식별할 수도 있으며, 이름을 이용해 자원을 식별할 수도 있다.
전자를 URL, 후자를 URN이라고 한다.
URL은 특정 시점에서 자원의 구체적인 위치를 나타내는데, 만약 자원의 위치가 변경되면 기존 URL은 더 이상 사용 불가능하다는 단점이 있습니다.
URN은 이러한 URL의 단점을 보완하기 위해 정의된 표준인데, URN은 자원에 대해 영속적이고 고유한 식별자를 뜻합니다.
URL의 구조는 다음과 같다.

자원에 접근하는 방법을 의미한다.
일반적으로 사용할 프로토콜이 명시된다.
HTTP를 사용하여 접근할 때는 http://를, HTTPS로 접근할 때는 https://를 사용한다.
호스트를 식별할 수 있는 정보이다.
IP 주소 혹은 도메인 네임이 명시된다.
자원이 위치한 경로가 명시된다.
path만으로 식별할 수 없는 자원을 키=값 형태의 쿼리 파라미터를 추가하여 자원을 요청한다.
자원의 한 조각을 가리키기 위한 정보이다.
흔히 HTML 파일의 특정 부분을 가리키기 위해 사용된다.
NEXT. 애플리케이션 계층 HTTP와 애플리케이션 서비스
도서
혼자 공부하는 네트워크