구성
- DNS
- IP 주소를 얻는 과정
- 로드 밸런싱
- TLD
- authoritative DNS server
- DNS의 IP 주소
- IP 주소의 신선함
- RR
- DNS protocol의 message
- 요약
이 정리는 23-2에 수강한 컴퓨터 네트워크 강의를 기반으로 하였습니다.
DNS(Domain Name System)
모든 패킷의 교환은 IP 주소를 기반으로 한다. 특정 웹 페이지에 접근하는 것도 그 서버의 IP 주소를 알아야한다. 하지만 우리가 평소에 네이버를 들어가는 방식은 브라우저의 URL 입력창에 naver.com만 써서 접근한다. 우리는 IP 주소를 알고 있지 않은데, 어떻게 네이버에 접근할 수 있는걸까?
naver.com같은건 IP 주소의 서브 네임이라고 생각할 수 있다. 서브네임은 용어로 도메인 네임이라고 하고, 이런 도메인 네임을 갖고 서버의 IP 주소를 알아와 주는 프로토콜을 DNS라고 한다.
왜 굳이 도메인 네임을 쓰냐면, 사람은 이름이 익숙하지 32비트의 주소를 외우는 것은 어렵기 때문이다.
따라서 DNS는 도메인 네임과 IP 주소의 매핑 테이블을 갖고 있어 변환이 가능하다. 도메인 네임 -> IP 주소 도 가능하고 IP 주소 -> 도메인 네임 도 가능하다.
distributed database
매핑 데이터가 하나의 DB에 있지 않고 분산되어 존재한다. 이는 계층식으로 구현되어 name server라는 것으로 존재한다. 이 네임 서버에 매핑 테이블이 분산되어 존재하는 것이다. 마치 부서를 나눠 회사가 돌아가는 것처럼 말이다.
현재 사용되는 주소 체계와 거의 비슷한 방식이라고 보면 된다.
왜 근데 centralized database를 쓰지 않는걸까? 이유는 싱글 로드(포인트) 페일로 이 서버 한대가 고장나면 전체 시스템이 망가지기 때문이다. 또 다른 이유는 전 세계 호스트가 다 이 루트 서버로 쿼리를 보내면 엄청난 트래픽이 오며 보틀 넥이 생길 수 있다. 그리고 만약 지구 다른 나라의 웹 페이지를 접근하려한다면 물리적 거리가 멀기 때문에 큰 딜레이가 생긴다. 그리고 유지보수와 확장성이 안좋다. 이러한 이유로 계층을 갖는 분산된 DB 구조로 DNS가 만들어진 것이다.
IP 주소를 얻는 과정
iterated query
더 이해를 돕기 위해 예로 multinet.inha.ac.kr을 들어보자. DNS는 이 주소를 오른쪽 끝에서부터 읽는다. 그럼 제일 먼저 마주치는건 kr이다. 그러면 kr 네임 서버로 가서 ac를 찾는다. 찾는다는 것은 kr 네임 서버의 매핑테이블에 ac 키가 존재하고 그 값이 ac 네임 서버의 IP 주소인 것이다. 그렇게 ac 네임 서버에 접근하여 다음인 inha를 찾는다. 그렇게 inha 네임 서버에 가서 multinet을 찾아 최종적으로 multinet.inha.ac.kr의 IP 주소를 얻어 요청한 호스트에게 제공하여 호스트가 이 사이트로 접속할 수 있게 된다.
그런데 한 가지 그냥 넘어간 것이 있다. 제일 처음에 만난 kr 네임 서버의 주소는 어떻게 알 수 있을까? 이건 위쪽 네임서버 계층도를 보면 제일 루트에 존재하는 루트 네임 서버에서 받아온다. 그러면 루트 네임 서버의 IP 주소는 어떻게 아느냐? 루트 네임 서버는 전 세계에 13개밖에 없기 때문에 이미 웹 브라우저에 적혀있다. 그래서 접근이 가능한 것이다. 그리고 이 루트 네임 서버는 permenent IP 주소를 사용하므로 변하지도 않아서 저장해둔 것이다.
그리고 일단 한번 접근한 IP 주소를 DNS는 DB에 저장해두고, 다음에 접근할 때 번거롭게 다시 물어보지 않는다.
이런식으로 얻어오는 과정을 iterated query라고 한다. 여러 번 왔다 갔다 하는 모습이다.
recursive query
다른 방식으론 recursive query가 있다. 이름 그대로 재귀적으로 물어본다는 뜻이다. 아랫사람이 책임지고 알아오고, 그 사람보다 더 아랫사람이 책임지고 알아오는 모양이다. 최종 답을 알게된 서버는 왔던 재귀를 타고 올라가 DNS 서버에게 IP 주소를 제공한다.
현재 방식
iterative + recursive 의 구조를 갖는다. 호스트에서 로컬 DNS 서버까지는 recursive이고 로컬 DNS와 다른 네임 서버는 iterative이다.
로드 밸런싱
네이버를 이용하는 사람은 대한민국 인구의 절반이 넘을 것이다. 그럼 이 많은 트래픽이 웹 서버 한 대로 감당이 가능할까? 절대 불가능하다. 그래서 네이버같은 대기업은 수많은 웹서버를 두고 있다.
그런데 웹 서버가 여러 대라는 것은 각 서버의 IP 주소또한 여러 개 존재한다는 뜻이다. 그러면 이 여러 개 중 하나의 IP 주소를 리턴해 주는데 이걸 하나의 서버로 몰리지 않도록 잘 리턴해주는걸 로드 밸런싱이라고 한다. 이 기능이 DNS에 존재한다.
TLD
루트 네임 서버의 자식 네임 서버들을 말한다(1차 링크된).
도메인 이름의 가장 마지막 부분을 차지한다.
ex) .com, .org, .net, .edu...authoritative DNS server
실제 개인 도메인과 IP 주소의 관계가 기록/변경 되는 서버이다. 공식 위키 백과, 홈페이지 같은 느낌이다.
인하대 DNS 서버가 multinet.inha.ac.kr의 IP주소를 가져와 DB에 저장해뒀지만 이는 카피일 뿐이기 때문에 authoritative가 아니다. 이 상황에서 authoritative DNS server는 multinet.inha.ac.kr이다.
DNS의 IP 주소
그런데 naver.com의 IP 주소를 물어보려면 로컬 DNS 에게 물어봐야 하는건데, 그럼 로컬 DNS의 IP 주소는 어떻게 알 수 있는걸까?
집에 만약 kt 인터넷을 설치했다면 kt가 운영하는 로컬 DNS 서버의 IP 주소를 우리가 알고 있을까? 아니다. 인터넷 설치 기사님은 설치만 해주시고 간다.
첫번째 방법은 내가 만약 교수님이고 연구실에 새로운 컴퓨터를 들여놔 permenent IP 주소를 사용하려고 한다고 가정해보자. 그러면 정보통신처에 전화해서 새로운 컴퓨터를 샀으니 IP 주소를 달라라고 하면 준다. 그리고 이때 동시에 로컬 DNS 서버 주소도 함께 준다. 그러면 이 IP 주소와 DNS IP 주소를 설정 창에 입력하여 로컬 DNS에 접근할 수 있는 것이다.
그런데 우리같은 학생들은 그런 과정을 전혀 따라가지 않는다. 따라서 두번째 방법을 생각해볼 수 있다. 만약 학교가 kt인터넷을 사용한다면, kt에게 나 IP 주소가 없으니 주소좀 주쇼 하고 메세지를 보낸다. 그러면 kt에서 나에게 사용 중이 아닌 IP 주소를 dynamic host configuration protocol에 의해서 건네준다. 이때 받는 응답 메세지에 내 노트북에 부여되는 새로운 IP 주소 뿐만 아니라 로컬 DNS 서버의 IP 주소도 들어있다.
IP 주소의 신선함
루트 DNS 와 가까울 수록 네임 서버의 IP 주소는 자주 바뀌지 않는다. 그런데 종단 쪽으로 갈 수록 금방 바뀔 수 있다. 이사를 갈 수도 있고 여러 이유가 존재한다.
그러면 얘의 IP 주소가 신선한지 아닌지(바뀌었는지 아닌지)는 어떻게 알 수 있을까? 프록시 서버에서 배운 유효기간 방식을 적용할 수 있을 것 같다.
알게된 IP 주소는 라벨을 붙여 DNS에 저장되는데, 이 라벨을 Resource recode(RR)이라고 부른다. DNS는 distributed database이고 RR이라는 정보를 저장하는 database라고 생각하면 된다. 이 RR에는 이 IP 주소에 관한 여러 정보를 저장하고 전달하는데 사용된다.
RR안에는 유효기간을 의미하는 TTL(Time to Leave)란 필드가 있다. 이 TTL은 authoritative server가 설정해주는 것이다. 이 TTL이 끝나면 authoritative server에게 다시 IP 주소를 물어봐 매핑 테이블을 신선하게 유지한다.
그런데 만약 TTL을 지키지 않고 그 이전에 IP 주소가 바뀌는 경우가 있을 수도 있다. 그러면 접근이 안됨을 인식하고 원래 저장해두었던 IP 주소를 버린다. 그리고 원래의 authoritative server에 접근해 바뀐 IP 주소를 받아와 저장한다.
결국 TTL 하나만으로는 효율성을 위함이지 신선함을 유지할 수 없고 다시 물어보는 과정이 있어야 완전해지는 것이다.
RR(resource recode)
RR의 포맷은 아래 이미지 형식을 따른다.
name은 도메인 네임이고, value는 IP 주소이다. 그리고 TTL은 앞에서 배웠던 유효기간 이라는 것을 자연스럽게 알 수 있다.
(출처: https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-DNS-%EB%A0%88%EC%BD%94%EB%93%9C-%EC%A2%85%EB%A5%98-%E2%98%85-%EC%95%8C%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC)
그런데 type이라는 필드가 존재한다. 이것은 무엇일까? 이건 이전에 배웠던 message semantics 와 거의 유사하다. 필드 안의 내용을 어떻게 해석할지에 관한 프리셋이다.
타입은 일단 4가지 타입들에 대해서만 알아보자.
- A
- NS
- MX
- CNAME
하나씩 알아보자.
A
- name: hostname
- value: IP 주소
name필드에 적힌 값을 hostname으로 인식하고, value에 적힌 값을 IP 주소로 인식한다는 의미다.
A는 호스트의 IPv4 주소를 저장하는데 사용되는 타입이다.
여담으로 AAAA라는 타입도 있는데, 이건 IPv6의 호스트 주소를 저장하는데 사용되는 타입니다.
NS
- name: name server 이름(ex inha.ac.kr)
- value: authoritative name server
NS는 name server를 줄인 단어이다. 이 IP 주소는 name server라는 것을 알려주기 위한 타입이며, 도메인에 대하여 누가 책임이 있는지(authoritative name server)를 알 수 있다. 쉽게 말하면 해당 도메인의 IP 주소를 알기 위해 위해 어떤 name server로 접근해야 하는지 알려주는 것이다.
예를 들어 인하대에는 inha.ac.kr이라는 홈페이지 주소가 있다고 하자. 그리고 이 주소를 관리하는 서버는 인하대학교 DNS일 것이다. 그러면 inha.ac.kr의 주소가 inhauniv.ac.kr로 바뀌게 되면 인하대학교 DNS의 DB에 원래 있던 주소를 지우고 inhauniv.ac.kr를 새로 추가하게 된다. 이를 NS type으로 나타내면 아래처럼 되는 것이다.
type NS
name inha.ac.kr
value ns1.inha.ac.kr
ttl 1 year
ns1은 인하대학교 DNS가 1개가 아니고 여러 대일 수 있기 때문에 숫자로 구분지은 것그런데 위 예시의 ns1.inha.ac.kr이라는 네임 서버에 접근하려면 IP 주소를 알아야할텐데 NS 타입에는 IP 주소를 적을 수 있는 곳이 없다. 따라서 이 NS는 혼자 사용되지 않고, A타입과 함께 쌍으로 사용되어 실제 authoritative name server 의 IP 주소를 적어주는 것이다.
type NS
name inha.ac.kr
value ns1.inha.ac.kr
ttl 1 year
type A
name ns1.inha.ac.kr
value 165.36.nn.n
ttl n days이렇게 RR이 쌍으로 존재하여 인하대 네임 서버의 IP 주소를 획득할 수 있게 된다.
MX
인하대에는 메인 서버 말고도 메일을 위한 메일 서버도 존재한다. 메일 서버임을 알려주기 위해 NS처럼 A와 쌍을 이룬 형태로 사용한다.
type MX
name inha.ac.kr (@inha.ac.kr라는 메일을 모든 학생이 부여받음)
value mail.ns1.inha.ac.kr
ttl 1 year
type A
name mail.ns1.inha.ac.kr
value 165.36.nn.n
ttl n daysCNAME
CNAME은 canonical name을 줄인 이름이다. 별칭 만들기라고 생각하면 된다.
실제 도메인 네임은 A이지만 B로도 접근할 수 있게 하는 것이다.
실제로 크롬 URL창에 naver.com을 치면 네이버 메인 페이지가 잘뜨는걸 알 것이다. 그런데 naver.net을 쳐도 똑같이 메인 페이지가 뜬다. 이를 위한 타입이 CNAME인 것이다. 같은 네이버로 가지만 별명을 여러개 만들어줘 다른 도메인 이름도 사용할 수 있도록 한다.
type CNAME
name naver.net(별칭)
value naver.com
ttl n days
type A
name naver.com
value 123.456.nn.n
ttl n days이렇게 헷갈리거나 여러 개의 별칭을 만들면 오타나 비슷한 도메인을 쓰는 경우를 다 CNAME으로 적어두기도 한다.
DNS protocol의 message
DNS protocol의 메세지는 query와 reply 이렇게 두 가지의 타입으로 나눌 수 있다.
그리고 두 메세지는 같은 메세지 포맷을 가지며 아래 이미지와 같다.
- identification: 고유 번호이며 같은 쿼리여도 다른 값을 갖는다.
- query: 이 메세지가 query인지 reply인지 등을 알려주는 필드이다.
- #questions: 여러 개를 한 쿼리에 담아서 물어볼 수도 있어서 이를 알려주기 위한 필드이다.
요약
- DNS: 해결사, IP 주소 얻어와주는 고마운 친구
- IP 주소를 얻는 과정: iterative, recursive
- 로드 밸런싱: 트래픽 안몰리게 이어주기
- TLD: 루트 직계 자식
- authoritative DNS server: 도메인을 책임지고 관리하는 서버
- DNS의 IP 주소: IP 받아올 때 DNS IP 주소도 준다.
- IP 주소의 신선함: 유효기간과 권한 DNS 서버를 함께 사용해 판단한다.
- RR: DNS DB에 저장되는 프로퍼티 타입이다.
- DNS protocol의 message: query, reply가 있다.
참고
