1. 도메인 서비스 (https://www.notion.so/15-DNS-1-b7035f64538d45a8b0f01190ca6d7268)
2. DNS 데이터베이스(https://naon.me/posts/til132)
3. 네임 서버(나)
4. DNS 프로토콜(나)

1. 네임서버

학습목표

• 도메인 관리를 위한 해석기와 네임 서버의 동작 원리 이해

변환 과정

• 응용 프로그램이 해석기라고 부르는 DNS 클라이언트에게 정보 제공 요청
• 해석기(resolver)
  • 해석기가 DNS 메세지 형식의 질의를 생성
  • 이 질의를 네임 서버에게 전달
  • 네임 서버는 회신용 DNS 메세지에 결과를 담아 해석기에 회신
• 네임 서버의 부담을 줄이기 위하여 캐시 정보 활용
  • 인증(authoritative) 데이터
    • 해당 데이터를 직접 관리할 책임이 있는 네임 서버로부터 받은 정보
  • 캐시 데이터
    • 이전 요청에 의하여 호스트가 보관하던 정보
      -TTL(Time to Live)동안 유효, 이 시간을 넘어가면 캐시 정보 삭제

존(zone)

• 존은 자원 레코드에 포함된 인증 데이터의 집합체로 정의됨
• 관리하는 정보
  • 존에 속하는 모든 호스트의 전체 자원 레코드 집합체
  • 존에 포함된 최상위 호스트
  • 위임 서브 존
    • 자신의 존에 속하지만 인증이 위임된 경우
  • 위임된 서버 존에 관한 글루(glue) 데이터
    • 서브 존의 네임 서버에 접근할 수 있도록 해줌
• test.info.mit.edu의 호스트정보를 얻고자 하는 경우
  • info.mit.edu를 관리하는 네임 서버의 ip 주소를 알면 간단히 처리
  • info.mit.edu의 네임 서버가 서브존 도메인 내부에 위치하여 ip 주소를 얻기 곤란한 경우에 글루 데이터가 필요

요청의 처리

• 호스트 a가 호스트 b의 정보를 원할 때, 호스트 a,b가
  • 같은 도메인에 위치하면 이 도메인의 네임 서버가 인증 데이터를 회신
  • 다른 도메인에 위치하면 인근 네임 서버에게 요청호스트 a를 중개해줌
• 인근 네임 서버를 찾는 작업은 인증 정보를 찾을 때까지 반복됨
• 질의 요청이 처리되는 과정(에서 꼭 명시해줘야 할 두가지)
  • 인증 데이터가 반드시 필요한지, 혹은 캐쉬 데이터로 충분한지 명시
  • 해석기는 질의 요청을 재귀적으로 처리해야 하는지 혹은 비재귀적으로 처리해야 하는지 명시

재귀적 요청

• 해석기가 최초로 접속을 시도한 네임 서버가 질의 요청을 추적, 관리
• 재귀적 요청을 받은 네임 서버가 결과적으로 해석기 역할을 수행
  (처음 요청 보낸 네임 서버가 나에게 결과를 알려주는 방식)

비재귀적

• 요청을 받은 네임 서버가 다른 네임 서버의 포인터 정보를 회신
• 이를 받은 해석기는 다른 네임서버에게 다시 질의
  (처음 요청 보낸 네임서버가 자기도 모르니 여기 가서 찾아봐라 하면서 다른 네임 서버 주소 알려주는 방식)

2. DNS 프로토콜

학습목표

DNS 클라이언트와 서버 간 전송되는 DNS 메세지 이해

DNS 메세지

메세지 구성

• Header
  • 12 바이트
  • 헤더 값에 따라 메시지 각 필드의 사용 결정
• Question
  • 질의 메세지, 응답 메세지에서 모두 사용
  • 질의 레코드
• Answer, Authority, Additional
  • 자원 레코드 사용
    

DNS 헤더

• Identification
  • 요청과 응답의 연관 관계 확인 용도
• QR(Query Response)
  • 질의 메세지(0)
  • 응답 메세지(1)
• OPCODE
  • 질의나 응답의 종류
  • 표준(0), 반대(1), 서버 상태 요청(2)
• AA (Authoritative Answer)
  • 인증 권한이 있는 네임 서버 여부(응답 전용)
• TC (Truncated)
  • UDP 최대 크기 초과 여부
  • 1로 설정되면 초과된 것이므로 TCP로 재요청 필요
• RD (Recursive Desired)
  • 재귀적 응답 요청(질의 전용)
• RA(Recursion Available)
  • 재귀 응답 가능 여부(응답 전용)
• RCODE
  • 0이면 정상, 그 외 응답 오류
    -QCOUNT, ANCOUNT, AUCOUNT, ARCOUNT
  • 각 자원 레코드 갯수
    

UDP 패킷 크기로 인한 제약

• 해석기와 네임 서버는 기본적으로 UDP 53번 포트로 DNS메시지 전송
• UDP 프로토콜의 최대 전송 크기: 512바이트
• TCP 53번 포트를 사용하는 경우
  • 미리 512 바이트보다 크다는 것을 인지하는 경우에는 처음부터 TCP 사용
  • 사전에 인지하지 못한 경우 TC=1로 지정되므로, TCP 연결을 사용하여 재질의
    -IPV4의 경우 UPD 사용이 일반적이나, 주소 크기가 늘어나고 기본적으로 복수 개의 주소를 가질수 있는 IPv6, 보안이 강화된 DNSSEC의 경우 UDP 크기 제한을 넘어갈 수 있음. -> TCP를 사용할 수 밖에 없는 상황

DNS 프로토콜의 동작 과정

요청 메세지

응답 메세지

• identification은 질의와 같아야 함.