DNS (Domain Name System)

클라이언트가 서버에 동시에 들어와서 작업하는게 많아졌다 (채팅등)

-> http 등 나왔다.

웹이 나오기전에는 터미널로 그래픽을 이용해서 ip, 패스워드 치고 접속해서 (ftp 서버) 파일 다운받고, 주고 받고 했다.
ip수첩 따로 만들어놨다. (ip주소와 사이트명을 같이 적어놓는다.)
                             서울대학교 도서관,,등등

사람들마다 각자 주소 목록을 종이등에 가지고있어야한다...(지금의 북마크)

시스코장비 - host file ( ip, name등 관리 )

 

※ 이름 공간

- 혼란을 피하기 위해 각 장치에 할당되는 이름은 이름과 IP 주소간의 매핑을 담당하는 이름 공간(name space)으로부터 신중하게 선택해야함

 

- 각 주소를 유일한 이름에 매핑하는 이름 공간은 하나는 단층적(flat)인 것이고 다른 하나는 계층적(hierarchical)으로 두가지 방법이 있음

 

< 단층적 이름 공간 >

- 단층적 이름 공간에서 이름은 주소에 할당     // 내부적으로 식별및 관리하기 위한 것 = '단층적'

- 이 공간에서 이름은 구조적이지 않은 문자의 연속으로 나타남

- 이름은 공통 부분을 가질 수도 있고 아닐 수도 있음

       ->만약 가진다면 어떤 의미도 가지지 않게 됨

- 단층적 이름 공간의 가장 큰 단점은 인터넷과 같은 큰 시스템에서는 사용할 수 없다는 것인데,

  이는 할당되는 이름들이 중복되지 않고 명확하게 사용되기 위해서는 중앙에서 전체적으로 관리가 되어야 하기 때문

 

< 계층적 이름 공간 >

- 각 이름은 여러 부분으로 나뉘어 구성        // 분산해서 관리

       - 첫 번째 부분은 조직의 성격을 나타냄

       - 두 번째 부분은 조직의 이름

       - 세 번째 부분은 조직내의 부서를 나타냄

- 중앙 기관은 조직의 성격과 조직의 이름을 정의하는 이름의 일부만을 할당할 수 있음

- 이름의 나머지 부분을 할당하는 책임은 그 조직에게 주어짐

- 각 조직은 그 이름에 접두사나 접미사를 붙여 호스트나 자원을 정의함

- 한 조직내의 관리자는 동일한 접두사나 접미사가 다른 조직 내에서 사용되었는지에 대해 걱정할 필요가 없음

 

ex) samsung을 줬으면 그에 해당하는 것들은 다 samsung에서 관리한다.

 

 

 

도메인 이름공간과 내 도메인 이름 공간

 

3자로 끝나면 우리나라에서 관리 하는게 x NIC에서 관리 (일반 최상위 도메인)

 

1단계 - 조직의 성격 / 나라  ,  2단계 - 조직의 이름 , 3단계 - 조직내의 부서

 

< 레이블 >

- 트리의 각 노드는 레이블(label)을 가지는데 이는 최대 63개의 문자로 구성

- 루트 레이블은 널 스트링(혹은 empty string)으로 불림

- DNS는 동일 노드에서 연결되어 지는 노드들인 자식 노드들이 다른 레이블을 가질 수 있도록 하여 도메인 이름의 유일성을 보장

 

< 도메인 이름 >

- 트리의 각 노드는 도메인 이름을 가짐

- 완전한 도메인 이름은 점( .)으로 구분

- 도메인 이름은 항상 노드에서 루트 방향으로 읽힘

- 널 스트링이 아무 것도 없는 것을 말하므로 완전한 도메인 이름은 항상 점으로 끝나게 된다는 것을 말함

 

< FQDN >

- 레이블이 널 스트링으로 끝나는 것을 FQDN(Fully Qualified Domain Name)이라 부름

- FQDN은 호스트의 완전한 이름을 포함하는 도메인 이름

- FQDN은 호스트의 이름을 유일하게 정의하는, 가장 명시적인 것부터 가장 일반적인 것까지의, 모든 레이블을 포함

- DNS 서버는 하나의 주소에 대해 하나의 FQDN만을 가짐

