박찬호.md

사용자가 URL을 클릭함으로써 HTTP를 쓸 때마다 URL에 들어 있는 도메인 이름을 IP 주소로 바꾸어 주는 DNS 프로토콜이 사실상 먼저 쓰이게 된다.

도메인 이름을 쓰게 된 계기가 IP 주소를 외우기 힘들기 때문이다. 인터넷이 커지면서 파일 하나에 들어가던 것들이 점점 커지게 되었고, 결국 자동화된 번역 시스템으로서 DNS가 태어나게 된다.

DNS가 IP를 대체하는 것이 아니다. 인터넷 안의 데이터의 배달은 당연히 "IP"에 의해서 이루어진다.

따라서 패킷이 인터넷으로 들어가기 전에, 도메인 이름은 IP 주소로 번역이 끝나야 한다.

스마트폰에서 사람 이름을 터치하면 전화가 걸리지만, 전화 네트워크가 사람 이름을 인식하는 것이 아니고 결국은 전화번호로 전화가 걸리는 것과 같다.

게다가 도메인 이름 번역을 위한 모든 통신은 IP 데이터그램을 사용해서 이루어진다.

DNS 프로토콜은 "응용 계층" 프로토콜이다.

따라서 응용 소프트웨어와 함께 구현된다. 사용자가 도메인 이름을 쓰면, 그것을 IP 주소로 바꾸기 위해

"리졸버(resolver)"를 기능을 함수 호출 형태로 응용에 넣어준다.

DNS는 아래 세가지 요소로 구성되어있다.

1. 도메인 네임 스페이스(Domain Name Space)
2. 네임 서버(Name Server) = 권한 있는 DNS 서버
3. 리졸버(Resolver) = 권한 없는 DNS 서버

1. DNS Name Space

DNS에서 Domain은 "명명 (naming) 도메인"이다. 마치 사람들 이름을 붙이는 것과 같다.

김씨 집안에 아이가 태어나면 이름이 "김"으로 시작한다.

고려대학교에 있는 컴퓨터가 도메인 이름을 얻게 되면 마치 서양식 성씨 처럼 last name은 korea,ac.kr

First name은 widen이라고 붙여서  => widen.korea.ac.kr 이 된다.

1.1 도메인 이름 공간의 구조

Domain Name Space

도메인 이름은 사람 이름처럼 2층으로만 이루어지지 않는다. 트리 구조를 그리면 위와 같다.

트리 구조는 도메인 이름 공간 ( Domain Name Space)라는 추상적인 공간이다.

최상위에 root 노드가 있고, 그 바로 아래에 "최고 수준 도메인(top-level domain; TLD)"가 있다.

트리 깊이는 한계가 없다.

• 레이블(label) : 각 노드의 단어

  루트 노드는 레이블이 "투명"이다. 즉, 기술적으로 레이블이 있지만, 길이가 0이다.

  대소문자 구분이 없다. 모두 소문자로 번환한다.

• 도메인 이름 : 리프 노드에서 루트 노드로 올라가면서 읽으면 된다. 맨 끝에 " . " 을 붙여야 한다.

  맨 끝에 붙은 . 은 루트 노드의 "투명"레이블이다.

• FQDN (Fully Qualified Domain Name; 완전히 갖춰진 도메인 이름) : 루트 노드의 레이블까지 포함

• 도메인 : 도메인 이름 공간의 한 서브트리이다. 즉. ibm.com은 com의 서브 도메인이다.

  서브 도메인은 필요한 대로 얼마든지 만들 수 있다.

• 하위 조직의 네임 스페이스를 할당하고 관리하는 방식은 각 하위 기관의 관리 책임자에게 위임된다.

  • 예를 들어 naver.com 도메인은 com 도메인을 관리하는 네임 서버에 등록되어있고 www.naver.com 은 naver.com을 관리하는 네임 서버에 등록되어있다.

• 리졸버 서버가 최상위 네임서버부터 차례대로 질의를 하며 원하는 도메인의 IP주소를 찾아간다.

1**.2 FQDN - 완전한 도메인 이름**

FQDN은 full name이다. DNS는 FQDN을 요구한다.

