DNS

이 글은 고재성, 이상훈 저 - "IT 엔지니어를 위한 네트워크 입문"를 공부하고 정리하여 작성하였습니다.

 

1. DNS 소개

• 사용자가 도메인 주소를 사용하여 서비스를 요청
• 네트워크 설정에 입력한 DNS로 해당 도메인에 대한 IP 주소 질의를 보냄
• DNS 서버는 결괏값으로 요청한 도메인의 서비스 IP주소를 알려줌

 

2. DNS 구조와 명명 규칙

• 도메인은 역트리 구조로 최상위 루트, Top-Level 도메인, Second-Level 도메인, Third-Level 도메인과 같이 하위 레벨로 원하는 주소를 단계적으로 찾음
• 도메인 계층은 최대 128계층까지 구성할 수 있고 계층별 길이는 최대 63바이트이다.
• “.”를 포함한 전체 도메인 네임의 길이는 최대 255바이트

2.1. 루트 도메인

1. 도메인을 구성하는 최상위 영역
2. DNS 서버는 사용자가 쿼리한 도메인에 대한 값을 직접 갖고 있거나 캐시에 저장된 정보를 이용해 응답
3. 만약 DNS 서버에 해당 도메인 정보가 없으면 루트 도메인을 관리하는 루트 DNS에 쿼리하게 됨
4. 전 세계에 13개가 있고 DNS 서버를 설치하면 루트 DNS의 IP 주소를 기록한 힌트 파일이 있음

2.2. Top-Level 도메인

• IANA(Internet Assinged Numbers Authority)에서 구분한 6가지 유형으로 구분
  
  1. Generic(gTLD)
     • 일반적인 최상위 도메인이며 세 글자 이상으로 구성
       

       gTLD	설명
       com	일반 기업체
       edu	4년제 이상 교육기관
       gov	미국 연방정부기관
       int	국제기구, 기관
       mil	미국 연방군사기관
       net	네트워크 관련 기관
       org	비영리기관

  2. country-code(ccTLD)
     • 국가 최상위 도메인, 두 글자의 국가 코드 사용, ex) kr(대한민국)
     • ccTLD를 사용한 경우 Second Level TLD 에선 gTLD처럼 사이트 용도에 따른 코드 사용
  3. sponsored(sTLD)
     • 특정 목적을 위한 스폰서를 두고 있는 최상위 도메인, ex) ‘.aero’, ‘.asia’, ‘.edu’,’.museum’ 등
  4. infrastructure
     • 운용상 중요한 인프라 식별자 공간을 지원하기 위해 전용으로 사용되는 최상위 도메인
     • ‘.arpa’: 인터넷 안정성을 유지하기 위해 새로운 모든 인프라 하위 도메인이 배치될 도메인 공간 역할
  5. generic-restricted(grTLD)
     • 특정 기준을 충족하는 사람이나 단체가 사용할 수 있는 최상위 도메인 ex) ‘.biz’, ‘.name’, ‘.pro’
  6. test(tTLD)
     • IDN(Internationalized Domain Names) 개발 프로세스에서 테스트 목적으로 사용하는 최상위 도메인 ex) ‘.test’

 

3. DNS 동작 방식

• 도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 함
• DNS 서버 없이도 로컬에 도메인과 IP 주소를 직접 설정해 사용할 수도 있음
• hosts 파일에 도메인과 IP 주소를 설정해두면 해당 도메인 리스트는 항상 DNS 캐시에 저장됨
• ※ hosts 파일: 로컬에서 도메인과 IP 주소를 관리하는 파일

3.1. 클라이언트 관점의 DNS 질의 과정

1. 도메인을 쿼리하면 DNS 서버에 쿼리를 하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인
   • 캐시를 통해 성능을 향상하기 위함
   • DNS 캐시 정보에는 기존 DNS 조회를 통해 확인한 DNS 캐시와 함께 hosts 파일에 저장되어 있는 정적 DNS 캐시가 함께 저장
2. DNS 캐시 정보에 필요한 도메인 정보가 없으면 DNS 서버로 쿼리를 수행
3. DNS 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장

