목차
2.4 DNS: 인터넷의 디렉터리 서비스 112
2.4.1 DNS가제공하는서비스 112
2.4.2 DNS 동작 원리개요 115
2.4.3 DNS 레코드와메시지 120

📖 2.4 DNS： 인터넷의 디렉터리 서비스

• 호스트 이름 : 호스트의 식별자
  • 인터넷에서의 그 호스트 위치에 대한 정보 제공 X
  • 가변 길이의 알파뉴메릭 문자로 구성 -> 라우터가 처리하는 데 어려움
• IP 주소(IP address) : 호스트의 식별자
  • 4바이트 구성
  • 계층구조 -> 주소를 왼쪽에서 오른쪽으로 조사 -> 호스트가 인터넷의 어디에 위치하는지 정보O
  • 0〜255의 십진수로 표현하는 각 바이트는 점으로 구분
  • ex) 121.7.106.83

☝🏻 2.4.1 DNS가 제공하는서비스

호스트 이름 : 사람이 보기 좋음 VS IP 주소 : 라우터가 보기 좋음
둘이 원만한 합의좀 -> DNS

• DNS(domain name system) : 호스트 이름을 IP 주소로 변환해주는 디렉터리 서비스
  • DNS 서버들의 계충구조로 구현된 분산 데이터베이스
    • BIND(Berkeley Internet Name Domain) 소프트웨어를 수행하는 유닉스 컴퓨터
  • 호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜
    • UDP상에서 수행, 포트 번호 53을 이용
  • 동작과정
    • 사용자가 URL: www.someschool.edu/index.html을 요청할 때
    1. 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행한다.
    2. 브라우저 -> DNS 애플리케이션의 클라이언트 한테 www.someschool.edu(호스트이름) 을 넘김
    3. DNS 클라이언트 -> DNS 서버로 호스트 이름 질의 전송
    4. DNS 서버 -> DNS 클라이언트 : 호스트 이름에 대한 IP 주소를 가진 응답 수신
    5. DNS 클라이언트 -> 브라우저: 해당 IP 주소 응답 수신
       • 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결
  • => 추가 지연 but 원하는 IP 주소는 가까운 DNS 서버에 캐싱->평균 DNS 지연+DNS 네트워크 트래픽↘

추가서비스

• 호스트 에일리어싱: 복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질수 있도록 지원
  • ex) 정식 호스트 이름 : relayl.west-coast.enterprise.com
    별칭 호스트 이름 : enterprise.com 와 www.enterprise.com
• 메일 서버 에일리어싱: 기억하기 쉬운 전자메일 주소
  • ex) 사용자 이메일 : bob@hotmail.com
    but 핫메일 서버의 정식 호스트 이름은 더 복잡(relayl.west-coast.hotmail.com)
  • MX 레코드 : 기업의 메일 서버와 웹 서버가 같은 호스트 이름(별칭)을 가져도 OK
• 부하 분산(load distribution)： 중복 (웹)서버 사이에 부하 분산
  • 인기사이트=여러 서버에 중복=각 서버가 다른 종단 시스템에서 수행됨
    => 정식 호스트 이름과 연관된 각기 다른 IP 주소를 가짐
  • ㄴ DNS 데이터베이스는 이러한 IP 주소 집합을 가짐
  • 클라이언트가 호스트 이름(주소집합에 매핑된)에 대한 DNS 질의 -> DNS 서버는 IP 주소들 전체를 가지고 응답, 이때 각 응답에서의 주소는 순환식으로 전송
    => DNS의 순환 방식

    • 클라이언트는 대체로 주소 집합 내부의 첫 번째 IP 주소로 HTTP 요청 메시지 전송

      이게 뭔소린가 싶은데 그냥 IP주소 돌아가며 균등히 나눠쓰는 느낌~ 원형큐처럼 ㅋㅋ

    • 여러 중복 서버들 사이에서 트래픽을 분산하는 효과

    • ex) 전자메일에서 사용되어 여러 메일 서버가 동일한 별칭을 가질 수 있음

      
      

🔎 2.4.2 DNS 동작 원리 개요

호스트 이름-> IP 변환 동작 과정
1. 어플리케이션 -> DNS 측의 클라이언트를 호출(gethostbyname()) with 호스트 이름
2. 사용자의 DNS -> 네트워크 : 질의 메시지 전송
- 모든 DNS 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내짐
- 수 밀리초에서 수 초의지연
3. 사용자(host)의 DNS는 DNS 응답 메시지(IP주소) 수신
4. 사용자의 DNS -> 애플리케이션으로 전달

