Domain Name Server

호스트 네임을 관리하는 체계 : DNS

네트워크를 통해 주고받는 정보의 명찰 : 자원

 

IP주소, 도메인 네임을 통해서 -> 메시지를 주고받는 송수신지 파악

자원을 통해서 -> 송수신하고자 하는 정보 파악

자원을 식별할 수 있는 방법은 여러가지가 있지만 가장 대표적인 것이 URL

 

도메인 네임과 네임 서버

• IP 주소만으로 송수신지 특정하는 것은 번거로움
  • (≒ 모든 친구의 전화번호 기억하기 어려움)
  • 통신하고자 하는 모든 호스트의 IP 주소 기억하기 어려움
  • IP 주소는 언제든 바뀔 수도 있음
• IP 주소만으로 송수신지 특정하는 것은 번거로움
  • 그래서 상대 호스트 특정를 위해 도메인 네임 사용
  • 도메인 네임 (≒ 전화번호에 대응하는 사용자 이름)
  • 예) www.example.com, kernel.org, git.kernel.org
  • 네임 서버(DNS 서버)에서 관리 (≒ 공용 전화번호부)
  • IP 주소 변경되어도 도메인 네임 다시 대응하면 그만

개인 전화번호부와도 같은 hosts 파일

• 도메인 네임과 IP 주소의 대응 관계를 담은 파일
• hosts 파일 위치
  • 맥OS나 리눅스 - /etc/hosts
  • 윈도우 - %SystemRoot%\System32\drivers\etc\hosts

네임 서버의 관리

• 도메인 네임의 구조로 알아보는 네임 서버 관리 방법
• 점(.)을 기준으로 계층적으로 분류
  • 루트 도메인(root domain)
  • 최상위 도메인(TLD; Top-Level Domain)
  • 2단계 도메인, 3단계 도메인, 4단계 도메인 ...

 

 

원래는 도메인 네임 끝에는 "."(루트 도메인) 이 생략되어 있음

 

• 전체 주소 도메인 네임(FQDN; Fully-Qualified Domain Name)
  • 전체 도메인 계층을 모두 포함하는 도메인 네임
  • FQDN까지 알면 비로소 하나의 호스트를 식별할 수 있게 됨

서브도메인

• 다른 도메인이 포함된 도메인
• https://www.google.com/search?q=google.com의 서브 도메인 ->
  • mail.https://www.google.com/search?q=google.com,
  • www.google.com,
  • scholar.https://www.google.com/search?q=google.com,
  • drive.https://www.google.com/search?q=google.com
• 루트 도메인 서버가 있고
• 최상위 도메인 서버가 있고
• 2단계 도메인 서버가 있고 ...

계층적 도메인 네임

• 이를 관리하기 위한 네임 서버 또한 계층적으로 관리
• 네임 서버는 전세계 여러 군데 분산되어 위치(부하 분산과 가용성 향상을 위해서)
• 계층적이고 분산된 도메인 네임에 대한 관리 체계 : DNS
• 도메인 네임에 대응하는 IP주소를 알아내는 과정
  • -> 도메인 네임을 리졸브한다
• 루트 도메인, 최상위도메인, 2단계, 3단계 순으로 리졸빙 함

주요 네임 서버의 유형: 로컬 네임 서버, 루트 네임 서버, TLD(최상위 도메인) 네임 서버, 책임 네임 서버

 

 

로컬 네임 서버

• 클라이언트와 가장 맞닿아 있는 서버
• 클라이언트가 도메인 네임을 통해 IP주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버
• 로컬 네임 서버의 주소는 일반적으로 ISP에서 할당
• ISP에서 할당해주는 거 말고 공개 DNS 서버(public DNS Server)를 이용할 수도 있음
  • ex) 구글의 8.8.8.8, 8.8.4.4, 클라우드플레어의 1.1.1.1

루트 네임 서버

• 루트 도메인을 관장하는 네임 서버
  • -> 로컬 네임 서버가 대응하는 IP주소를 모를 경우
  • -> TLD 네임 서버의 IP주소를 반환할 수 있음

TLD 네임 서버

• TLD를 관리하는 네임서버
• DNS 질의에 대해 TLD의 하위 도메인을 관리하는 네임 서버 주소 반환
  • -> 하위 도메인 네임을 관리하는 네임 서버는 그보다 하위 도메인 네임을 관리하는 네임 서버 주소를 반환

 

 

책임 네임 서버

• 특정 도메인 영역을 관리하는 네임 서버
• 다른 네임서버에게 떠넘기지 않고 바로 답할 수 있는 네임서버
• 즉, 책임 네임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임 서버
• 일반적으로 로컬 네임 서버는 책임 네임 서버로부터 원하는 OIP주소를 얻어냄

네임 서버의 계층적 구조

 

네임 서버의 계층적 구조를 토대로 IP 주소를 알아내는 과정

- 재귀적 질의

- 반복적 질의

 

재귀적 질의

• 클라이언트 -> 로컬 네임 서버 -> 루트 네임 서버 -> TLD 네임 서버 -> 책임 네임 서버에게 질의
• 최종 응답 결과를 역순으로 전달

반복적 질의

• 네임 서버에 일일이 질의 -응답 반복
• 최종 응답 결과를 클라이언트에게 전달

DNS 캐시