• 도메인 이름에서의 점은 무수히 많을 수 있다.(Domain Name Space의 깊이가 무제한이므로)
• IP 주소와 도메인 이름은 1:1 대응이 아니다!!
  • 컴퓨터들이 인터페이스를 여러 개 가지면서 1대1 대응 관계는 사라졌다.
• 즉, 도메인 이름은 해당 컴퓨터의 수많은 인터페이스 중 하나와 매핑이 이루어진다.

결론 : 도메인 이름과 IP주소는 융통성 있게 매핑할 수 있다. (Round Robin DNS)

1.3 최상위 도메인(TLD)

2. 데이터베이스로서의 DNS

DNS는 전 세계적인 분산 데이터베이스다. 데이터베이스의 물리적 실체가 여러 조각으로 분산된 것이다.

이러한 물리적 실체는 "각 도메인의 매핑 자료 (record) 집합"이다.

ex) 고려대학교의 접미사 : korea.ac.kr // 해당 접미사로 된 모든 도메인 이름에 대한 매핑 자료를 고려대학교가 가지고 관리하고 있다.

도메인 이름을 등록한다는 것은 "매핑 자료에다가 새로운 도메인 이름과 해당 매핑을 추가"하는 것이다.

따라서 도메인 자료는 소유자가 관리한다.

• 존 파일(zone file) : 도메인 이름에 대한 매핑 자료

  DNS 시스템은 이러한 "존 파일"들의 전체 집합이다.

• DNS = 존 파일들의 연합체

• RR (resource record) : 자원 레코드, 도메인 이름에 결부된 다양한 데이터들

=> 도메인 이름과 그에 대응하는 여러 데이터들이 모여서 하나의 "레코드"를 구성하고, 이러한 레코드들이 모여 "존 파일"이 되는 것이다.

• authoritative 서버 : 각 존 파일을 관리할 서버

3. DNS 데이터의 종류 - RR type

• A : Address로 IPv4 주소를 담는다.

• AAAA : IPv6 주소

• NS : Name Server, 어떤 도메인을 책임지는 DNS 서버, 즉 authoritative 서버이다.

  도메인 이름을 등록하고 수정하는 등 존 파일의 원본을 관리한다.

• MX : Mail Exchange, 해당 도메인을 책임지는 메일 서버이다.

  메일 쓸 때 @ 뒤에 쓰는 주소는 도메인이다. ([email protected])

  따라서 이 도메인의 우체국인 메일 서버의 도메인 이름을 찾아야 하며, MX에 들어있다.

• CNAME : 본명이다. 도메인 이름은 "별명"에 해당하고 원하는 만큼 길어질 수 있다.

  이 경우 좀 짧은 도메인 이름으로 대신 쓸 수 있는데, 이때 DNS에 의해 본명으로 번역을 해야 관련 RR들을 얻을 수 있다.

  "본명 으로의 매핑 관계"의 RR이 CNAME이다. ->Domain Name Space의 말단 노드만 가짐

• PTR : pointer이다. IP 주소에서 도메인 이름으로의 매핑 데이터를 가진다.

• SOA : Start-Of-Authority. "도메인 관리에 사용되는 모든 파라미터"를 가진다.

• SRV : Server. DNS가 NS나 MX 서버 등 다양한 서버들을 접속할 떄 DNS의 도움을 받기 위해 정의

• TXT : 다양한 정보를 텍스트 메시지 형태로 가짐

더 많지만 생략

💡 nslookup 프로그램 사용하여 도메인 이름을 가지고 각 타입의 RR 데이터를 출력할 수 있다.

3.1 A 타입

set querytype=A 를 명령하면, A타입의 RR을 찾아와서 출력해준다.

nslookup을 통한 질의에 응답하는 디폴트 DNS 서버의 도메인 이름,IP주소가 나온다.

권한 없는 응답은 authoritative 서버에서 온 응답이 아니라는 뜻이다.

즉, cnn.com의 authoritative 서버가 아닌 다른 서버에서 온 답이다.

즉, DNS 캐쉬에서 온 답이다.

그리고 답이 4개나 왔다. 즉 도메인 이름에 4개의 IPv4 주소가 매핑된 것이다. cnn.com이라는 도메인 이름을 공유하는 서버가 최소 4개가 있다.

3.2 AAAA 타입

