히포

• DNS 서버의 기본 동작은 클라이언트에서 질의 메시지를 받은 내용에 따라서 등록 정보를 회신하는 것
• DNS에서 도메인 네임(또는, DNS Zone)과 관련된 개별 정보 항목을 갖는 레코드
• DNS는 분산된 DNS 네임서버 내 자원 레코드의 집합

질의 메시지에는 아래와 같은 세 가지 정보가 포함

DNS RR(Resource Records) 종류

DNS 서버는 본질적으로 데이터베이스 서버의 하나 유형

• 데이터베이스 항목을 자원레코드(RR)라고 하며 아래는 예시
  

  

DNS 서버에 MX 타입 질의 예시

• IP 주소를 문의할 때는 A라는 타입을 쓰지만 메일 보낼 곳을 질의할 때는 MX(Mail eXchange)라는 타입을 사용함
• webmaster@cyber.co.kr이라는 메일 주소가 있고, 보낼 곳을 알아야 할 경우는 @ 뒤에 있는 이름이 메일을 보낼 곳이 되므로 이름을 문의
  1. 문의 내용
  2. 이름 = cyber.co.kr
  3. 클래스 = IN
  4. 타입 = MX

• DNS 서버는 10 mail.cyber.co.kr이라는 내용을 클라이언트로 회신
• 타입이 MX인 경우 회신할 항목 2가지
  1. 우선순위(10)와 메일 서버이름(mail.cyber.co.kr)
  2. mail.cyber.co.kr이라는 메일 서버의 IP 주소도 함께 회신해야 함

• 이용자의 요구에 따라 도메인 이름에 대응하는 IP 주소를 찾아내는 것을 name resolution이라고 함
• name resolution이라는 구조는 DNS의 중요한 기본 기능

1. 질의와 응답

• name resolution의 기본은 질의와 응답
• 질의와 응답을 통한 주고받는 정보를 알고 싶은 사람과 정보를 제공하는 사람 사이에서 발생
  

  

1.1. 질의와 응답에 대한 3가지 약속이 있음

1. 질의와 응답은 항상 1대 1로 대응함
   • 질의에 대응하지 않는 응답이 오거나, 한 개의 질의에 두 개의 응답이 오는 일은 없음
   • DNS에 www.foo.bar 도메인에 대한 IP 질의

2. 정보를 알고 싶은 사람은 알고 싶은 정보의 이름(도메인 이름)과 종류(타입)를 지정
   • 'www.foo.bar'의 IP 주소와 같이 이름과 종류 양쪽을 지정해야 함
   • 현재 www.foo.bar의 정보를 DNS에서 확인

3. 정보를 제공하는 사람은 받은 질의에 대해 자신이 알고 있는 정보를 응답
   • www.foo.bar에 IP는 1.2.3.5으로 질의한 클라이언트에 응답

2. name resolution의 작동

2.1. name resolution의 네 가지 포인트

1. A가 보내는 질의는 항상 같은 내용임

2. A가 보낸 질의를 받은 네임 서버는 자신이 알고 있는 정보를 응답
   • 네임 서버가 도메인 이름을 다른 네임 서버에게 위임하고 있을 때는 위임처(자식)의 네임 서버 정보를 응답함
   • 네임 서버가 도메인 이름의 정보를 가지고 있을 때는 가지고 있는 정보를 응답

3. A는 응답이 네임 서버 정보에 관한 것인지 원하는 응답인지에 따라 행동을 변경

4. 네임 서버 정보를 받았을 때, A는 정보에 적힌 네임 서버에게 질의함

2.2. name resolution의 작동 예시

1. 클라이언트가 www.foo.bar에 접속 시도
   • 클라이언트는 www.foo.bar의 IP 주소를 알 수 없기에 DNS 확인 필요

2. 루트(root) 질의 및 응답
   • A는 계층 구조의 정점인 루트의 네임서버로 알고 싶은 정보의 이름과 종류(www.foo.bar의 IP)를 질의함
   • 루트는 bar을 위임하고 있기 때문에 위임처인 bar의 네임 서버 정보(ns.bar.)를 응답