- 이름은 항상 널 레이블로 끝나야 하는데 이것이 아무 것도 의미하지 않으므로 레이블은 항상 점으로 끝남

 

< PQDN >

- 레이블이 널 스트링으로 끝나지 않으면 이를 부분적으로 PQDN(Partially Qualified Domain Name)이라 부름

- PQDN은 노드로부터 시작하나 루트에 도달하지는 않음

- 이는 해석할 이름이 클라이언트와 동일한 사이트에 속해 있을 때 사용

- 여기서 해석기(resolver)는 FQDN을 생성하기 위해 첨자(suffix)라고 불리는 나머지 빠져있는 부분을 제공

- DNS 클라이언트는 보통 첨자의 항목을 가짐

 

< 도메인 >

- 도메인은 도메인 이름 공간의 서브 트리

- 도메인 이름은 서브 트리의 맨 상위에 있는 노드의 도메인 이름

- 도메인은 그 자체가 다른 도메인들(또는 서브 도메인들)로 나뉘어 질 수 있음

도메인

< 이름 서버의 계층 >

- 도메인 이름 공간에 포함된 정보는 저장되어야만 함

- 그러나, 이렇게 엄청나게 많은 양의 정보를 하나의 컴퓨터에만 저장하는 것은 비효율적이고 안전하지도 않음

- 이러한 문제점의 해결책은 정보들을 DNS 서버라는 많은 컴퓨터에 분산시키는 것으로 모든 공간을 첫 번째 레벨에 기초하여 많은 도메인으로 나누는 방법이 있음

 

이름 서버의 계층

< 영역(zone) >

- 서버가 책임을 지거나 권한을 가지는 곳

- 서버가 도메인에 대한 책임을 수락하고 이를 더 작은 도메인으로 나누지 않았다면 도메인과 영역은 같은 것을 의미

- 서버는 영역 파일(zone file)이라는 데이터베이스를 가지며 그 도메인 내의 모든 노드 정보를 여기에 보관

- 그러나, 서버가 도메인을 서브 도메인으로 나누고 일부를 다른    서버에 권한 이양하게 되면 도메인과 영역은 서로 다른 의미가 됨

Zone

< 루트 서버(Root Server) >

- 루트 서버는 전체 트리를 영역으로 가지는 서버

- 루트 서버는 보통 도메인에 대한 어떠한 정보도 가지지 않으며 자신의 권한을 다른 서버들에게 이양하고 자신은 이러한 서버들에 대한 참조만을 가지게 됨

- 현재 13개 이상의 루트 서버가 있으며 각각은 전체 이름 공간을 다루고 있음

- 서버들은 전 세계에 분산되어 있음

 

< 일차 및 이차 서버 >

- DNS는 일차 서버와 이차 서버라는 두 가지 서버를 정의

- 1차 서버는 자신이 권한을 가지는 영역에 대한 파일을 가짐

- 이는 영역 파일에 대한 생성, 관리, 갱신에 대한 책임을 가지며 로컬 디스크에 영역 파일을 저장

 

- 2차 서버는 다른 서버(일차 및 이차 서버)로부터 영역에 관한 완전한 정보를 수신하여 로컬 디스크에 파일을 저장하는 서버                                                                                                            이차서버 = 백업 서버 

- 2차 서버는 영역 파일을 생성하지도 않고 갱신하지도 않음

- 갱신이 필요하면 이는 1차 서버에서 이루어진 후 2차 서버로 갱신된 버전이 보내지게 됨

- 1차와 2차 서버는 모두 자신들이 서비스하는 영역에 권한을 가짐

- 2차 서버가 더 낮은 레벨의 권한을 가지는 것은 아니며 하나의 서버가 실패할 경우 다른 서버가 클라이언트를 계속 서비스할 수 있도록 중복된 데이터를 유지함

 

네트워크에서의 이중화란?

하나는 내부망만 연결되어있고, 하나는 외부망이랑만 연결 되어있다. 

-> 내, 외부로서의 유출을 막기 위함

 

※ 인터넷 내에서의 DNS

- DNS는 여러 다른 플랫폼에서 사용되어 질 수 있음

-인터넷에서, 도메인 이름 공간(트리)은 3가지 다른 섹션으로 나뉘어

