430 likes | 595 Views
제 14 장. 도메인 네임 시스템. 목차. 1. 서론 2. DNS 기본 3. DNS 메시지 형식 4. 간단한 예 5. 포인터 조회 6. 자원 레코드 7. 캐싱 8. UDP 또는 TCP 9. 그 밖의 예 10. 요약. 14.1 서론. Domain Name System TCP/IP application 에 의해 사용되는 분산 DB 호스트 이름과 IP 주소를 매핑 전자메일 라우팅 정보를 제공 C/S 가 통신할 수 있는 프로토콜을 제공
E N D
제 14 장 도메인 네임 시스템
목차 1. 서론 2. DNS 기본 3. DNS 메시지 형식 4. 간단한 예 5. 포인터 조회 6. 자원 레코드 7. 캐싱 8. UDP 또는 TCP 9. 그 밖의 예 10. 요약
14.1 서론 • Domain Name System • TCP/IP application에 의해 사용되는 분산 DB • 호스트 이름과 IP 주소를 매핑 • 전자메일 라우팅 정보를 제공 • C/S가 통신할 수 있는 프로토콜을 제공 • RFC 1034 - DNS 개념과 기능 • RFC 1035 - DNS 구현과 명세 • 캐시 기능(cashing)
서론(cont’d) • 변환기(Resolver) • Machine name을 알기 위해 필요한 application으로 컴파일된 라이브러리 • gethostbyname(3) ===> 호스트이름 -> IP 주소 • gethostbyaddr(3) ===> IP 주소 -> 호스트이름 • 매핑하기 위해 하나 이상의 이름 서버와 접속 • Application의 일부(클라이언트 측)
4.2 DNS 기본 • 계층적인 이름 공간 • 63 문자까지의 라벨을 가질 수 있는 노드 • 루트는 라벨이 없는 특별 노드 • 대, 소문자 구분을 하지 않음 • 레벨의 리스트로 구성 • 라벨을 구분하기 위하여 점(dot)를 사용 • 트리의 각 노드는 반드시 고유한 도메인 이름 • 마지막이 점으로 끝나면... • 절대 도메인 이름(Absolute Domain Name) • 완전한 도메인 이름(FQDN : Fully Qualified Domain Name)
DNS 기본(cont’d) 이름없는 루트 최상위 레 벨 도메인 arpa com edu gov int mil net org ae kr us 아랍연맹 제2레벨 도메인 in- addr noao ac “권한의 위임” 140 tuc han nam 252 sun net wk sun.tuc.noao.edu netwk.hannam.ac.kr 일반 도메인 국가 도메인 13 33 33.13.252.140.in-addr.arpa
DNS 기본(cont’d) • 최상위 레벨의 세 도메인 영역 • arpa : 주소를 이름으로매핑하기 위해 사용되는 특수 도메인 • 7개의 3-문자 도메인 • 범용 도메인(generic domain) • 조직 도메인(organizational domain) • 2-문자 도메인 • ISO 3166에 나타난 국가코드에 기초 • 국가 도메인(country) 또는 지역(geographcal) 도메인
DNS 기본(cont’d) • 3-문자 범용 도메인 도메인 설 명 com 상업 조직 edu 교육 기관 gov 비정부 관계기관 int 정부 조직 mil 군사 기관 net 네트워크 org 그 밖의 조직
DNS 기본(cont’d) • 도메인 이름 부여 • ~ 권한의 위임 • 영역(zone) • ~ DNS 트리의 서브 트리에서 개별적 관리 • 복수의 이름 서버 제공 가능 • 새로운 시스템 설치 • ~ 도메인 이름과 IP 할당, 이름 서버의 DB에 등록 • 위임된 권한을 분담 • ~ 대학의 학과, 회사의 부서
DNS 기본(cont’d) • 1차 이름 서버가 고장날 때를 대비해 2차 이름 서버 • 1차 이름 서버(primary name server) • ~ 영역에 대한 모든 정보 • 2차 이름 서버(secondary name server) • ~ 영역 전송(zone transfer) • ~ 모든 정보를 1차 이름 서버로부터 획득 • ~ 정기적인 주기(3시간)마다 1차 이름 서버를 조회
DNS 기본(cont’d) • 이름 서버가 요청된 정보를 가지고 있지 않을 때 • ~ 다른 이름 서버와 접속(DNS의 분산 특성) • ~ 모든 이름 서버는 루트 이름 서버(root name server)와 접속 • 1차 이름 서버 • ~ 각 루트 이름 서버의 IP주소를 알고 있어야 한다. • 루트 이름 서버 • ~ 제2레벨 도메인을 관리하는 이름 서버의 이름과 IP를 알고 있다.
DNS 기본(cont’d) • 루트 이름 서버 목록 • ~ ftp.rs.internic.net/netinfo/root-servers.txt HOSTNAME NET ADDRESSES SERVER PROGRAM ROOT-SERVERS.NET 198.41.0.4 BIND (UNIX) ROOT-SERVERS.NET 128.9.0.107 BIND (UNIX) ROOT-SERVERS.NET 192.33.4.12 BIND (UNIX) ROOT-SERVERS.NET 128.8.10.90 BIND (UNIX) ROOT-SERVERS.NET 192.203.230.10 BIND (UNIX) ROOT-SERVERS.NET 192.5.5.241 BIND (UNIX) ROOT-SERVERS.NET 192.112.36.4 BIND (UNIX) ROOT-SERVERS.NET 128.63.2.53 BIND (UNIX) ROOT-SERVERS.NET 192.36.148.17 BIND (UNIX) ROOT-SERVERS.NET 198.41.0.10 BIND (UNIX) ROOT-SERVERS.NET 193.0.14.129 BIND (UNIX) ROOT-SERVERS.NET 198.32.64.12 BIND (UNIX) ROOT-SERVERS.NET 202.12.27.33 BIND (UNIX)
14.3 DNS 메시지 형식 • DNS 조회와 응답의 일반 형식 0 15 16 31 식별자 플래그 질문의 수 대답 RR의 수 12 바이트 권한 RR의 수 추가 RR의 수 질문(그림 14.5 참조) 응답(그림 14.8 참조) (RR에 대한 가변 길이) 권한 (RR에 대한 가변 길이) 추가 정보 (RR에 대한 가변 길이)
DNS 메시지 형식(cont’d) • 조회/응답 메시지 • 고정 길이의 12 바이트 • 4개의 가변길이를 갖는 필드 • 식별자 • 설정 : 클라이언트 • 반환 : 서버 • 클라이언트는 식별자에 의해 요구/응답 조회 • 플래그 - 16 bit • 질문의 수, 응답 RR의 수 • 위임 RR의 수, 추가 RR의 수
QR opcode AA TC RD RA (zero) rcode 1 1 1 1 1 3 4 4 DNS 메시지 형식(cont’d) • DNS 헤더의 플래그 필드 • QR : 0(접속 요구)/ 1( 응답) • opcode : 0 (표준조회) / 1(역조회) / 2(서버상태 요구) • AA : 권한있는 대답 • TC : 절단(truncated) - 전체 크기가 초과하여 512바이트만 리턴 • RD : 재귀 요구 • RA : 재귀 가능 - 서버가 재귀를 지원한다면 응답에서 1로 설정 • (zero) : 3 bit를 0으로 설정 - 추후 사용을 위해 예약 • rcode : 리턴 코드- 0(에러 없음), 1(양식오류), 2(서버실패), 3(이름 에러), 4(구현되지 않음), 5(거절), 6~15(추후사용)
6 g e m i n i 3 t u c 4 n o a o 3 e d u 0 DNS 메시지 형식(cont’d) • DNS 조회 메시지의 질문 부분 형식 • 도메인 이름 gemimi.tuc.noao.edu 표현 0 31 15 16 조회 이름 조회 유형 조회 클래스 카운트 카운트 카운트 카운트 카운트
DNS 메시지 형식(cont’d) • 조회 이름(query name) • ~ 검색하고자 하는 이름 • ~ 하나 이상의 레이블 연속 • ~ 각 레이블은 뒤에 나오는 바이트 수를 나타내는 1바이트 카운트 • ~ 조회 이름은 0바이트로 끝남(루트 레이블) • ~ 카운트 : 0 ~ 63까지의 범위 • ~ 패딩할 필요가 없음
DNS 메시지 형식(cont’d) • 조회 유형(query type) • ~ 각 응답(RR)은 하나의 유형을 갖음 • ~ 약 20개의 유형 • 조회 클래스(query class) • ~ 보통 1 • ~ 인터넷 주소
도메인 이름 유형 클래스 생존 시간 자원 데이터 길이 자원 데이터 DNS 메시지 형식(cont’d) • DNS RR(자원 레코드) 형식 0 31 15 16
DNS 메시지 형식(cont’d) • 도메인 이름(domain name) • ~ 자원 데이터의 내용 • 유형(type) • ~ RR 유형 코드 중 하나 • 클래스(class) • ~ 인터넷 데이터의 경우 1 • 생존시간(time-to-live) • ~ RR이 클라이언트에 의해 캐시되는 초 단위 시간 • 자원 데이터의 길이(resource record length) • ~ 자원 데이터의 양, 이 데이터 형식은 유형에 따라 다르다. • ~ 유형 1(A 레코드)의 경우 자원 데이터는 4바이트의 IP 주소
14.4 간단한 예 ce#telnet netwk daytime Trying 203.247.39.32... Connected to netwk.hannam.ac.kr. Escape character is '^]'. Thu Nov 19 23:00:02 1998 Connection closed by foreign host. • 변환기와 이름 서버간의 통신 telnet 클라이언트 로부터의 출력 daytime 서버의 출력 telnet 클라이언트의 출력
간단한 예(cont’d) • 간단한 DNS 예제에 사용된 시스템 Daytime 서버 이름 서버 Noao.edu gemini .1.54 .1.11 140.252.1 .1.29 Telnet 클라이언트 sun
간단한 예(cont’d) • host sun의 파일 “/etc/resolv.conf”는 변환기가 할 일을 지시 sun% cat /etc/resolv.conf nameserver 140.252.1.54 domain tuc.noao.edu 이름 서버 호스트 noao.edu의 IP 주소 표시, 최대 3개까지 지정 디포트 도메인을 지정
간단한 예(cont’d) • 호스트 이름 gemini.tuc.noao.edu의 이름 서버 조회의 tcpdump 출력 1 0.0 140.252.1.29.1447 > 140.252.1.54.53: 1+ A? gemini.tuc.noao.edu. (37) 2 0.290820 (0.2908) 140.252.1.54.53 > 140.252.1.29.1447: 1* 2/0/0 A • 140.252.1.11 (69) • 위 출력은 변환기와 이름 서버사이의 패킷교환을 보여 준다. • Port 1447 : 클라이언트에 의해 사용되는 일시적인 Port • Port 53 : 이름 서버의 알려진 Port • 1+ : 식별자(identifier)가 1 • + : RD 재귀 요구 플래그가 설정, Default로 변환기가 재귀를 요구 • A? : 조회 유형이 A(IP 주소 요구) • ? : 응답이 아닌 조회를 의미
간단한 예(cont’d) • UDP datagram에서 사용자 데이터의 길이는 37 바이트 • 고정된 길이의 헤더 : 12 바이트 • 조회 이름 : 21 바이트 • (조회 유형과 조회 클래스) : 4 바이트 • 홀수 길이의 UDP datagram : DNS 메시지에 패딩이 없음 • 2 번 줄 : Name server로부터의 응답 • 1* : 은 AA(권위있는 응답) 플래그 설정 • 2/0/0 : 3개의 가변길이 필드의 RR수 • 2 : 응답RR, 0 :권위RR, 0 :추가RR • tcpdump는 첫 번째 응답만을 출력하고 유형이 A( IP 주소)인 값은 140.252.1.11 • 왜, 하나의 조회로 두개의 응답을 얻는가? • 호스트 gemini가 멀티홈드이기 때문
IP 데이터그램 UDP 데이터그램 DNS 메시지 UDP 헤더 IP 헤더 DNS 헤더 Question (그림 14.5) IP 헤더 IP 헤더 20 8 12 25 16 16 도메인 이름 (6gemini3tuc4noao3edu0) qtype (1) qclass (1) ptr (12) 유형 (1) 클래스 (1) 길이 (4) TTL IP주소 21bytes 2 2 2 2 2 4 2 4 간단한 예(cont’d) • 그림 14.10의 두 번째에 대응하는 DNS 형식
14.5 포인터 조회 Sun % host 140.252.13.34 Name : svr4.tuc.noao.edu Address : 140.252.13.34 명령어의 인수가 IP 주소이기 때문에, 호스트 프로그램은 자동적으로 포인터 조회를 생성 • 포인터 조회에 대한 tcpdump 출력 1 0.0 140.252.1.29.1610 > 140.252.1.54.53: 1+ PTR? 34.13.252.140.in-addr.arpa. (44) 2 0.332288 (0.3323) 140.252.1.54.53 > 140.252.1.29.1610: 1* 1/0/0 PTR svr4.tuc.noao.edu. (75)
포인터 조회(cont’d) • 1번 라인 1 : 식별자 + : 재귀요구 설정 PTR : 조회유형 ? : 응답이 아닌 조회 44 : 데이터 크기 DNS 헤더 : 12 바이트 도메인 이름의 7개 레벨 : 28 바이트 (조회 유형과 조회 클래스) : 4 바이트 2번 라인 1* : AA(권위있는 응답) 플래그 설정 1/0/0 : 3개의 가변길이 필드의 RR수 1 : 응답 RR 0 : 권위 RR 0 : 추가 RR PTR : RR 유형 자원데이터 : 도메인 이름 포함
포인터 조회(cont’d) • 호스트 이름 속임수 검사 • ~ 그림 14.13은 함수 gethostbyaddr이 IP address 140.252.1.29에 상응하는 이름을 호출했을 때 SLIP link에 수집된 tcpdump를 출력 • 1 0.0 sun.1812 > noao.edu.domain: 1+ PTR? • 29.1.252.140.in-addr.arpa. (43) • 20.339091 (0.3391) noao.edu.domain > sun.1812: 1* 1/0/0 PTR • sun.tuc.noao.edu. (73) • 3 0.344348 (0.0053) sun.1813 > noao.edu.domain: 2+ A? • sun.tuc.noao.edu. (33) • 4 0.669022 (0.3247) noao.edu.domain > sun.1813: 2* 2/0/0 PTR • 140.252.1.29 (69)
포인터 조회(cont’d) • 1번 라인 : 포인터 조회 • 2번 라인 : 응답 • 3번 라인 : 변환기함수는 자동적으로 두 번째 줄에서 받은 이름에 대해 세 번째 줄에서 IP 주소 조회를 보낸다. • 4번 라인 : 응답은 두개의 응답 레코드를 포함 • 호스트 sun이 두개의 IP 주소를 가지기 때문 • 만일, 주소중의 하나가 gethostbyaddr에 대한 인수와 맞지 않는다면 메시지가 시스템 기록장치에 보내지고, 그 함수는 에러를 반환
14.6 자원 레코드(Resource Records) • A • ~ IP 주소 정의, 32-bit binary 값으로 저장 • PTR • ~ 포인터 조회에 사용하는 포인터 레코드 • CNAME • ~ 규범적 이름(canonicalname)을 의미 • ~ 도메인 이름(domain name)으로 표현 • ~ 규범적 이름을 갖는 도메인 이름은 “alias”로 불린다. • ~ 몇몇 ftp 사이트에서 다른 시스템에 대한 alias를 쉽게 기억하기 위해 사용 • HINFO • ~ 호스트 정보(CPU와 운영체제) 표시 • ~ 모든 사이트에서 HINFO 레코드를 제공하는 것은 아니다. • ~ 최신 정보가 아닐 수 도 있다.
자원 레코드(cont’d) • MX ~ 메일 교환 레코드 1) Internet에 접속되어 있지 않은 사이트는 인터넷에 접속되어 있는 사이트를 메일 교환기로 이용할 수 있다. 그러면, UUCP protocol을 사용 2) 목적지 host가 이용이 불가능할 때, 대체 host로 mail 보내는 방법 제공 3) 조직은 cs.university.edu.와 같은 메일을 보낼 수 있는 가상호스트 설정 가능 4) 방화벽 게이트웨이를 가진 조직은 MX 레코드를 사용해서 접속을 내부 시스템만으로 제한할 수 있다. • NS ~ 이름 서버 레코드 ~ 도메인의 권위있는 이름 서버 지정 ~ 도메인(레벨의 순서)
14.7 캐싱(Caching) • 인터넷상에서 DNS 트래픽을 줄이기 위해 사용 • 모든 이름서버는 캐쉬를 사용 • 변환기가 아닌 서버에서 관리 • 시스템이 가동되고 있는 동안 항상 메모리에 두는 프로그램(이름서버)으로 캐시를 관리 • 캐시는 서버에서 동작하는 모든 응용이 가능 • 이 이름서버를 이용하는 사이트의 다른 모든 호스트도 이 서버의 캐시를 공유
캐싱(cont’d) • 그림 14.14 호스트 ftp.uu.net의 tcpdump 출력 1 0.0 sun.tuc.noao.edu.domain > NS.NIC.DDN.MIL.domain: 2 A? ftp.uu.net. (28) 2 0.559285 (0.5593) NS.NEC.DDN.MIL.domain > sun.tuc.noao.edu.domain: 2- 0/5/5 (229) 3 0.564449 (0.0052) un.tuc.noao.edu.domain > ns.UU.NET.doamin: 3+ A? ftp.uu.net. (28) 4 1.009476 (0.4450) ns.UU.NET.domain > sun.tuc.noao.edu.domain: 3* 1/0/0 A ftp.UU.NET (44)
캐싱(cont’d) • 1번 라인 ~ 식별자가 작은 정수(2,3) : 이것은 캐쉬를 비우기 위해 name server를 중지시키고, 네임 서버를 다시 작동 시키기 때문이다. Name server가 시작될 때 식별자를 1로 초기화 호스트 ftp.uu.net의 IP 어드레스를 찾고, name server는 11대의 루트 서버 중 하나와 접속(ns.nic.ddn.mil) • 2번 라인 : ~ 응답으로 대답 RR이 0, 권위 RR이 5, 추가 정보 RR이 5, (-)는 재귀가능 플래그가 설정되지 않음 ~ 이것은 루트 서버가 만약 이것을 요청하였다 하더라도 반복 의문 부호에 대해 응답하지 않는다.
캐싱(cont’d) • 그림 14.15 host ftp.ee.lbl.gov의 tcpdump 출력 1 18.664971 (17.6555) sun.tuc.noao.edu.domain > c.nyser.net.domain: 4 A : ftp.ee.lbl.gov. (32) 2 19.429412 (0.7644) c.nyser.net.domain > sun.tuc.noao.edu.domain: • 0/4/4 (188) 3 19.432271 (0.0029) sun.tuc.noao.edu.domain > ns1.lbl.gov.domain: 5+ A? ftp.ee.lbl.gov. (32) 4 19.909242 (0.4770) nsl.lbl.gov.domain > sun.tuc.noao.edu.domain: 5* 2/0/0 CNAME ee.lbl.gov. (72)
캐싱(cont’d) • 1번 라인 : 서버가 다른 루트서버(c.nyser.net)에 접속한 것을 나타내고 있다. 이름 서버는 보통 왕복시간이 결정되기까지 영역의 여러 가지 서버를 이용한다. 그래서 왕복시간이 가장 짧은 서버를 이용한다. • 2번 라인 :대답(answer)이 없는 응답이 돌아온다. 그러나 4 개의 권위 RR과 4 개의 추가 정보 RR이다. 4 개의 권위 RR이 이름서버 ftp.ee.lbl.gov에 대한 이름을, 4개의 추가 정보 RR은 IP 주소를 가지고 있다고 추측 • 3번 라인 : 이름 서버 ns1.lbl.gov의 조회, 재귀 요구 플래그 설정 • 4번 라인 : 응답은 이전의 응답과는 다르다. 2개의 대답 RR이 되돌아오고, tcpdump는 가장 처음이 CNAME RR이라는 것을 나타낸다.
14.8 UDP 또는TCP • DNS 이름 서버에 대한 port는 TCP, UDP가 53 • 변환기가 조회를 보내고 “truncated”라는 응답이 왔을 때,이것은 512byte를 초과한 것을 의미한다. • 그래서 처음의 512byte만 서버로부터 돌아온다. • 이 경우, 변환기는 일반적으로 TCP를 이용해 요구를 다시 발행 • 이것에 의해 512byte 이상이 되돌아 오는 것이 가능 • 2차 이름서버는 3시간마다 1번씩 1차 이름서버의 변경 내용을 조회 ------- TCP 이용 • DNS는 기본적으로 UDP를 사용 • UDP 응용 - LAN, DNS- WAN 용(패킷 손실률, 왕복시간)
14.9 그 밖의 예 Rlogin 클라이언트와 서버의 가동 시 패킷 교환
14.9 그 밖의 예(cont’d) 1. 클라이언트는 호스트의 name을 IP 어드레스로 전환하기 위하여 resolver 함수를 호출한다. A 형식의 query는 root server로 보내진다. 2. Root server의 응답은 서버의 domain 에 대한 name server를 갖고 있다. 3. 클라이언트의 resolver는 A 형식의 query를 서버의 name server에게 다시 보낸다. 이 query는 일반적으로 recursion-desired flag를 설정한다. 4. 서버 호스트의 IP 어드레스를 가진 응답신호가 돌아온다. 5. Rlogin 클라이언트는 Rlogin 서버를 가진 TCP 접속을 설정한다. 세개의 패킷은 클라이언트와 서버 TCP 모듈 간에 교환된다. 6. Rlogin 서버는 클라이언트로부터 접속을 받고 클라이언트 호스트의 이름을 얻기 위해 자신의 resolver를 호출한다. 7. Root server의 응답은 클라이언트의 in-arpa domain에 대한 name server를 갖는다.
14.9 그 밖의 예(cont’d) 8. Root server의 응답은 클라이언트의 name server에 PTR query를 다시 보낸다. 9. PTR 응답은 클라이언트 hsot의 FQDN을 포함한다. 10. 서버의 resolver는 클라이언트의 name server에 대한 A 형식query를 넘겨준다. 전 단계에서 이름에 해당하는 IP 주소가 돌아온다. 11.클라이언트 name server로부터의 응답은 클라이언트 host를 위한 A 기록을 포함하고 있다. Rlogin 서버는 클라이언트의 TCP 연결 요청으로부터의 IP 주소와 A 기록을 비교한다.
요약 • DNS는 인터넷에 접속되어 있는 중요한 부분 • 기본적인 구조 : 계층적인 트리 • Resolver에서 host name을 IP 주소와 바꾼다. Resolver는 local name server와 접속하고, 요청을 실행하기위해 이 서버는 root server의 하나와 접속하거나 다른 서버와 접속할 것이다. • DNS 요청과 응답은 같은 메시지 형식을 갖는다. • 질문과 대답 RR, 권위 RR, 추가 정보 RR을 포함 • 변환기의 구성파일 • DNS의 최적화 기술 - 도메인 이름의 포인터(메시지의 크기 압축), 캐시,in-addr.arpa(IP 주소로부터 이름 검색), 추가 정보 RR(요구측 조회의 수소를 더는)….