3. .bar. 질의 및 응답

   • 루트로 부터 받은 응답에서 아래 두 가지를 알 수 있음
     • 루트는 bar를 위임하고 있음
     • 위임처의 네임 서버는 ns.bar.임
   • 루트로 부터 받은 정보를 사용해 bar의 네임 서버로 이름과 종류(www.foo.bar의 IP)를 질의함
   • bar은 foo.bar을 위임하고 있기 때문에 위임처인 foo.bar의 네임 서버 정보(ns.foo.bar,)를 응답

4. foo.bar. 질의 및 응답

   • bar.로 부터 받은 응답에서 아래 두 가지를 알 수 있음
     • bar는 foo.bar를 위임하고 있음
     • 위임처의 네임 서버는 ns.foo.bar.임
   • bar.로 부터 받은 정보를 사용해 foo.bar.의 네임 서버로 이름과 종류(www.foo.bar의 IP)를 질의함
   • foo.bar 네임 서버는 www.foo.bar의 IP 주소를 알고 있기 때문에 IP 주소를 응답
   • A는 www.foo.bar의 IP 주소(1.2.3.4)를 얻을 수 있으며 name resolution이 종료됨

5. 클라이언트에 www.foo.bar의 IP 응답
   • 클라이언트는 www.foo.bar의 IP 주소(1.2.3.4)에 접속
     

     

3. name resolution을 위해 필요한 것

3.1. 부모가 응답하는 자식의 네임 서버 정보 → '위임 정보'

• 어떤 도메인에 서브 도메인을 만들고, 서브 도메인을 다른 사람에게 위임하면 위임한 쪽(부모)와 위임 받는 쪽(자식)은 부모-자식 관계가 됨
• 네임 서버가 응답하는 위임처(자식)의 네임 서버 정보를 가지고 계층 구조를 따라감
• 계층 구조를 따라갈 수 있도록 하기 위해서 위임자(부모)가 응답하는 위임처(자식)의 네임 서버 정보를 위임 정보라고 함

3.2. 위임 정보의 등록

• foo.bar(자식)은 bar(부모)에게 "foo.bar.을 관리하고 있는 'ns.foo.bar.'이라는 네임 서버를 bar.의 네임 서버에 등록해 주세요"라고 의뢰함
• 의뢰를 받아 bar은 foo.bar.의 네임 서버 정보(ns.food.bar)를 자신의 네임 서버(ns.bar)에 등록함
• bar의 네임 서버는 www.foo.bar에 대한 질의가 오면 위임 정보로서 foo.bar의 네임 서버 정보(ns.foo.bar)를 응답함 → 부모가 응답하는 위임 정보는 자식이 등록한 네임 서버 정보
• 자식이 잘못된 정보를 등록하면 부모는 잘못된 위임 정보를 응답하게 되고 name resolution를 할 수 없게 됨
• name resolution를 하는 사람이 계층 구조를 따라갈 수 있게 하기 위해서는 아래 두가지가 필요
• 자식이 부모에게 올바른 네임 서버 정보를 등록함
• 부모가 자식으로부터 받은 네임 서버 정볼르 위임 정보로서 정확하게 응답함
  
  
  

4. name resolution에서 위임의 중요성

• DNS의 name resolution는 부모가 자식에게 위임하여 만들어지는 계층 구조를 따라가는 것으로 이루어짐
• name resolution의 구조가 가져다 주는 장점

4.1. 존(zone)마다 분산 관리를 실현할 수 있음

• 계층화와 위임에 의해 관리하는 범위를 분산할 수 있음
• 계층 구조를 도입해서 각 계층의 관리를 위임함으로써 위임자(부모)는 위임처(자식)의 위임 정보만 관리하면 되고, 위임처(자식)는 자신이 위임받은 부분의 계층을 관리하면 됨
• DNS에서는 위임에 의해 관리하게 된 범위를 존(zone)이라함 → 계층화와 위임에 의해 존마다 분산 관리를 실현할 수 있음

4.2. 존(zone)을 어떻게 다룰지는 그 존의 관리자가 정할 수 있음

• 위임된 존(zone)은 위임처에서 관리함
• 각 존(zone)의 관리 정책을 각 존(zone)의 관리자가 정할 수 있음
• 예를 들면, KR존에서는 레지스트리인 KISA가 정책을 정하고 있음