• 조금 문제가 있다
• 앞선 예시는 8단계를 거치게 됨
  • -> 시간이 오래 걸리고 네트워크 상의 메시지 수가 지나치게 늘어날 수 있음
  • -> 루트 네임 서버에 과부화 우려
• DNS 캐시
  • 네임 서버들이 기존에 응답 받은 결과를 임시로 저장했다가 추후 같은 질의에 이를 이용
  • DNS 캐시를 저장하는 용도로만 사용되는 서버도 있음
  • DNS 캐시를 활용하면 더 짧은 시간 안에 원하는 IP주소를 얻어낼 수 있음
  • DNS 캐시는 영원히 남아있는 것은 아님
  • -> 임시 저장된 값은 TTL(Time To Live)될 수 있는 시간)값과 함께 저장

자원을 식별하는 URI

• 자원(resource) - 네트워크상의 메시지를 통해 주고받는 대상
  • 두 호스트가 네트워크를 통해 서로 정보를 주고받을 때, 송수신하는 대상
  • HTML 파일, 이미지나 동영상 파일, 텍스트 파일 등
• 자원은 'HTTP 요청 메시지의 대상'이라 보기도

자원을 식별하는 URI

• 자원을 식별할 수 있는 정보, URI(Uniform Resource Identifier)
  • URL(Uniform Resource Locator)
    • 위치를 이용해 자원을 식별
  • URN(Uniform Resource Name)
    • 이름을 이용해 자원을 식별

 

URL

• 오늘날 인터넷 환경에서 자원 식별에 더 많이 사용되는 식별자
• URL의 구조 (RFC 3936)
  1. scheme
  2. authority
  3. path
  4. query
  5. fragment

 

1. scheme

• URL의 첫부분은 scheme: '자원에 접근하는 방법'을 의미
• 일반적으로 사용하는 프로토콜이 명시
  • -> HTTP를 사용하여 자원에 접근할 때는 http://를 사용
  • -> HTTPS를 사용하여 자원에 접근할 때는 https://를 사용

2. authority

• authority에는 '호스트를 특정할 수 있는 정보', 이를테면 IP주소 혹은 도메인 네임이 명시
• 콜론(:) 뒤에 포트 번호를 덧붙일 수도 있음

3. path

•  path에는 자원이 위치한 경로가 명시
• 자원의 위치는 슬래시(/)를 기준으로 계층적으로 표현되고, 최상위 경로 또한 슬래시로 표현

4. query

HTTP는 요청-응답 기반의 프로토콜

• 클라이언트는 서버에게 URI(URL)가 포함된 HTTP 요청 메시지를 보내고,
• HTTP 서버는 이에 대해 HTTP 응답 메시지를 보냄

 

이런 요청은 scheme, authority, path만으로 어떻게 표현할 수 있을까?

 

• 이럴 때 사용 가능한 **쿼리 문자열(query string), 쿼리 파라미터(query parameter)**라고도 부름
• 물음표(?)로 시작되는 <키, 값> 형태의 데이터
• 앰퍼샌드(&)로 여러 쿼리 문자열을 덧붙일 수 있음
• 예: http://example.com/random/path?query=value&query2=value2

 

 

5. fragment

• fragment는 '자원의 한 조각을 가리키기 위한 정보'
• HTML 파일과 같은 자원에서 특정 부분을 가리키기 위해 사용
• 예시 1: https://datatracker.ietf.org/doc/html/rfc3986
• 예시 2: https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.2

 

자원의 위치가 변경되면 기존 URL로는 자원을 식별할 수 없다는 단점

 

URN

• URL의 단점
  • 위치를 기반으로 자원을 식별하는데 자원의 위치는 언제든 변할 수 있음
  • 즉, 자원의 위치가 변경되면 기존 URL로는 자원을 식별할 수 없음
• URN의 장점
  • 자원에 고유한 이름을 붙이는 이름 기반 식별자이기에 자원의 위치와 무관하게 자원을 식별
  • URN은 아직 URL만큼 널리 채택된 방식은 아님

네임 서버는 무엇을 저장할까

• DNS 자원 레코드(DNS resource record)
  • 이름(호스트 이름, Record Name)
  • 값(Value)
  • TTL
  • 레코드 유형(타입, Record type)
  • 등

네임 서버는 무엇을 저장할까

• 1.2.3.4로 접속 가능한 웹 서비스 배포, example.com 도메인 네임 구입
• 이를 1.2.3.4에 대응하고자 한다면?
  • -> example.com이 1.2.3.4에 대응됨을 네임 서버에 알려야 함

 

DNS 레코드 예제

• 네임 서버에 example.com을 질의하면 1.2.3.4 응답
• DNS 캐시는 300초간 저장

타입	이름	값	TTL
A	example.com.	1.2.3.4	300

레코드 유형(타입, Record type)

• 레코드 유형이 달라지면 레코드 이름과 값의 의미가 달라짐
• 대표적인 레코드 유형

레코드 유형	설명
A	특정 호스트에 대한 도메인 네임과 IPv4 주소와의 대응 관계
AAAA	특정 호스트에 대한 도메인 네임과 IPv6 주소와의 대응 관계
CNAME	호스트 네임에 대한 별칭 지정
NS	특정 호스트의 IP 주소를 찾을 수 있는 네임 서버
MX	해당 도메인과 연동되어 있는 메일 서버

타입	이름	값	TTL
A	example.com.	1.2.3.4	300
CNAME	www.example.com.	example.com.	300