(일반 도메인, 국가 도메인, 인버스(inverse) 도메인)

도메인 이름 공간 3 섹션

 

< 일반 도메인 >

- 일반 도메인은 그들의 일반적인 특성에 따라 등록된 호스트를 정의

- 트리에 있는 각 노드는 도메인을 정의하며, 이는 도메인 이름 공간 데이터베이스에 대한 색인을 의미

- 트리를 보면, 일반 도메인 섹션에 있는 첫 번째 레벨에서 7개의 세 문자로 구성된 레이블이 허용 가능함을 알 수 있음

일반 도메인

< 일반 도메인 레이블 >

일반 도메인 레이블

새로운 일반 도메인 레이블

 - 최근에 들어 몇 가지 첫 번째 레벨 레이블이 새로 제안됨

새로운 일반 도메인 레이블

< 국가 도메인 >

- 국가 도메인(Country domain) 섹션은 일반 도메인과 동일한 형태를 가지나 앞에서와 같이 세 문자로 구성된 것이 아니라 두 문자로 국가의 약자 형태를 표시

- 두 번째 레벨의 레이블은 조직을 나타낼 수도 있고, 아니면 더 명시적으로 국가 지정이 될 수도 있음

                      국가 도메인

< 인버스 도메인 >

- 인버스 도메인(inverse domain)은 주소를 이름으로 매핑하는데 사용되며, 서버가 클라이언트로부터 이러한 업무를 요청 받은경우에 일어날 수 있음

          -서버가 인증된 클라이언트들의 항목을 포함하는 파일을 가지고 있긴 하지만, 이 클라이언트가 현재 인증된 항             목에 있는지 없는지를 결정하기 위해서는 DNS 서버에 질의하고 주소를 이름으로 바꾸도록 해석기에게 요청하             여야 함

         (인버스 or 포인터(PTR) 질의)

 

- 인버스 도메인을 처리하는 서버들도 계층적

      - 이는 주소의 netid 부분이 subnetid 부분보다 더 높은 레벨이어야 함을 의미하고 subnetid는 hostid 보다 높은              레벨이어야 함을 의미

     - 이와 같은 방식으로 전체 사이트를 서비스하는 서버는 각 서브 네트워크를 서비스하는 서버보다 레벨이 높음

인버스 도메인

※ 해석

- 이름을 주소로 매핑하거나 주소를 이름으로 매핑하는 것을 이름-주소 해석(name-address resolution) 이라 함

 

< 해석기 >

- 주소를 이름으로, 혹은 이름을 주소로 매핑하기 원하는 호스트는 해석기(resolver)라고 불리는 DNS 클라이언트를 호출

- 해석기는 매핑 요구를 보내기 위해 가장 가까운 DNS 서버에 접속

- 만약 서버가 정보를 가지고 있으면 해석기에 대한 응답을 줄 수 있으나 그렇지 않으면 해석기가 다른 서버를 참조하게    거나 다른 서버가 이 정보를 제공하도록 요구

- 해석기가 매핑 결과를 수신한 후 제대로 온 것인지 아니면 오류가 난 것인지를 알아보기 위해 응답을 해석한 다음,

   최종적으로 그 결과를 요청한 프로세서에 전달

 

< 이름을 주소로 매핑 >

- 대부분 해석기는 도메인 이름을 서버에 주고 해당 주소를 요청

- 서버는 매핑을 찾기 위해 일반 도메인 혹은 국가 도메인을 검사

- 도메인 이름이 일반 도메인 섹션에 있을 경우

      해석기는 “chal.atc.fhda.edu.”와 같은 도메인 이름을 수신

      질의는 해석을 위해 해석기에 의해 로컬 DNS 서버로 보내어 짐

      로컬 서버가 질의를 해결하지 못하면 해석기에게 다른 서버를 참조하도록 하거나 다른 서버에게 직접 요청

- 도메인 이름이 국가 도메인 섹션에 있을 경우

      해석기는 “ch.fhda.cu.ca.us.”과 같은 도메인 이름을 수신

      절차는 동일

 

< 주소를 이름으로 매핑 >

- DNS 클라이언트는 도메인 이름으로 매핑되어질 IP 주소를 서버로 보냄