• 애플리케이션 관점에서 DNS는 간단하고 직접적인 변환 서비스를 제공하는 블랙박스
  => 애플리케이션 계층 프로토콜 : 전 세계에 분산된 많은 DNS 서버 + 질의하는 호스트 사이의 통신법
• if 계층 구조(분산 구조)가 아닌 only one 인터넷 네임 서버라면? => 확장성이 없음
  • 서버 고장 : 전체 인터넷 안됨
  • 트래픽 양 : 졸라 많음
  • 먼 거리의 중앙 집중 데이터 베이스 : 졸라 멀수도 = 졸라 큰 지연
  • 유지 관리 : ㅈ됨
  • 따라서 확장성을 위해 아래와 같은 분산(계층) 구조를 가짐

분산 계층 데이터베이스

• 루트 DNS 서버
  • 1000개 이상의 루트 서버 인스턴스
  • 루트 서버들은 13개의 다른 루트 서버 복사체이고, 12개의 다른기관에서 관리
  • 인터넷 할당 번호 관리기관[IANA 2020】에 의해 조정
  • 기관, 주소 목록 보기 : [Root Servers 2020]
  • 루트 네임 서버는 TLD 서버의 IP 주소들을 제공
• 최상위 레벨 도메인(TLD) 서버
  • com, org, net, edu, gov 같은 상위 레벨 도메인 + kr, uk, fr, cajp 같은 모든 국가의 상위 레벨 도메인
  • TLD를 지원하는 네트워크 인프라는 크고 복잡
  • TLD 서버는 책임 DNS 서버에 대한 IP 주소를 제공
• 책임 DNS 서버
  • 서버 호스트를 가진 기관의 책임 DNS : 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공
  • 기관은 책임 DNS 서버의 구현 or 서비스 제공자의 책임 DNS 서버에 이 레코드를 저장하고, 비용 지불
  • ex) 대학, 기업 : 자신의 기본 책임 DNS 서버와 보조 책임 DNS 서버를 유지하고 구현

• +) 로컬DNS 서버
  - 서버는 서버들의 계층 구조에 엄격하게 속하지는 X but DNS의 구조 중심
  - ISP들은 로컬 DNS 서버를 가짐
  - 호스트가 ISP에 연결될 때，그 ISP는 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공(DHCP)
  - 호스트의 로컬 DNS 서버는 대체로 호스트에 ‘가까이’ 있음.
  - 호스트 DNS 질의 -> 프록시(캐싱인듯)로 동작하는 로컬 DNS 서버 -> DNS 서버 계층으로 전달

  잠꺈! :저~위에 2.4.1 DNS 설명하면서 알려준 동작과정의 DNS 어플리케이션 클라이언트랑 비교
  - DNS 어플리케이션 클라이언트 : 사용자의 컴퓨터에서 실행되는 소프트웨어로, 도메인 이름을 IP 주소로 변환하기 위해 로컬 DNS 서버와 통신
  - 로컬 DNS 서버: 네트워크나 ISP에서 운영되며, 클라이언트의 DNS 쿼리를 처리하고, 도메인 이름에 대한 정보를 캐시하여 빠르게 응답

  내생각 ISP = 통신사라고 보면 통신사애들이 우리 컴퓨터 인터넷 심어주자나. 우린 통신사업스면 응애. 통신사애들이 잘쓰는 호스트이름이랑 ip 주소 매핑을 가지고 있으면=프록시=캐싱 우리같은애들(호스트)가 응애 하면 주는거지 ㅎㅎ