• Windows 에서 DNS 캐시를 확인하려면 ipconfig /displaydns 실행

3.2. DNS 시스템 관점에서의 결과값 응답 과정

• DNS는 워낙 방대하기 때문에 분산된 데이터베이스로 서로 도와주도록 설계
• 자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받을 수 있음
• 재귀적 쿼리: 쿼리를 보낸 클라이언트에 서버가 최종 결괏값을 반환하는 서버 중심의 쿼리
• 반복적 쿼리: 최종값을 받을 때까지 클라이언트에서 쿼리를 계속 진행하는 방식

1. 사용자 호스트는 ‘zigispce.net’이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어 있는지 확인
2. ‘zigispce.net’이 로컬 캐시에 저장되어 있이 않으면 사용자 호스트에 설정된 DNS에 ‘zigispce.net’에 대해 쿼리
3. DNS 서버는 ‘zigispce.net’이 로컬 캐시와 자체에 설정되어 있는지 직접 확인하고 없으면 해당 도메인을 찾기 위해 루트 NS에 .net에 대한 TLD 정보를 가진 도메인 주소에 쿼리
4. 루트 DNS는 ‘zigispce.net’의 TLDdls ‘.net’을 관리하는 TLD 네임 서버 정보를 DNS 서버에 응답
5. DNS는 TLD 네임 서버에 ‘zigispce.net’에 대한 정보를 다시 쿼리함
6. TLD 네임 서버는 ‘zigispce.net’에 대한 정보를 가진 zigi 네임 서버에 대한 정보를 DNS 서버로 응답
7. DNS는 zigi 네임 서버에 ‘zigispce.net’에 대한 정보를 쿼리
8. zigi 네임 서버는 ‘zigispce.net’에 대한 정보를 DNS 응답함.
9. DNS는 ‘zigispce.net’에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 ‘zigispce.net’에 대한 정보를 응답
10. 사용자 호스트는 DNS로부터 받은 ‘zigispce.net’에 대한 IP 정보를 이용해 사이트에 접속

 

4. 마스터와 슬레이브

• 마스터와 슬레이브는 도메인에 대한 존(zone) 파일을 직접 관리하는지 여부로 구분
• 마스터 서버는 존 파일을 직접 생성해 도메인 관련 정보를 관리
• 슬레이브 서버는 마스터에서 만들어진 존 파일을 복제
• 이 과정을 영역 전송(Zone Transfer) 과정이라 함
• 도메인 영역 전송을 위해 슬레이브 서버를 만들 때 도메인을 복제해올 마스터 서버 정보를 입력해야 함
• 마스터 서버는 자신이 가진 도메인 정보를 받을 슬레이브 서버를 지정해 제한할 수 있음
• 마스터-슬레이브는 이중화에서 일반적으로 사용하는 액티브-스탠바이나 액티브-액티브 형태로 구성하지 않음
• DNS 서버는 마스터 서버에 문제가 생기면 슬레이브 서버도 도메인에 대한 질의를 응답할 수 없음
• 따라서 만료 시간 안에 마스터 서버를 복구하거나 슬레이브 서버를 마스터 서버로 전환해야 함

마스터와 슬레이브는 도메인 별로 설정 가능하지만
마스터 서버는 모든 도메인에 대해 마스터로 설정하고
슬레이브 서버는 모두 슬레이브로 설정하는 것이 바람직함

액티브-스탠바이와 액티브-액티브

네트워크 서비스나 시스템 내부의 컴포넌트 일부가 정상적으로 동작하지 않더라도 서비스가 지속될 수 있도록 고가용성 기술을 사용함.

• 액티브-액티브: 두 개의 노드가 동시에 서비스를 제공하고 한 노드가 문제가 발생하면 다른 노드에서 서비스를 계속 제공
• 액티브-스탠바이: 두 개의 노드 중 액티브 노드만 서비스를 제공하고 스탠바이 노드는 대기하다 한쪽에 문제가 생기면 서비스를 시작

 

2.5. DNS 주요 레코드

• 도메인에는 다양한 내용을 매핑할 수 있는 레코드가 있음

