티스토리 뷰
2.4 DNS - 인터넷 디렉터리 서비스
사람을 이름, 주민번호 등으로 식별하는 것과 마찬가지로
인터넷 호스트에 대한 하나의 식별자를 호스트 네임(hostname)이라고 한다.
예) www.facebook.com, www.google.com, gaia.cs.umass.edu
호스트 네임
- 호스트 위치에 대한 정보를 거의 제공하지 않는다.
- 가변 길이의 알파뉴메릭 문자로 구성되므로 라우터가 처리하는 데 어려움이 있다.
호스트는 흔히 말하는 IP 주소로도 식별된다.
IP 주소
- 4바이트로 구성되고 계층구조를 갖는다.
- 0~255의 십진수로 표현하는 각 바이트는 점으로 구분한다.
- IP주소는 계층구조여서 주소를 왼쪽에서 오른쪽으로 조사함으로써, 그 호스트가 인터넷의어디에 위치하는지에 대한 자세한 정보를 얻을 수 있다.
2.4.1 DNS가 제공하는 서비스
사람은 호스트 네임 식별자를 선호하지만,
라우터는 고정 길이의 계층구조를 가진 IP주소를 선호한다.
호스트 네임을 IP 주소로 변환해 주는 디렉터리 서비스가 필요
이것이 인터넷 DNS(domain name system)의 주요 임무이다.
DNS
- DNS 서버들의 계층구조로 구현된 분산 데이터베이스이고
- 호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜이다.
- DNS 서버는 주로 BIND 소프트웨어를 수행하는 유닉스 컴퓨터이다.
- DNS 프로토콜은 UDP상에서 수행되고 포트 번호 53을 이용한다.
DNS는 다른 애플리케이션 프로토콜들이
HTTP, SMTP, FTP 등 사용자가 제공한
호스트 네임을 IP 주소로 변환하기 위해 주로 이용한다.
어떤 사용자의 호스트에서 수행되는 브라우저(HTTP 클라이언트)가 URL www.someschool.edu/index.html 을 요청한 경우 다음과 같은 과정이 수행된다.
- 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행한다.
- 브라우저는 URL로부터 호스트 네임 www.someschool.edu를 추출하고 그 호스트 네임을 DNS 애플리케이션의 클라이언트 측에 넘긴다.
- DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보낸다.
- DNS 클라이언트는 결국 호스트 네임에 대한 IP 주소를 가진 응답을 받게 된다.
- 브라우저가 DNS로부터 IP 주소를 받으면, 브라우저는 그 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.
DNS 제공하는 중요한 서비스
- 호스트 엘리어싱(host aliasing)
- DNS는 호스트의 IP 주소뿐만 아니라 제시한 별칭 호스트 네임에 대한 정식 호스트 네임을 얻기 위해 이용될 수 있다.
- 메일 서버 엘리어싱(mail serve aliasing)
- DNS는 호스트의 IP 주소뿐만 아니라 제공된 별칭 호스트 네임에 대한 정식 호스트 네임을 얻기 위해 메일 애플리케이션에 의해 수행된다.
- 부하 분산(load distribution)
- DNS는 중복 웹 서버 같은 여러 중복 서버 사이에 부하를 분산하기 위해서도 사용되고 있다.
- 중복 웹 서버의 경우, 여러 IP 주소가 하나의 정식 호스트 네임과 연관되어 있다.
- DNS 데이터베이스는 이 IP 주소 집합을 갖고 있다.
- DNS 순환 방식은 전자메일에서도 사용되어 여러 메일 서버가 동일한 별칭을 가질 수 있다.
2.4.2 DNS 동작 원리 개요
모든 DNS 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내진다.
단일 DNS 서버에 있는 중앙 집중 데이터베이스는
서버의 고장, 트래픽 양, 먼 거리의 중앙 집중 데이터베이스, 유지관리
면에서의 문제점으로 확장성이 전혀 없어 DNS는 분산되도록 설계되었다.
1. 분산 계층 데이터베이스
대체로 계층으로 구서왼 세 유형의 DNS 서버가 있다.
- 루트(root) DNS 서버
- 최상위 레벨 도메인 네임(TLD, top-level domain) DNS 서버
- 책임(authoritative) DNS 서버
DNS 클라이언트가 호스트네임 www.amazon.com의 IP 주소를 결정하기 원한다고 가정하자.
- 클라이언트는 루트 서버 중 하나에 접속한다.
- 루트 서버는 최상위 레벨 도메인(예: com)을 갖는 TLD 서버 IP 주소를 보낸다.
- 클라이언트는 이 TLD 서버 중 하나에 접속하고, 서버는 도메인 amazon.com을 가진 채임 서버의 IP 주소를 보낸다.
- 클라이언트는 amazon.com의 책임 서버 중에서 하나로 접속한다.
- 서버는 www.amazon.com 의 IP 주소를 보낸다.
로컬 DNS 서버
서버들의 계층구조에 엄격하게 속하지는 않지만, DNS 구조의 중심에 있다.
대학이나 주거지역 ISP들은 로컬 DNS 서버를 갖는다.
- 호스트가 ISP에 연결될 때, 그 ISP는 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공한다.
재귀적 질의(recursive query)와 반복적 질의(iterative query)
- 위의 그림에서 cse.nyu.edu로부터 dns.nyu.edu로 보내는 질의는 자신을 대신하여 필요한 매핑을 얻도록 dns.nyu.edu에게 요구하므로 재귀적 질의이다.
- 다른 세 가지 질의는 모든 응답이 dns.nyu.edu에 직접 보내지므로 반복적 질의이다.
2. DNS 캐싱
DNS는 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱을 사용한다.
- 예) 위에 위에 그림에서 로컬 DNS 서버 dns.nyu.edu는 임의의 DNS 서버로부터 응답을 받을 때마다 응답에 포함된 정보를 저장할 수 있다.
- 만약 호스트 네임과 IP 주소 쌍이 DNS 서버에 저장되고 다른 호스트 네임으로 같은 질의가 DNS 서버로 도착하면 DNS 서버는 호스트 네임에 대한 책임이 없을 때조차 원하는 IP 주소를 제공할 수 있다.
- 호스트 DNS와 IP 주소 사이의 매핑과 호스트는 영구적인 것이 아니기 때문에 DNS 서버는 어떤 기간(흔히 2일로 설정) 이후에 저장된 정보를 제거한다.
2.4.3 DNS 레코드와 메시지
DNS 분산 데이터베이스를 구현한 DNS 서버들은 호스트 네임을 IP 주소로 매핑하기 위한 자원 레코드(resource record, RR)을 저장한다.
각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답한다.
자원 레코드
- 4개의 투플(tuple)로 구성
- (Name, Value, Type, TTL)
- TTL
- 자원 레코드의 생존기간이다.
- 자원이 캐시에서 제거되는 시간을 결정
- 자원 레코드의 생존기간이다.
- Type=A
- Name: 호스트 네임
- Value: 호스트 네임에 대한 IP 주소
- 표준 호스트 네임의 IP 주소 매핑을 제공한다.
- 예) (relay1.bar.foo.com, 145.37.93.126, A)
- Type=NS
- Name: 도메인
- Value: 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 아는 책임 DNS 서버의 호스트 네임
- 예) (foo.com, dns.foo.com, NS)
- Type=CNAME
- Name: 별칭 호스트 네임
- Value: 별칭 호스트 네임 Name에 대한 정식 호스트 네임
- 이 레코드는 질의 호스트에게 호스트 네임에 대한 정식 이름을 제공한다.
- 예) (foo.com, relay1.bar.foo.com, CNAME)
- Type=MX
- Name: 별칭 호스트 네임
- Value: 별칭 호스트 네임 Name을 갖는 메일 서버의 정식 이름
- 예) foo.com, mail.bar.foo.com, MX)
- MX 레코드는 메일 서버의 호스트 네임이 간단한 별칭을 갖는 것을 허용한다.
- 메일 서버의 정식 이름을 얻기위해서 DNS 클라이언트는 MX 레코드에 대한 질의를 한다.
- 다른 서버의 정식 이름을 얻기 위해서 DNS 클라이언트는 CNAME 레코드에 대한 질의를 한다.
예) 호스트 gaia.cs.umass.edu에 대한 책임서버가 아닌 TLD 서버를 가정하자.
- 그러면 이 서버는 호스트 gaia.cs.umass.edu를 포함하는 도메인에 대한 레코드(예: umass.edu, dns.umass.edu, NS)를 포함할 것이다.
- TLD 서버는 또한 Type A 레코드를 포함하는데, 이는 DNS 서버 dns.umass.edu를 IP 주소(예: dns.umass.edu, 128.119.40.111, A)로 매핑한다.
1. DNS 메시지
DNS 질의와 응답 메시지 모두는 아래 그림과 같은 포맷을 가지고 있다.
- 헤더 영역
- 12바이트
- 식별자
- 질의를 식별하는 16비트 숫자
- 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별하게 한다.
- 플래그
- 질의/응답 플래그
- 1비트
- 메시지가 질의(0)인지 응답(1)인지를 구별하게 한다.
- 책임 플래그
- 1비트
- DNS 서버가 질의 이름에 대하여 책임 서버일 때 응답 메시지에 설정된다.
- 재귀 요구 플래그
- 1비트
- DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 수행하기를 클라이언트(호스트 혹은 DNS 서버)가 원할 때 설정된다.
- 재귀-가능 필드
- 1비트
- DNS 서버가 재귀 질의를 지원하면 응답에 설정된다.
- 헤더에 4개의 "개수" 필드가 있다.
- 이들 필드는 헤더 다임에 오는 데이터 영역의 네 가지 타입의 발생 횟수를 나타낸다.
- 질의/응답 플래그
- 질문 영역
- 질의에 대한 이름, 타입 필드
- 답변 영역
- 질의에 대한 응답 내의 RR
- 원래 질의된 이름에 대한 자원 레코드를 포함한다.
- 응답으로 여러 개의 RR을 보낼 수 있다. 왜냐하면 호스트 네임은 여러 개의 IP 주소를 가질 수 있기 때문이다.
- 책임 영역
- 책임 서버에 대한 레코드
- 다른 책임 서버의 레코드를 포함한다.
- 추가 영역
- 추가 도움 정보
- 다른 도움이 되는 레코드를 포함한다.
어떻게 DNS 질의 메시지가 여러분이 작업하는 호스트로부터 DNS 서버로 곧장 보내질 수 있을까?
- 윈도우와 유닉스에서 nslookup 프로그램으로 할 수 있다.
- 예를 들어, 윈도우 호스트로부터 명령 창을 열고 "nslookup"을 입력하여 nslookup 프로그램을 실행한다.
- nslookup을 실행한 후에 여러분은 DNS 질의를 어떤 DNS 서버로 보낼 수 있다.
- DNS 서버로부터 응답 메시지를 받은 후에 nslookup은 응답에 있는 레코드를 화면에 사람이 읽을 수 있는 형태로 보여준다.
2. DNS 데이터베이스에 레코드 삽입
네트워크 유토피아라고 하는 새로운 벤처 기업을 설립했다고 가정하자.
- 당신이 처음으로 하고자 하는 것은 도메인 네임 networkutopia.com을 등록기관에 등록하는 것이다.
- 도메인 네임 networkutopia.com을 어떤 등록기관에 등록할 때
- 등록기관에 주책임 서버와 부책임 서버의 이름과 IP 주소를 등록기관에 제공해야 한다.
- 그 이름과 IP 주소가 dns1.networkutopia.com, dns2.networkutopia.com, 212.212.212.1 그리고 212.212.212.2라고 하자.
- 이 두 책임 DNS 서버 각각에 대해 등록기관은 Type NS와 Type A 레코드가 TLD com 서버에 등록되도록 확인한다.
- 특히 networkutopia.com에 대한 주 책임 서버의 경우, 등록기관은 다음 2개의 자원 레코드를 DNS 시스템에 삽입한다.
- (networkutopia.com, dns1.networkutopia.com, NS)
- (dns1.networkutopia.com, 212,212,212,1, A)
✅ 등록기관
- 도메인 네임의 유일성을 확인하고 그 도메인 이름을 DNS 데이터베이스에 넣고 그 서비스에 대해서 당신으로부터 약간의 요금을 받는 상업기관이다.
✖️ ICANN(InternetCorporation for Assigned Names and Numbers): 여러 등록기관을 승인해 준다.
😡 DDoS attacks
- DNS 서버를 사용 못하게끔 공격 시 도메인을 쓰지 못함.
DNS를 아래 예를 통해 총정리 해보자.
호주에 있는 앨리스가 www.networkutopia.com 웹 페이지를 보고자 한다고 가정하자.
- 그녀의 호스트는 먼저 DNS 질의를 자신의 로컬 DNS 서버로 보내고,
- 로컬 DNS 서버는 TLD com 서버에 접속할 것이다(또한 로컬 DNS 서버는 TLD com 스타일 서버의 주소가 캐시되어 있지 않으면 루트 DNS 서버를 접속해야만 한다).
- 이 TLD 서버는 위에 나열된 Type NS와 Type A 자원 레코드를 갖고 있다. 왜냐하면 등록기관이 이들 자원 레코드를 모든 TLD com 서버에 삽입했기 때문이다.
- TLD com 서버는 앨리스의 로컬 DNS 서버로 두 자원 레코드를 포함하는 응답을 보낸다.
- 그러고 나서 로컬 DNS 서버는 www.networkutopia.com에 에 대응되는 Type A 레코드를 요구하는 DNS 질의를 212.212.212.1에게 보내면, 이 레코드는 요구하는 웹 서버, 즉 212.212.71.4의 IP 주소를 제공한다.
- 그리고 로컬 DNS 서버는 앨리스 호스트에게 이 레코드를 전달한다.
- 이제 앨리스의 브라우저는 212.212.71.4 호스트로 TCP 연결을 초기화하고 그 연결로 HTTP 요청을 보낸다.
'CS > 컴퓨터네트워크' 카테고리의 다른 글
[Computer Network] 2.7 소켓 프로그래밍: 네트워크 애플리케이션 생성 (0) | 2022.10.13 |
---|---|
[Computer Network] 2.5 P2P 파일 분배 (0) | 2022.10.12 |
[Computer Network] 2.3 인터넷 전자메일 (0) | 2022.10.12 |
[Computer Network] 2.2 웹과 HTTP (0) | 2022.10.12 |
[Computer Network] 2.1 네트워크 애플리케이션의 원리 (0) | 2022.10.08 |