• 동작 과정(재귀적 질의 + 반복적 질의)
  : TLD 서버는 호스트 이름에 대한 책임 서버를 알때 과정

  • 가정 : 호스트(cse.nyu.edu) gaia. cs . umass . edu의IP 주소 원함,
    • cse. nyu. edu에 대한 NYU의 로컬 DNS 서버 = dns.nyu.edu
    • gaia.cs.umass.edu에 대한 책임 DNS 서버 = dns.umass.edu
  • 동작 과정
  1. 호스트(cse.nyu.edu) -> 로컬 DNS 서버(dns.nyu.edu) With DNS 질의 메시지( gaia.cs.umass.edu 포함)
  2. 로컬 DNS 서버 -> 루트 DNS 서버로 전달 With DNS 질의 메시지
  3. 루트 DNS 서버 -> 로컬 DNS 서버로 전송 With edu의 책임을 가진 TLD 서버의 IP 주소 목록 응답
  4. 로컬 DNS 서버 -> TLD 서버 With 질의 메세지
  5. TLD 서버 -> 로컬 DNS 서버 With 매사추세츠대학교(dns.umass.edu)의 책임 DNS 서버 IP 주소 응답
  6. 로컬 DNS 서버 -> 책임 DNS 서버(dns.umass.edu) With 질의 메시지
  7. 책임 DNS 서버 -> 로컬 DNS 서버 With gaia.cs.uniass.edu의 IP 주소로 응답
  8. 로컬 DNS 서버 -> 호스트 With 매핑 결과 응답
  • 하나의 호스트 이름 매핑을 얻기 위해 질의 메시지 4 + 응답 메시지 4 = 총 8번 DNS 메시지
  • 

• +) 재귀적 질의 : 자신을 대신하여 필요한 매핑을 얻도록 요구 (ex - 호스트 -> DNS 서버)
• +) 반복적 질의 : 응답 직접 받음 (위 예에서 DNS가 응답받는 모든 질의)
• 위 예에서 TLD 서버는 호스트 이름에 대한 책임 서버를 안다고 가정했지만 일반적으론 X
  • +) 동작 과정(only 재귀적 질의)
    : TLD 서버가 호스트 이름에 대한 책임 서버를 모를때 (but 책임 DNS를 아는 중간 DNS 서버를 알때)
    • 가정: 매사추세츠대학교의 각 학과도 자신의 DNS 서버를 갖고 있고，각 학과 DNS 서버가 학과 안의 모든 호스트를 책임진다고 가정 (위의 6번 과정부터 변경(7의 응답 변경,8,9 추가됨)
    • 동작과정
    7. 중간(책임) DNS 서버(dns.umass.edu) -> 로컬 DNS 서버(dns.nyu.edu) with dns.cs.umass.edu의 IP 주소 응답
    8. 로컬 DNS 서버(dns.nyu.edu) -> 책임 DNS 서버(dns.cs.umass.edu) with 질의
    9. 책임 DNS 서버(dns.cs.umass.edu) -> 로컬 DNS 서버 with 응답
    10. 로컬 DNS 서버 -> 호스트 with 매핑 결과 응답
  • 이 경우에 전체 8(원래)+2(추가) = 10번의 메시지를 보내게 된다.
  • 아래 그림의 질의는 모두 재귀적 질의
    
    

DNS 캐싱

• DNS는 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱을 사용

• DNS 서버가 DNS 응답을 받았을 때, 로컬 메모리에 저장할 수 있다.

  • if 같은 질의가 오면，DNS 서버는 호스트 이름에 대한 책임이 없어도 원하는 IP주소를 제공 가능
  • 호스트 DNS-IP 매핑과 호스트는 영구적X->DNS 서버는 어떤 기간(보통 2일) 후에 정보 제거
  • 로컬 DNS 서버도 TLD 서버의 IP 주소 저장->로컬 DNS 서버가 질의체인에서 루트 DNS서버 우회
  
  

📄 2.4.3 DNS 레코드와 메시지

DNS 레코드

• dns서버들(DN분산데이터베이스의)은 호스트 이름->IP 주소 매핑을 위한 자원 레코드 저장하고 응답
• 자원 레코드는 4개의 튜플로 구성 : (Name, Value, Type, TTL)
  • TTL(time to live)은 자원 레코드의 생존기간(자원이 캐시에서 제거되는 시간)
  • Name과 Value의 의미는Type에 따름(아래 예시에서 TTL 무시)
  • Type=A
    • Name = 호스트 이름
    • Value = 호스트 이름에 대한 IP 주소
    • 표준 호스트 이름의 IP 주소 매핑을 제공
    • ex) (relayl.bar.foo.com, 145.37.93.126, A)
  • Type=NS
    • Name = 도메인(예: foo.com)
    • Value = 도메인 내부 호스트의 IP 주소를 얻을 방법을 아는 책임 DNS 서버의 호스트 이름
    • ex) (foo.com, dns.foo.com, NS)
  • Type=CNAME
    • Name = 별칭 호스트 이름
    • Value = 별칭 호스트 이름(Name)에 대한 정식 호스트 이름
    • 질의 호스트에게 호스트 이름에 대한 정식 이름을 제공
    • ex) (foo.com, relayl.bar. foo.com, CNAME)
  • Type=MX
    • Name = 별칭 호스트 이름
    • Value = 별칭 호스트 이름(Name)을 갖는 메일 서버의 정식 이름
    • ex) (foo.com, mail.bar.foo.comz MX)
    • MX 레코드는 메일 서버의 호스트 이름이 간단한 별칭을 갖는 것을 허용
    • 어떤 회사는 한 메일 서버와 다른 서버들(웹 서버 같은 것)이 같은 별칭을 가질 수 oo
    1. 메일 서버의 정식 이름을 얻기 위해 DNS 클라이언트는 MX 레코드에 대한 질의
    2. 다른 서버의 정식 이름을 얻기 위해 DNS 클라이언트는 CNAME 레코드에 대한 질의