• KR 정책의 예시
  • 등록자는 한국에 주소를 갖는 조직이나 개인일 것
  • 한글 도메인 이름으로 등록 가능한 라벨은 한글, 숫자, 영문자를 사용할 수 있으며 반드시 한글을 포함할 것

4.3. 어떤 존(zone)에 트러블이 발생해도 그 영향 범위를 국소화할 수 있음

• 어떤 존(zone)에 트러블이 발생했을 때, 그 존(zone)에만 영향이 미치며 다른 존(zone)에는 영향이 미치지 않음
• 예를 들면, KR의 네임 서버가 응답하지 않아 name resolution를 하지 못하게 되었을 때는 KR과 그 서브 도메인에만 영향을 미치며, KR과 같은 계층에 있는 com이나 net 그리고 그 서브 도메인에는 영향이 미지지 않음

• 한국 시간 5월 30일 오후 7시 48분(5월 30일 오전 10시 48분 GMT)이후 Comodo의 AddTrust External CA Root가 만료
• 2017년 10월 프랜시스코 파트너스(Francisco Partners)가 코모도 CA(Comodo CA)를 인수 → 2018년 11월 코모도(Comodo CA)를 섹티고(Sectigo)로 리브랜딩
• 기존 코모도 사의 루트 인증서 AddTrust External CA Root를 USERTrust RSA Certification Authority로 변경 → 기존 인증서는 2020년 5월 30일에 만료
• CA 인증서 만료가 다양한 서비스 및 시스템에 영향을 줌
• 과거 Root CA 만료 자료로 참고용 → HTTPS를 사용하는 고객에 이슈가 발생 가능하기에 사전 정리
  
  
  

모던 브라우저와 레거시 브라우저의 인증서 체인 차이(출처: Sectigo 공식 문서)

• AddTrust 루트 인증서가 만료 되더라도 대체 루트/체인과 교차서명(Cross-Sigining)을 통해서 95% 이상 대부분의 접속에는 문제 X
• "오래된 구형 디바이스 또는 해당 SW 공급사에서 제공된 최신 업데이트를 적용하지 않은" PC/Mobile/프레임워크 등 에서 접속 문제 발생 가능
• USERTRust 루트 인증서뿐만 아니라 AddTrust 인증서까지 인증서 체인을 검증하는 레거시 시스템의 경우 문제가 발생 가능
  

  

  
  

Comodo의 AddTrust 인증서까지 확인하는 다양한 서비스에 영향이 발생

• 참고 트위터 URL → https://twitter.com/__agwa/timelines/1266777818811322368
• 데이터독 에이전트도 일부 조건에서 영향 → https://github.com/DataDog/dd-agent/issues/3881
• macOS에서도 코모도 인증서를 사용하는 사이트 curl 명령어로 실행할 경우 인증서 만료로 실패 → https://security.stackexchange.com/questions/232445/https-connection-to-specific-sites-fail-with-curl-on-macos
  
  
  

Comodo의 AddTrust 인증서 대체하는 AAA 루트/체인 인증서

• 기존에 배포되었던 Sectigo/Comodo 의 "AddTrust External CA Root" 루트 인증서가 05/30 만료 예정
• SecureSign 에서는 루트 인증서 만료에 대응하여, 기존 AddTrust 대신 대체 AAA 루트/체인 인증서로 2019/12/03 부터 첨부 제공
  1. AddTrust External CA Root 루트 만료 관련 (추가 안내 사항) (2020/05/31) → https://www.securesign.kr/supports/announceView/56
  2. Sectigo 제품 발급시 AAA 루트/체인 인증서 파일로 변경 첨부 (2019/12/03) → https://www.securesign.kr/supports/announceView/48
  3. Sectigo AddTrust External CA Root Expiring May 30, 2020 → https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l00000117LT
  4. Sectigo 루트/체인(중개) 인증서 변경 대상 인증서 매칭표 → https://www.securesign.kr/guides/kb/68
     
     
     

고객 조치 사항

1. 서버 인증서 설정시, 루트를 AddTrust 로 적용한 경우