레코드 종류	내용
A(IPv4)	도메인 주소를 IP 주소로(IPv4)로 매핑 (일대일, 다대일)
AAAA(IPv6)	도메인 주소를 IP 주소로(IPv6)로 매핑
CNAME(Canonical Name)	도메인 주소에 대한 별칭
SOA(Start Of Authority)	본 영역 데이터에 대한 권한
NS(Name Server)	본 영역에 대한 네임 서버
MX(Mail eXchange)	도메인에 대한 메일 서버 정보
PTR(Pointer)	IP 주소를 도메인에 매핑(역방향)
TXT(TeXT)	도메인에 대한 일반 텍스트

 

2.6. DNS에서 알아두면 좋은 내용

1. 도메인 위임
   

   

   
   
   • 도메인은 그 도메인에 대한 정보를 관리할 수 있는 네임 서버를 지정
   • 도메인 내의 모든 레코드는 그 네임 서버가 직접 관리하지 않고 일부에 대해 다른 곳에서 레코드를 관리하도록 위임
   • CDN을 이용하거나 GSLB를 사용하는 것이 대표적인 경우
   • 도메인은 특정 계층의 레코드를 위임하면 해당 레코드의 하위 계층은 함께 위임처리됨.
2. TTL
   1. DNS에 질의해 응답받은 결괏값을 캐시에서 유지하는 시간
   2. 로컬 캐시에 저장된 도메인 정보를 TTL 값에 따라 그 시간만 로컬 캐시에 저장
   3. 기본 TTL 값: 3,600(윈도), 10,800(리눅스)
   기타 도메인 관련 시간
   • refresh(새로 고침 간격): 보조 네임 서버에서 Zone Transfer를 통해 정보를 주기적으로 받아오는 주기
   • retry(다시 시도 간격): 보조 네임 서버가 주 네임 서버로 접근이 불가할 때 재시도하는 주기
   • expire(다음 날짜 이후 만료): 보조 네임 서버가 주 네임 서버로부터 도메인 정보를 받아오지 못할 때 유지되는 시간
    
3. 화이트 도메인
   • 사전에 등록된 개인이나 사업자에 한해 국내 주요 포털 사이트 이메일 전송을 보장해주는 제도
   • 정상적으로 발송하는 대량 이메일이 RBL 이력으로 간주되어 차단되는 것을 예방
   • 반대로 불법적인 스펨메일 사이트는 실시간 블랙리스트 정보로 관리해 메일 발송 제한
   • KISA RBL 사이트에 화이트 도메인으로 등록해야 하며 SPF 레코드가 설정되어야 함.
   • SPF 레코드를 작성하려면 TXT 레코드를 사용함
4. 한글 도메인
   • 한글로 주소를 만들 수 있음
   • DNS에서는 해당 한글을 “퓨니 코드”로 변경하고 이것으로 DNS에 도메인을 생성해야 함
   ※ 퓨니코드: 애플리케이션 국제화 도메인 네임 기반 하에서 다국어 도메인이 아스키로 변환된 구문

 

2.7. 호스트 파일 설정

• 도메인과 IP 주소를 매핑해놓은 hosts 파일을 이용해 도메인-IP 주소 쿼리를 사용할 수 있음
• DNS 기능 이전부터 사용한 방식이며 테스트 목적 등으로 특정 도메인에 대해 설정한 값으로 접속할 때 사용할 수 있음
• hosts 파일 설정 도메인 정보가 DNS에 의한 질의보다 우선순위가 높음

DNS 의 시작

• DNS가 없던 ARPANET 시절에서는 ARPANET에 있는 컴퓨터의 IP 주소와 호스트를 매핑한 hosts.txt를 사용
• 시간이 지나고 인터넷이 커지면서 텍스트 파일로는 한계가 왔고 이를 해결하기 위해 1983년 11월 RFC 882와 883을 통해 DNS 스펙이 발표됨
• 이듬해인 1984년 그 스펙을 기준으로 앞에서 소개한 BIND가 만들어짐
• 이후 스펙이 지속적으로 추가되면서 현재의 모습을 갖춤

 

자료

• IT 엔지니어를 위한 네트워크 입문 (고재성, 이상훈 저, 2020.10)