• 책임 DNS 서버는 그 호스트 이름에 대한 Type A 레코드를 포함(책임 서버아니여도 캐시에 포함 가능)
• 책임 DNS 서버가 아니라면，호스트 이름을 포함하는 도메인에 대한 Type NS 레코드 포함
  + NS 레코드의 Value 필드에 DNS 서버의 IP 주소를 제공하는 Type A 레코드 포함
  • ex) 호스트(gaia.cs.umass.edu)에 대해 책임 서버가 아닌 TLD 서버를 가정
    TLD 서버는 호스트 gaia.cs.umass.edu를 포함하는 도메인에 대한 레코드 포함
    (umass.edu, dns.umass.edu, NS)
    +) DNS서버(dns.umass .edu) - IP주소로 매핑하는 A Type 레코드 포함
    (dns.umass.edu, 128.119.40.111，A)
    
    

DNS 메시지

• DNS 질의와 응답 메시지는 같은 포맷을 가짐
• 헤더 영역
  • 처음 12 byte
  • 식별자 필드
    • 첫 필드, 질의를 식별하는 16비트 숫자
    • 질의에 대한 응답 메시지에 복사->클라이언트가 보낸 질의와 수신된 응답 간의 일치 식별
  • 플래그 필드
    • 여러 개의 플래그
    • 1 비트의 질의/응답 플래그 : 메시지가 질의(0)인지 응답(1)인지 구별
    • 1 비트의 책임 플래그 : 질의 이름에 대해 책임 서버일 때 응답 메시지에 설정
    • 1 비트의 재귀 요구 플래그 : 레코드가 없으면, 재귀적 질의를 요청하는 쪽이 원할 때 설정
  • 1 비트로 된 재귀 가능 필드 : 재귀 질의를 지원하면 응답에 설정 됨.
  • 4개의 ‘개수’ 필드
    • 헤더 다음에 오는 데이터 영역의 4가지 타입의 발생 횟수를 나타냄
    • 질문 영역 : 현재 질의에 대한 정보를 포함
      (1) 질의되는 이름을 포함하는 이름 필드
      (2) 이름에 대해 문의되는 질문 타입을 나타내는타입 필드 포함
      • 이름과 연관된 호스트 주소(A 타입) or 이름에 대한 메일 서버(MX 타입) 등
    • 답변 영역 : 원래 질의된 이름에 대한 자원 레코드를 포함
      • 응답으로 여러 개의 자원레코드(RR) 전송 가능
      • 호스트 이름은 여러 개의 IP 주소를 가질 수 있기 때문에 (ex 중복된 웹 서버)
    • 책임 영역 : 다른 책임 서버의 레코드를 포함
    • 추가 영역 : 다른 도움이 되는 레코드를 포함
      • ex) MX응답에서 응답 필드는 전자메일 서버의 정식 호스트 이름을 제공하는 자원 레코드를 가짐.
        추가 영역은 메일 서버의 정식 호스트 이름의 IP주소를 제공하는 Type A 레코드를 포함

• nslookup 프로그램 : 윈도우와 유닉스에서 DNS 질의 메시지가 호스트로부터 DNS 서버로 보내는 과정을 확인 가능

DNS 데이터베이스에 레코드 삽입
레코드를 데이터베이스에 삽입하는 동작 과정

