ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • DNS
    네트워크 2024. 4. 7. 01:01

    Domain Name Server

    IP를 사람이 이해하기 쉬운 주소로 변환해주는 시스템입니다.

    일례로, 저는 구글 서버 IP를 모릅니다. 하지만 www.google.com  하면 접속이 된다는 것은 알 수 있습니다.

     

    기본적으로 DNS는 분산 데이터베이스로, 계층화되어 있습니다.

    UDP를 사용하는데 DNS는 가해지는 부담이 큰 시스템이라 TCP를 쓰기엔 힘들어서

    문제가 있으면 클라이언트 측이 알아서 재접속하도록 책임을 전가한다고 볼 수 있습니다.

     

    중앙 집중화를 하지 않는 이유도 부담이 커서입니다.

    현재 인터넷 구조 특징 상 DNS가 스톱되면 거의 대부분의 시스템이 정지되기에 안정성이 중요합니다.


    DNS 발전 과정

    초기: 직접 IP 입력하기

    발전: 클라이언트 컴퓨터에 파일 형태로 관리

    현재: DNS 서버


    DNS의 계층화

    Root DNS Server
    TLD Server (Top-Level Domain)
    Authoritative DNS Server (책임 DNS 서버)

     

    - 루트 DNS 서버

    최상위 계층. 밑 계층에 대한 정보를 가지고 있음

    예를 들어 .com으로 끝나는 사이트로 가고 싶으면 어느 TLD DNS 서버로 가야 하는지 알고 있음

    ICANN이 관리하고 전세계에 13개

     

    - TLD Server

    com, org, edu, uk, kr DNA server ....

    루트 바로 밑. 예를 들어 com DNS 서버는 .com으로 끝나는 도메인에 대한 정보를 가짐

     

    - Authoritative DNS Server

    기관 별 서버. 예를 들어 amazon.com에 대한 정보를 요청하면 이제 매핑되는 IP를 얻을 수 있음

    만약 KT가 부여해주었다 -> KT에서 관리


    Local DNS

    계층 구조에 속한다기 보다는, 캐시 역할로 사용(프록시)

    상위 DNS로 가면 오래 걸리는 것도 있고 상위 DNS의 부담이 큽니다.

    가고자 하는 곳에 대한 정보가 있으면 그 정보를 활용합니다.

     

    예를 들어 www.google.com  에 접근하고자 했을 때

    com Athoritative DNS로 가는 정보를 안다면 루트로 안가고

    바로 해당 TLD Server로 가게 됩니다.


    DNS 서버에 접근하는 것은 반복적인 방법과 재귀적인 방법이 있습니다.

     

    일단 두 방식 다 리퀘스트하는 호스트는 일단 로컬 DNS 서버에 접근해서 데이터를 요청합니다.

    가지고 있다면 바로 주겠지만 없다면 얻어와야 합니다.

     

    - 반복적인 방법

    밑의 과정들을 로컬 서버가 주체가 되어 해줍니다.

    1. 루트 DNS 서버에 접근해서 TLD 서버 받아오기

    2. TLD 서버에 접근해서 책임 DNS서버 받아오기

    3. 책임 DNS 서버에 접근해서 IP 받아오기

    4. 호스트에게 IP 전달

     

    - 재귀적인 방법

    1. 로컬 DNS 서버가 루트 DNS 서버에 요청

    2. 루트 DNS 서버가 TLD DNS 서버에 요청

    3. TLD DNS 서버가 책임 DNS 서버에 요청

    4. 책임 DNS 서버가 TLD DNS  서버에 IP 반환

    5. TLD DNS 서버가 루트 DNS 서버에 반환

    6. 루트 DNS 서버가 로컬 DNS 서버에 반환

    7. 로컬 DNS 서버가 호스트에게 반환

     

    둘 다 루트의 부담은 크지만 그래도 반복적인 방법이 부담이 덜하여

    반복적인 방법을 사용합니다.

     

    만약 로컬 DNS 서버가 알고 있는 정보가 있다면 중간 과정이 스킵 가능합니다.


    웹 캐시 때처럼 로컬 DNS 서버도 데이터 최신화 문제를 가집니다.

    로컬 DNS 서버는 보통 TLD 서버를 캐시하고 있는데, 시간이 지나면서 바뀔 수도 있습니다. (out-of-dated)

     

    해결책

    TTL - 캐시 정보에 문제가 있을 수도 있으니 유효 기간을 두는 것

    RFC 2136 - 업데이트 기술


    DNS records

     

    DNS는 RR(Resorce Records)를 데이터베이스에 분산 저장합니다.

     

    RR format : (name, value, type, ttl)

    -- name과 value의 매핑 --

     

    type=A : name = hostname, value = IP

    type=NS : name = domain, value = 책임 DNS 서버의 hostname

    type=CNAME : name = alias name (가짜 이름), value = 진짜 name

    type=MX : name / value = 네임과 관련된 메일 서버의 이름


    DNS 프로토콜 구조

    쿼리와 리플라이가 같은 포맷을 사용

    #은 카운터

    Identification Flags
    # Questions # Answer RRs
    # Authority RRs # Additional RRs
    Qustions (variable # of questions)
    Answers (variable # of RRs)
    Authority (variable # of RRs)
    Additional info (variable # of RRs)

    Identification: 16비트 식별자.

    Flags: 16비트 요청에 대한 정보

    - QR: query or reply

    - recursion desired

    - recursion available

    - reply is authoritative

    - 등..

    Qustions: 쿼리의 이름, 타입

    Answers: 쿼리에 대한 응답(RRs)

    Authority: 책임 서버에 대한 레코드

    Additional info: 나머지 정보


    DNS 공격

    보통 로컬 DNS 서버는 TLD 서버로 캐싱해서 루트로 갈 일은 생각보다 적기도 하고, 트래픽 필터링도 잘 됩니다.

    그래서 TLD 서버로의 공격이 자주 이루어집니다.

     

    '네트워크' 카테고리의 다른 글

    비디오 스트리밍과 CDNs  (0) 2024.04.08
    P2P 아키텍처 File Distribution  (0) 2024.04.08
    SMTP, MIME  (0) 2024.04.06
    쿠키, 웹 캐시(프록시)  (0) 2024.04.06
    HTTP 프로토콜 구조  (0) 2024.03.25
Designed by Tistory.