캐슁이 잘 되어 있기 때문에 authoritative 서버로 부터 직접 답을 얻는 경우가 희귀하다. 다른 서버로부터 왔기 때문에 권한없는 응답이다.

여기서도 IPv6 주소가 4개나 나왔다.

3.3 NS 타입

네임 서버들이 나온다. 이 중에서 하나만 "주 서버"일 것이다.

->SOA타입의 질의를 하면 알 수 있다.

이 네임 서버들이 다 다른 위치에 있는 걸 확인할 수 있다.

.net / .org/  .com/  .co.uk

분산시켜서 한 쪽이 다운되더라도 다른 네임 서버가 존 파일들을 가지고 서비스하기 위함이다.

NS 질의에 대해서 "네임 서버의 도메인 이름"에다가 추가로 "IPv4"주소 까지 제공하고 있다.

어짜피 도메인 이름만으로는 통신이 안되기 때문에 같이 준 것이다.

이번에는 쓰지 않더라도 "리졸버가 캐쉬에 저장"했다가 나중에 cnn.com 도메인에 대한 질문을 받으면

DNS 검색없이 네임 서버를 이 IP 주소로 직접 접속한다.

3. Name Server

어떤 도메인을 책임지는 DNS 서버, 즉 authoritative 서버이다.

• 도메인 이름을 등록하고 수정하는 등 존 파일의 원본을 관리한다.
  • DB 저장 & 관리, 질의에 대한 응답 처리
• IP주소와 도메인 주소를 연결해 주는 역할을 한다.

4. Resolver server

DNS 서버에게 질의를 던져서 도메인 주소에 맵핑된 IP 주소를 얻으려는 DNS 클라이언트를 대신해서 여러 네임 서버들에게 질의와 응답을 주고 받으며 IP 주소를 클라이언트에게 제공한다.

• 중간에서 대신 일해주는 역할임
• 하나의 네임 서버에게 DNS 질의를 하고 해당 서버에 정보가 없으면 다른 네임 서버에게 요청을 보내서 정보를 결국 받아낸다.

5. DNS 동작 과정 요약

• DNS 클라이언트와 DNS 서버는 DNS 쿼리를 교환한다.
• DNS(Domain Name System) 쿼리는 사용자가 웹사이트 이름(예: www.example.com)를 입력할 때, 해당 이름이 실제로 어떤 IP 주소를 가리키는지 찾아내는 과정이다.
• 이를 위해 DNS 서버가 쿼리를 처리하는 방식에는 크게 두 가지, 즉 재귀적(Recursive) 방식과 반복적(Iterative) 방식이 있다.

재귀적(Recursive) DNS 쿼리

• 클라이언트(또는 요청하는 DNS 서버)가 DNS 서버에게 도메인 이름에 대한 IP 주소를 알려달라고 요청할 때 사용된다.
• 이 요청을 받은 DNS 서버는 요청 받은 정보를 가지고 있지 않을 경우, 자신이 직접 다른 DNS 서버들에게 찾아달라고 요청한다. 이렇게 요청을 받은 DNS 서버 역시 해당 정보를 가지고 있지 않다면, 다시 다른 DNS 서버에게 정보를 요청하는 과정을 반복한다. 이후 원하는 정보를 찾게 되면, 원래의 요청자에게 결과를 반환한다.

반복적(Iterative) DNS 쿼리

• 반복적 쿼리에서 클라이언트(또는 요청하는 DNS 서버)는 DNS 서버에게 도메인 이름에 대한 IP 주소를 알려달라고 요청한다.
• 이 요청을 받은 DNS 서버는 자신이 가지고 있는 정보를 제공하거나, 해당 정보를 가지고 있지 않다면, 다른 DNS 서버를 가리키는 참조(또는 포인터) 정보를 제공한다.
• 이후 클라이언트는 이 참조를 통해 다른 DNS 서버에게 다시 직접 쿼리를 수행한다. 이런 과정을 반복하여 원하는 정보를 찾게 된다.

💡 이 두 방식의 주요 차이점은, 재귀적 쿼리에서는 DNS 서버가 모든 작업을 수행하고 결과를 클라이언트에게 반환하는 반면, 반복적 쿼리에서는 클라이언트가 직접 다른 DNS 서버에게 쿼리를 수행하는 것이다.