• '네트워크 유토피아'라는 새로운 벤처 기업을 설립했다고 가정
  1. 도메인 네임(networkutopia. com)을 등록기관에 등록

  • 이때 등록기관에 주책임 서버+부책임 서버의 이름과 IP 주소를 제공
  • dnsl.networkutopia.com, dns2.networkutopia.com, 212.212.212.1, 212.212.212.2 이라 가정
  • 등록기관(registrar): 도메인 네임의 유일성을 확인하고 DNS DB에 삽입한 후, 서비스에 대한 약간의 비용을 받는 상업기관
    +) ICANN(Intemet Corporation for Assigned Names and Numbers) : 이러한 등록기관을 승인

  2. 등록기관은 받은 두 책임 DNS 서버 각각에 대해 Type NS와 Type A 레코드가 TLD com 서버에 등록되도록 확인

  • 주책임 서버의 경우，등록기관은 다음 2개의 자원 레코드를 DNS 시스템에 삽입
    (networkutopia.com, dns1.networkutopia.com, NS)
    (dns1.networkutopia.com, 212.212.212.1, A)

  3. 기업은 아래 2개의 레코드가 기업의 책임 DNS서버에 등록되는 것을 확인

  1. 웹 서버(www.networkutopia.com)에 대한 Type A 자원 레코드와
  2. 메일 서버(mail.networkutopia.com)에 대한 Type MX 자원 레코드

  4. 일반 사람들은 기업의 웹사이트를 방문 + 직원들에게 전자메일을 보낼 수도 있다

위 명제 확인

• 호주에 있는 앨리스가 www. networkutopia. com 웹 페이지를 보고자 한다고 가정

  1. 엘리스의 호스트 -> 로컬 DNS 서버 with DNS 질의
  2. 로컬 DNS 서버 -> TLD com 서버 with DNS 질의

  • (if 로컬 DNS 서버는 TLD com 스타일 서버의 주소가 캐싱되지 않았다면, 루트DNS 서버에 접속)

  3. TLD com 서버 -> 로컬 DNS 서버 with 두 자원 레코드를 포함하는 응답

  • 등록기관이 모든 TLD com 서버에 위에 나열된 Type NS와 코드를 삽입했기에

  4. 로컬 DNS 서버 -> 212.212.212.1 with DNS 질의

  • 호스트이름(www.networkutopia.com)에 대응되는 Type A 레코드를 요구하는 DNS 질의

  5. 212.212.212.1 -> 로컬 DNS 서버 with 레코드 응답(요구하는 웹 서버(212.212.71.4의 IP 주소)
  6. 로컬 DNS 서버 -> 앨리스 호스트 with 매핑 결과(레코드 전달)
  7. 앨리스의 브라우저는 212.212.71.4 호스트로 TCP 연결을 초기화 -> HTTP 요청

보안 초점 - DNS 취약점

• DDoS 대역폭 플러딩(flooding) 공격
  • ex) 다량의 패킷을 각 DNS 루트 서버로 보냄 -> 정상적인 DNS 질의들이 응답을 받을 수 X
  • 보안법
    1. DNS 루트 서버로 향하는 모든 ICMP 핑 메시지를 블록하도록 형상화한 패킷 필터로 보호
  2. 대부분의 로컬 DNS 서버들은 최상위 도메인 서버들의 IP 주소를 캐싱
     => 질의 과정에서 DNS 루트 서버를 자주 거치지 않음
• 더 효과적인 DDos 공격
  • ex) .com 도메인을 다루는 모든 최상위 도메인 서버들에게 다량의 DNS 질의를 보내는 것
    • DNS 서버로 향하는 DNS 질의들을 필터링하기가 더욱 어려움
    • 최상위 도메인 서버들은 루트 서버처럼 우회하는 것이 쉽지 않음
• 중간자 공격
  • 호스트로부터의 질의를 가로채어 가짜 응답을 반환
  • DNS 중독(poisoning)공격에서 공격자는 DNS 서버로 가짜 응답을 보내어 그 서버가 자신의 캐시에 가짜 레코드를 받아들이도록 속임수를 쓴다.
  • ex) 순진한 웹 사용자들을 공격자의 웹사이트로 유도하는 데 이용
  • 보안법
    • DNS 보안 확장(DNS Security Extensions,DNSSEC) 프로토콜 : DNS의 보안 확장 버전