- 이런 종류의 질의에 응답하기 위해 DNS는 인버스 도메인을 사용

- 그러나 이때 질의에는 IP 주소가 반대로 되어야 하고 인버스 도메인 섹션에서 받아들여질 수 있는 도메인이 만들어지도록 두 레벨인 in-addr과 arpa가 추가되어야 함

 

귀환적 해석

< 귀환적 해석 >

- 클라이언트(해석기)는 이름 서버에 귀환적인(recursive) 응답을 요청할 수 있는데 이는 해석기가 서버로부터 최종적인 해석 결과를 얻을 수 있을 것이라고 기대함을 의미

- 서버가 도메인 이름에 대한 권한을 가진다면 데이터베이스를 찾아본 뒤 응답을 함

- 서버가 권한이 없다면 다른 서버(주로 부모 서버)에게 요청을 보내고 응답을 기다림

- 부모서버가 권한을 가진다면 응답을 하고, 그렇지 않다면 또 다른 서버에게 질의를 보냄

- 질의가 최종적으로 해석되면, 응답은 요청을 보낸 클라이언트에게 도달할 때까지 거꾸로 거슬러 가게 됨

 

 

반복적 해석

< 반복적 해석 >

- 클라이언트가 귀환적 해석을 요청하지 않으면, 매핑은 반복적(iterative)으로 진행

- 서버가 이름에 대한 권한을 가진다면, 응답을 보내고 그렇지 않다면 이 질의를 해석할 수 있을 것 같은 서버의 IP 주소를 클라이언트에게 되돌려 줌

- 클라이언트는 이 두 번째 서버에 질의를 반복할 의무를 가짐

- 새로 선택된 서버가 문제를 해결할 수 있으면 질의에 대한 IP 주소를 답하게 되고 그렇지 않으면, 새로운 서버의 IP 주소를 되돌려 줌

- 이제 클라이언트는 세 번째 서버에 질의를 반복

- 이 과정을 반복적이라 하는데 이는 클라이언트가 다수의 서버들에게 같은 질의를 하기 때문

 

< 캐슁 >

- DNS는 검색 시간의 감소로 인한 효율 증가를 위해 캐슁(caching)이라는 절차를 이용

- 서버가 다른 서버에게 매핑 정보를 요청하고 응답을 수신하면 이 정보를 클라이언트에게 전달하기 전에 캐쉬 메모리에 저장

- 동일한 혹은 다른 클라이언트가 동일한 매핑을 조회해오면 서버는 자신의 캐쉬 메모리를 검색한 후 문제를 해결

- 그러나 클라이언트에게 지금 이 응답이 권위 있는 기관이 아니라 캐쉬 메모리에서 얻어진 것임을 알리기 위해 서버는 응답을 인증 받지 못했다(unauthoritative)는 표시를 하여 보냄

- 캐슁은 주소 해석 속도를 높일 수 있지만 문제 또한 가지고 있음

 

- 서버가 오랫동안 캐쉬 정보를 가지고 있다면 클라이언트에게 잘못된 매핑 정보를 보낼 수도 있음

 

- 이를 해결하기 위해 두 가지 기법을 사용

       하나는 권한 있는 서버가 매핑 정보에다 수명(time-to-live; TTL)이라는 추가적인 정보를 제공하는 것

       두 번째는 각 서버가 캐쉬하고 있는 각 매핑에 대해 TTL 카운터를 가지도록 DNS가 요구하는 것

 

※ DNS 메시지

< DNS 메시지의 캡슐화 >

- DNS는 UDP나 TCP에 캡슐화

        UDP에 캡슐화 : 응답 메시지의 크기가 512byte 미만

        TCP에 캡슐화 : 응답 메시지의 크기가 512byte 이상

- DNS 식별 -> 포트번호 : 53 (TCP/UDP 동일)

 

DNS 메시지의 캡슐화

 

< DNS는 두 가지 종류의 메시지를 가지고 동일한 형식을 가짐 >

- 질의 메시지는 헤더와 조회 레코드(question records)로 구성

- 응답 메시지는 헤더와 조회 레코드, 응답 레코드(answering records), 권한 레코드(authoritative records) 와 추가적인 레코드들로 구성

 

< DNS 메시지 >