• 구형 안드로이드등의 모바일 접속 문제가 발생 : 웹서버에서 AAA 루트/체인 인증서로 교체 적용 필요
• 서버간 SSL 통신시 접속 문제 발생
  1. 웹서버 → 루트/체인 인증서 교체 필요 (인증서 설치된 방화벽등 기타 장비도 교체 필요)
  2. 클라이언트 서버 → 신규 루트인증서 추가 설치 필요
  3. Windows PC 에서 접속 문제가 발생 → 각 PC 자체적으로 루트인증서 설치 조치 필요

2. 서버인증서 발급시, AAA 루트로 포함(적용)되어 있는 경우

• 서버에서 조치할 작업 X
• Windows PC 에서 접속 문제가 발생 → 각 PC 자체적으로 루트인증서 설치 조치 필요
  
  
  

※ 참고

• 참고 URL : https://www.sslcert.co.kr/supports/announceView/53
• 참고 URL : https://github.com/DataDog/dd-agent/issues/3881
  

• WHOIS는 도메인 이름이나 IP 주소의 레지스트리가 관리하는 등록과 할당 정보를 인터넷에 공개하여 이용자가 참고할 수 있도록 해주는 서비스
• ICANN에서는 WHOIS를 "도메인이나 IP 주소의 관리 책임자는 누구인가를 질문하는 시스템"으로 정의 → 누구나 쉽게 도메인 등록 정보를 검색하여 이용할 수 있는 서비스를 제공
• 어느 Registrar나 Registry 사이트를 방문하더라도 손쉽게 도메인 정보 검색 페이지를 확인할 수 있어야함
• WHOIS는 도메인을 확인하고 도메인과 관련된 사람과 인터넷의 자원을 찾아보기 위한 프로토콜로써 만들어짐
• WHOIS는 전세계적으로 모든 국가에는 ISO3166-1에 지정한 2문자로 된 국가코드가 부여
  1. 한국의 경우, ISO3166-1 국가코드는 KR
  2. 북한은 KP이지만, 아직 APNIC에 가입되어 IP를 할당 받은 것은 없음

• 도메인 등록 사업을 운영하고자 하는 자는 ICANN으로부터 그 자격을 인증 받아야 함
• RIR(Regional Internet Registry, 대륙별 인터넷주소자원 관리기관)에 가입되어 있는 국가들 중에서도 WHOIS 서버를 공식적으로 제공하지 않는 국가들도 많음
• WHOIS 서버에 쿼리할 때는 서버의 포트를 지정 → WHOIS 서비스는 일반적으로 43번 포트를 사용
  
  
  

WHOIS 서비스를 공식 서비스하는 국가별 WHOIS 서버의 인터넷 주소들

WHOIS 서버를 통해서 얻을 수 있는 정보 → 관리자 이름, 연락처등등은 사회 공학적 방법으로 사용 가능

• 도메인 등록 정보를 제공하는 곳은 등록자의 데이터를 받아 보관하고 관리하는 Registry와 Registrar 두 곳
• ccTLD와 gTLD의 정책 결정 기구가 다르기 때문에 도메인마다 공개되는 등록 데이터에는 차이가 있음
• WHOIS가 제공하고 있는 주요한 등록 정보를 확인
• 도메인 등록인 혹은 홈페이지의 운영자와 관련된 연락 정보는 아래 정보 리스트에서 붉은 색으로 표시
• 전세계 수십억의 인터넷 사용자가 언제든지 확인 가능한 개인의 전화번호와 이메일 등록 필요 → 메인 등록 정보 제공이 개인정보를 침해한다는 문제가 계속해서 제기

• 정보 리스트
  1. 등록 , 관리 기관
  2. 도메인 이름, 도메인 관련 인터넷 자원 정보
  3. 목표 사이트 네트워크주소와 ip주소
  4. 등록자, 관리자, 기술 관리자의 이름 및 연락처, 이메일 계정
  5. 레코드 생성 시기와 갱신 시기
  6. 주 DNS서버와 보조 DNS서버
  7. IP 주소의 할당 지역 위치
     

     

     
     

WHOIS 의 사용 세가지 목적

• 기술적인 문제가 발생했을 때 당사자의 연락처 정보 확보
• 도메인 이름의 등록 상태 확인
• 보안 사고나 도메인 이름과 상표의 관계 등 비기술적인 문제 해결
  
  
  

※ 참고

• 참고 URL : https://blog.naver.com/yoo0826/50131452771
• 참고 URL : https://library.gabia.com/contents/domain/2900/