- 질의 섹션(Question section)

      하나 이상의 질의 레코드로 구성

      질의 메시지와 응답 메시지 모두에 존재

- 응답 섹션(Answer section)

      하나 이상의 자원 레코드로 구성

      응답 메시지에 존재하며, 서버 è 클라이언트로의 응답 포함

- 권한 섹션(Authoritative section)

      하나 이상의 자원 레코드로 구성

      질의에 대해 권한 있는 서버의 정보(도메인 이름) 제공

- 추가 섹션(Additional section)

      하나 이상의 자원 레코드로 구성

      해석기에서 도움이 될 만한 추가적인 정보 제공

 

< 헤더 (12 byte) >

- 질의와 응답 메시지는 모두 같은 헤더 형태를 가지며 질의 메시지의 경우 몇 개의 필드는 0으로 지정

 

헤더 필드

< 헤더 필드 >

- 식별자

   이는 클라이언트에서 질의에 대한 응답과의 비교를 위해 사용하는 16 비트 필드

   클라이언트는 질의를 보낼 때마다 서로 다른 식별자 번호를 사용

   서버는 해당 응답에 이 번호를 복사하여 넣음

- 플래그

   서브 필드들로 구성되는 16 비트 필드

 

< DNS 헤더 형식 >

- 질의 레코드의 수

    이 16비트 필드는 메시지의 질의 섹션내의 질의 수를 포함

- 응답 레코드의 수

    이 16 비트 필드는 응답 메시지의 응답 섹션에 있는 응답 레코드의 수를 포함

    이 값은 질의 메시지에서는 0

- 권한 레코드의 수

    이 16 비트 필드는 응답 메시지의 권한 섹션내의 권한 레코드의 수를 포함

    이 값은 질의 메시지에서는 0

- 추가 레코드의 수

    이 16 비트 필드는 응답 메시지의 추가 섹션에 있는 추가 레코드의 수를 포함

    이 값은 질의 메시지에서는 0

 

※ 레코드의 종류

< 질의 레코드 >

- 질의 메시지와 응답 메시지의 질의 섹션에 사용

- 클라이언트가 서버로부터 정보를 얻기 위해 사용

 

- 질의 이름

    이 필드는 가변 길이를 가지며 도메인 이름을 포함

 

파싱 -> 토큰으로 구분해서 따오는것 

XML 통신 ->  안드로이드 앱 , 화면UI 

 

- 질의 종류

   이 16 비트 필드는 질의 종류를 나타냄

   마지막 두 가지는 질의에서만 사용

 

- 질의 클래스

    이 16비트 필드는 DNS를 사용하는 특정 프로토콜을 정의

< 자원 레코드 >

- 각 도메인 이름(트리 상의 각 노드)은 자원 레코드라는 레코드와 관계됨

- 자원 레코드들은 서버에서 클라이언트로 반환되는 것이기도 함

- 도메인 이름

    이 필드는 가변 길이를 가지며 도메인 이름을 포함

    이는 조회 레코드에 있는 도메인 이름을 복사한 것

    DNS는 이름이 반복되는 곳이면 어디든지 압축 기법의 사용을 요구하기 때문에 이 필드는 질의 레코드에 있는

    도메인 이름 필드에 대한 포인터 옵셋을 나타냄

 

- 도메인 종류

   이 필드는 질의 섹션에 있는 질의 종류 필드와 동일하나 마지막 두 종류만 허락되지 않음

 

- 도메인 클래스

   이 필드는 질의 섹션에 있는 질의 클래스 필드와 동일'

 

 

 

 

 

DNS 패킷 분석

네임 부분은 파싱 규칙에의해서 , 카운터 값이 먼저온다. 03 -> 뒤에 3바이트, 06 -> 뒤에 6바이트, 03 -> 다시 뒤에 3바이트의 문자열을 가지고 마지막에 0 나오면 끝이라는 의미

 

nslookup 으로 dns서버 접근

Wire Shark를 켜고 DNS서버에 접속해 패킷을 캡처 및 분석 해보자.

 

응답

네이버도 캡처해볼까?

네이버

응답이 3개나 온다

www이기 때문에 Authority 도메인에 체크 되어있다.

캐슁 되있으면 어솔티브가 0이 나온다.!!