히포

• DNS 쿼리 및 응답은 인터넷 작동 방식의 기본 → 웹사이트를 방문할 때, 브라우저에 URL을 입력
• DNS 쿼리를 보냄 → DNS는 사람이 읽을 수 있는 도메인 이름(예: hippo.com)을 인터넷 프로토콜(IP) 주소(예: 192.168.0.100)로 변환
• 웹사이트에 성공적으로 접속했는지 여부에 관계없이 받는 모든 응답에는 코드가 포함
• 거의 모든 DNS 쿼리와 함께 반환되는 가장 일반적인 네 가지 쿼리
  1. NOERROR
  2. NXDOMAIN
  3. SERVFAIL
  4. REFUSED

• DNS 쿼리에 문제가 있는 경우 응답 데이터를 통해 보안 위반 문제를 더 빨리 해결하거나 식별하는 데 도움이 될 수 있음
• DNS 반환 코드에 대해 간략하게 설명
  

  DNS 응답 코드	설명
  NOERROR	- DNS 쿼리가 성공적으로 완료
  NXDOMAIN	- 쿼리한 도메인 이름이 존재하지 않기 때문에 DNS 쿼리가 실패
  SERVFAIL	- 답변을 제공할 수 없기 때문에 DNS 쿼리가 실패
  REFUSED	- 서버가 정책으로 인해 응답을 거부했기 때문에 DNS 쿼리가 실패

• DNS 응답 코드 개요
  • 공식적으로 DNS의 응답 코드 전체 목록은 24개가 넘음
  • DNS 쿼리는 약 84%의 시간을 성공 → NOERROR 코드를 생성
  • DNS 쿼리의 약 16%가 실패 → 세 가지 공통 코드 중 하나가 발생(NXDOMAIN, SERVFAIL, REFUSED)

1. DNS 응답 코드 NOERROR

1.1. 가장 일반적인 응답

• 약 80~90%에서 NOERROR는 네트워크 로그에 표시되는 응답 코드
• NOERROR는 DNS 쿼리가 유효한 응답을 받았다는 의미
• NOERROR는 모든 것이 정상이며 쿼리에 문제가 없었음을 나타내는 방법
• 사용자가 hippo.com 도메인으로 요청을 하였으며, 리졸버와 DNS 서버가 hippo.com 도메인으로 정상 이동

1.2. NOERROR 응답 코드가 항상 완벽하다는 의미 X

• NOERROR 응답이 반환되었다고 하여, 네트워크의 사용자가 특별히 요청한 웹사이트로 이동했다는 의미는 아님
• 사용자가 hippo.com 도메인으로 요청
• hippo.com 도메인으로 요청을 보냈을 경우 test.com 도메인으로 리다이렉션되도록 설정
• 사용자가 hippo.com 도메인으로 이동하면, 성공적인 NOERROR 응답 코드를 받음
• 성공적으로 NOERROR 응답코드가 출력되면서, 사용자가 test.com 도메인으로 이동
• hippo.com 도메인 요청하였을 때, test.com 도메인 서버에 장애가 발생하거나 액세스 권한이 없다고 알려도 DNS 로그에서는 NOERROR 응답

2. DNS 응답 코드 NXDOMAIN

• 수신된 응답 코드의 나머지 10~15%는 대부분 NXDOMAIN
• 서버가 되돌려 보내는 NXDOMAIN 응답의 의미는 "이 도메인에 대해 쿼리했지만 해당 도메인이 존재하지 않거나 존재하는지 모르겠습니다."
• NXDOMAIN이 발생했다는 의미는 쿼리가 실패를 의미
• NXDOMAIN 응답 코드가 네트워크에 의미하는 바에 대한 전체 블로그 게시물이 있지만 여기에서 몇 가지 기본 사항을 다룸

2.1. NXDOMAIN에 대한 의미

1. 브라우저에서 도메인 이름을 잘못 입력하는 동안 사용자 오류가 발생
2. 보안 제어가 사용자가 접근하려는 사이트를 차단
3. 일부 오래된 코드가 더 이상 존재하지 않는 웹사이트에 연결
4. 잘못 구성된 응용 프로그램이 철자가 잘못된 도메인을 쿼리
5. 도메인이 손상되었거나 맬웨어가 존재한다는 표시

2.2. 악성코드 감염의 징후

• 일반적으로 맬웨어는 코드에 하나 이상의 도메인에 접근하는 경우가 있음
• 악성 코드에 감염된 장치가 현재 차단된 도메인을 확인할 수 없는 경우 NXDOMAIN 응답이 발생

3. DNS 응답 코드 SERVFAIL

• SERVFAIL 응답은 약 1%
• NXDOMAIN이 도메인이 존재하지 않는다는 것을 알려주는 DNS 서버라면, SERVFAIL은 "당신에게 그 쿼리에 대한 답을 줄 수 없다"라고 말하는 DNS 서버
• DNS 서버에 기술적인 문제로 인해 발생 가능 → 방화벽이나 침입 방지 시스템과 같은 네트워크의 보안 제어가 사용자가 해당 도메인으로 이동하는 것을 차단하고 있음을 의미
• NXDOMAIN과 마찬가지로 과도한 SERVFAIL 응답은 추가 조사가 필요
• SERVFAIL 응답을 받는 도메인도 악의적인 활동에 대해 조사 필요

4. DNS 응답 코드 REFUSED

• REFUSED는 DNS 이름 서버가 정책상의 이유로 작업 수행을 거부할 때 발생 → 특정 장치가 네임서버를 악용하는 경우 차단
• 특정 작업이 금지될 수 있음
  1. 영역 전송은 로드 밸런싱 또는 백업을 위해 여러 DNS 서버에 DNS 구성 정보를 복제하는 방법
  2. 일반적으로 권한이 있는 사람만 영역 이전을 완료 가능
  3. 일반 사용자가 DNS 구성 정보를 복제하려고 할 때, 권한이 없으면, REFUSED 응답 코드가 발생

1. DNS TXT 레코드란?

• DNS TXT 레코드를 사용하면 도메인 관리자가 도메인 네임 시스템(DNS)에 텍스트를 입력할 수 있음
• DNS TXT 레코드는 원래 사람이 읽을 수 있는 메모를 위한 장소 → 기계가 읽을 수 있는 일부 데이터를 TXT 레코드에 넣을 수 있음
• 하나의 도메인에 여러 TXT 레코드가 있을 수 있음

• TXT 레코드의 예
  

  

• 오늘날 DNS TXT 레코드의 가장 중요한 두 가지 용도 → TXT 레코드는 원래 아래 용도로 설계 X
  1. 이메일 스팸 방지
  2. 도메인 소유권 확인

2. DNS TXT 레코드에는 어떤 종류의 데이터가 포함될 수 있을까요?

• 참고 자료 : https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.14
• RFC의 'TXT-DATA'에는 TXT 레코드의 값이 필드에 들어갈 수 있음

  TXT-DATA        One or more <character-string>s.

• 관리자가 자체 도메인과 연결하려는 텍스트 → TXT 레코드는 설명 텍스트를 저장하는 데 사용
• 대부분의 DNS 서버는 TXT 레코드의 크기와 저장할 수 있는 레코드 수에 제한 → 많은 양의 데이터에 TXT 레코드를 사용할 수 없음

3. DNS TXT 레코드에 데이터를 저장하는 공식적인 형식은?

• 1993년 인터넷 엔지니어링 태스크 포스(IETF)에서는 TXT 레코드의 '값' 필드에 속성과 해당 값을 저장하는 형식을 정의
• 따옴표(")에 포함된 속성과 값
• 속성과 값은 등호(=)로 구분

  "속성 = 값"

• DNS TXT 레코드를 정의하는 1993년 문서인 RFC 1464에는 아래 예제가 포함(https://datatracker.ietf.org/doc/html/rfc1464)
  

  

• DNS 관리자는 TXT 레코드를 사용하는 경우, TXT 레코드 내에서 자체 형식을 따름
• TXT 레코드는 특정 용도에 대해 특정 방식으로 형식이 지정될 수도 있음(예: DMARC 정책은 표준화된 방식으로 형식을 지정)

4. TXT 레코드는 이메일 스팸을 방지하는 데 어떻게 도움이 될까요?

• 스팸 발송자는 종종 이메일 메시지를 보내는 도메인을 위조하거나 위조하려고 시도함
• TXT 레코드는 이메일 서버가 신뢰할 수 있는 출처에서 온 메시지인지 확인하는 데 도움이 되는 여러 이메일 인증 방법의 핵심 구성 요소

• 일반적인 이메일 인증 방법
  1. 도메인 키 식별 메일(DKIM)
  2. 발신자 정책 프레임워크(SPF)
  3. 도메인 기반 메시지 인증 보고 및 적합성(DMARC)

• 도메인 운영자는 아래 TXT 레코드를 구성하여 스팸 발송자가 도메인을 스푸핑하는 것을 더 어렵게 만들고 스푸핑 하려는 시도를 추적할 수 있음
  1. SPF 레코드
     • SPF TXT 레코드에는 도메인에서 이메일 메시지를 보낼 권한이 있는 모든 서버가 나열
  2. DKIM 레코드
     • DKIM TXT 레코드는 공개-개인 키 쌍을 사용하여 각 이메일에 디지털 서명하는 방식으로 작동
     • DKIM을 사용하면 이메일이 실제로 보낸 도메인에서 온 것인지 확인 가능
     • 공개 키는 도메인과 연결된 TXT 레코드에서 호스팅
     • 공개 키 암호화 방식 참고 자료 : https://www.cloudflare.com/ko-kr/learning/ssl/how-does-public-key-encryption-work/
  3. DMARC 레코드
     • DMARC TXT 레코드는 도메인의 SPF 및 DKIM 정책을 참조
     • DMARC TXT 레코드는 제목 _dmarc.example.com 아래 'example.com'과 함께 실제 도메인 이름으로 대체해서 저장
     • 레코드의 '값'은 도메인의 DMARC 정책
     • DMARC TXT 레코드 참고 자료 : https://dmarcguide.globalcyberalliance.org/#/dmarc/

5. TXT 레코드는 도메인 소유권을 확인하는 데 어떻게 도움이 될까요?

• 도메인 소유권 확인은 처음에는 TXT 레코드의 기능이 아니었지만, 일부 웹마스터 도구 및 클라우드 공급자가 TXT 레코드를 활용
• 관리자는 특정 정보가 포함된 새 TXT 레코드를 업로드하거나 현재 TXT 레코드를 수정 → 도메인을 제어하고 있음
• 도구 또는 클라우드 공급자는 TXT 레코드를 확인하고 요청에 따라 변경되었는지 확인 가능
• 사용자가 이메일로 전송된 링크를 열고 클릭하여 이메일 주소를 확인해서 자신이 해당 주소를 소유하고 있음을 증명하는 것과 비슷

참고 자료

• https://www.cloudflare.com/ko-kr/learning/dns/dns-records/dns-txt-record/

1. DNS NS 레코드란

• NS는 '네임서버(Name Server)'를 의미
• 네임서버(Name Server) 레코드는 어떤 DNS가 해당 도메인의 권한 있는 Name Server(실제 DNS 레코드를 갖고 있는 서버)인지 지시함
• 기본적으로 NS 레코드는 해당 도메인의 IP 주소를 찾기 위해 가야 할 곳을 알려줌
• 도메인에는 해당 도메인의 기본 및 백업 네임서버(Name Server)를 나타낼 수 있는 NS 레코드가 다수 있음
• NS 레코드가 적절히 구성되어 있지 않다면 사용자는 웹 사이트나 애플리케이션을 로딩할 수 없게 됨

• NS 레코드의 예시
  

  

  
  ※ NS 레코드는CNAME 레코드를 지시할 수 없음

2. 네임서버(Name Server)란

• 네임서버(Name Server)는 DNS 서버의 유형 중 한 가지
• A 레코드, MX 레코드, CNAME 레코드 등 특정 도메인에 관한 모든 DNS 레코드를 저장하는 서버
• 모든 도메인이 안정성을 높이기 위해 다수의 네임서버(Name Server)에 의존
• 네임서버(Name Server) 하나가 중단되거나 사용할 수 없게 되어도 DNS 쿼리는 다른 네임서버(Name Server)를 이용할 수 있음
• 기본 네임서버(Name Server)가 하나 있으며, 네임서버(Name Server)의 DNS 레코드를 그대로 복사한 내용을 갖고 있는 보조 네임서버(Name Server)가 다수 존재하게됨
• 기본 네임서버(Name Server)를 수정하면 보조 네임서버(Name Server)도 마찬가지로 수정됨
• 다수의 네임서버(Name Server)를 이용할 경우에는 NS 레코드에 하나 이상의 서버 목록이 포함됨

3. 언제 NS 레코드를 수정하거나 변경 필요한가?

• 도메인 관리자는 도메인의 네임서버(Name Server)를 바꿔야 할 경우 NS 레코드를 수정 필요
• 예를 들어 클라우드 공급자 중에는 네임서버(Name Server)를 제공하며, 고객이 서버를 가리키도록 요구하는 경우가 있음
• 도메인 관리자는 하위 도메인에 다른 네임서버(Name Server)를 이용하고자 할 때도 NS 레코드를 수정이 필요함

• 예시
  1. example.com의 네임서버(Name Server)가 ns1.exampleserver.com임
  2. example.com의 네임 서버(Name Server)관리자가, blog.example.com 도메인을 질의할 때 ns1.exampleserver.com 대신 ns2.exampleserver.com을 통해 확인되도록 설정 필요
  3. NS 레코드를 수정함으로써 blog.example.com 도메인을 질의할 때, ns2.exampleserver.com을 통해 질의 가능

• NS 레코드를 수정하면, 변경 사항이 DNS에 복제되는 데는 몇 시간이 걸리기도 함

참고 자료

• https://www.cloudflare.com/ko-kr/learning/dns/dns-records/dns-ns-record/

1. DNSSEC 등장 배경

• DNS는 ‘도메인’을 ‘IP주소’로 변환하는 인터넷의 전화번호부 같은 역할을 함
• 인터넷 초기에 개발된 DNS는 설계당시 보안성을 충분히 고려하지 못해, DNS정보의 위-변조가 가능하다는 문제가 있음
• 악의적인 공격에 의해 도메인네임에 대한 IP주소가 악성 사이트 등으로 위/변조 된다면, DNS를 이용하는 인터넷 이용자들은 의도치 않은 IP주소로 연결되어 피해가 발생 가능

• 파밍(pharming)은 ISP의 캐시 DNS서버나 사용자 PC에 특정 도메인네임에 대해 위-변조된 IP주소가 설정되도록 하는 공격방식
• 파밍(pharming) 공격이 성공하면 사용자는 분명히 올바른 웹 사이트 주소를 입력하였음에도 불구하고(예: 인터넷뱅킹, 쇼핑몰 등), 공격자가 만들어놓은 가짜 사이트로 유도되는 상황이 발생
• 가짜 사이트는 원래 사이트와 동일한 모습으로 꾸며져 있기에 사용자는 아무런 의심도 하지 않고 자신의 로그인 정보와 계좌정보 등을 가짜 사이트에 입력해 피해가 발생
• ISP나 기관이 운영하는 캐시 DNS서버를 대상으로 "파밍(pharming)" 공격이 성공하는 경우, 캐시 DNS서버를 사용하고 있는 모든 인터넷 사용자에 대해 대규모의 피해가 발생 가능
• 캐시 DNS서버는 한번 파악한 DNS 정보는 자신의 캐시 메모리에 저장하여 일정시간이 경과하기 전까지 DNS 정보를 반복 사용하여 사용자 호스트의 DNS 질의에 응답
• 캐시 DNS서버의 캐시 메모리에 가짜 데이터를 저장하여 사용하도록 유도하는 방식의 파밍(pharming) 공격 → "DNS 캐시 포이즈닝(cache poisoning) 공격"

1.1. 인터넷 상의 피싱(phishing) 공격과 파밍(pharming) 공격 비교

1.2. 인터넷 상의 피싱(phishing) 공격과 파밍(pharming) 공격 비교

• 파밍 공격 절차
  1. 거래은행인 www.bank.kr 사이트 접속을 위해 사용자는 'http://www.bank.kr/' 주소를 입력
  2. 호스트는 www.bank.kr의 IP 주소를 파악하기 위해 DNS 질의 개시(1)
  3. DNS 서버들은 www.bank.kr의 IP 주소를 파악하기 위해 질의 진행(2~6)
  4. 파밍 공격자는 (7-1)의 정상 DNS응답이 캐시 DNS서버에 도달 전에 자신이 조작한 가짜 DNS 응답메시지를 (7-2)와 같이 대량으로 캐시 DNS서버에 송출
  5. 캐시 DNS서버는 DNS 응답메시지 수신대기 중 공격자가 송출한 (7-2)의 가짜 DNS 응답 메시지 수신(7-2), 정상 응답이 이루어진 것으로 간주, 캐시에 위-변조된 가짜 데이터 저장
  6. 캐시 DNS서버는 사용자 호스트에는 이 가짜 IP 주소 데이터로 응답처리(8-2)
  7. 사용자 호스트는 캐시 DNS서버가 응답한 가짜 IP 주소를 사용하여 웹 사이트 접속(9-2)
  8. 오염된 캐시 DNS서버를 사용하는 다른 사용자가 동일한 도메인네임을 질의하면 캐시 DNS서버는 이 캐시 메모리의 가짜 IP 주소로 바로 응답처리 → 인터넷 사용자의 피해자는 시간이 갈수록 늘어남

• 파밍 공격 절차 그림
  

  

2. DNSSEC 개념

• DNSSEC(DNS Security Extensions)은 DNS 데이터 대상의 "데이터 위조-변조 공격"을 방지하기 위한 인터넷 표준기술
• DNSSEC(DNS Security Extensions)은 2005년경 완성된 국제표준기술로 다양한 시험을 거쳐 2010년에는 전세계 최상위 DNS인 ‘루트DNS’에도 적용되면서, 전세계적으로 적용이 확대
• 우리나라는 2011년 “.kr” 국가도메인 영역에 대한 DNSSEC 적용을 시작
• 2012년 9월 .kr, .한국 등 총 31개 국가도메인 영역 전체에 DNSSEC 적용을 완료하여 DNSSEC 개념을 본격적으로 서비스 제공
• DNSSEC은 DNS를 대체하는 것이 아니라, 기존의 DNS에 공개키 암호화 방식의 보안기능을 추가 부여 → DNS의 보안성을 대폭 강화하는 역할
• DNS 데이터의 위조-변조 가능성을 원천적으로 차단하기 위해, DNSSEC은 공개키 암호화방식(Public Key Cryptography)의 전자서명 기술을 DNS 체계에 도입 적용
• 공개키 암호화방식의 전자서명 메커니즘은 금융권 등에서 널리 사용하는 공인인증서가 사용하고 있는 기술

2.1 DNSSEC은 전자데이터로 된 DNS정보에 서명코드를 추가하여 정보를 인증

2.2. 도메인과 IP주소에 대한 검증 절차가 수행되므로 해커에 의한 데이터 위·변조시 확인 가능

3. 보안침해 공격에 대한 DNSSEC이 제공하는 보안성 범위

4. DNS 구성체계 중 DNSSEC이 제공하는 보안 안정성 범위

• DNSSEC은 인터넷 상의 도메인에 대한 DNS 질의응답 절차 가운데 발생할 수 있는 "DNS 데이터 위-변조" 공격에 대응할 수 있는 보안기술
• 권한 DNS서버 간 존 데이터 전송 또는 동적업데이트와 같은 네임서버 관리영역의 동작에 대해서는 별도의 공유키 암호화 방식인 TSIG 기술을 사용하여 보호체계를 적용 가능
  

  

• DNS RR 내용 예
  

  구분	보호 영역 여부	비고
  권한 DNS서버 ⇔ 캐시 DNS서버	보호	- DNS 질의응답 절차 중 DNS 데이터 위-변조 공격 검출 수단 제공
  캐시 DNS서버 ⇔ 사용자 호스트	조건부 보호	- 사용자 호스트에 서명검증 가능한 리졸버(Validator) 사용 시 보호 - 그렇지 않은 경우, 보호할 수 없음
  권한 DNS서버 간 존 전송	대상 아님	- TSIG 적용 인증체계로 보호
  권한 DNS서버 동적 업데이트	대상 아님	- TSIG 적용 인증체계로 보호

참고자료

• KISA 참고 자료 : https://xn--3e0bx5euxnjje69i70af08bea817g.xn–3e0b707e/jsp/resources/dns/dnssecInfo/dnssecInfo.jsp
• google cloud 참고 자료 : https://cloud.google.com/dns/docs/dnssec?hl=ko

• 도메인 이름을 사용하기 위해서는 도메인 이름을 관리하는 레지스트리의 레지스트리 데이터베이스에 등록 필요
• 현재 .kr이나 .com와 .net 등 주요한 TLD는 레지스트리·레지스트라 모델(Registry·Registrar model)을 등록 구조로 채택

1. 레지스트리·레지스트라 모델(Registry·Registrar model)

1.1. 레지스트리·레지스트라 모델(Registry·Registrar model) 분리

• 레지스트리와 레지스트라 모델은 도메인 이름의 등록 관리를 아래 두가지 역할로 분리하고 있음
  1. 레지스트리 → 도메인 이름을 일원화 관리
  2. 레지스트라 → 도메인 이름의 등록자로부터 신청을 중개

1.2. 레지스트리·레지스트라 모델(Registry·Registrar model) 역할을 분리하는 이유

1. 도메인 이름 등록에서 등록될 도메인 이름을 고유하게 하면서 가격이나 서비스의 다양성을 확보하기 위함
2. 하나의 TLD에 대해서 레지스트리는 하나이지만 레지스트라는 보통 여럿이 존재함
3. 각 레지스트라는 획일적인 서비스가 아닌 다양한 서비스를 등록자에게 제공할 수 있음 → 레지스트라는 독자적인 서비스나 가격 설정이 가능하고, 등록자는 자신에게 맞는 레지스트라를 고를 수 있음

1.3. 레지스트리·레지스트라 모델(Registry·Registrar model)에서 리셀러(reseller)

1. 레지스트라를 통해서 등록한 도메인 이름을 다른 등록자에게 재판매하는 것을 리셀러(reseller)라고 함
2. 리셀러는 레지스트라와 등록자 사이에서 도메인 이름의 등록에 관한 각종 신청을 중개함
3. 리셀러는 레지스트리와의 계약 관계가 없으며 해당 도메인 이름을 취급하는 레지스트라와 계약을 맺고, 등록자로부터 레지스트라에게 도메인 이름의 등록을 중개함
4. 등록자 입장에서 볼때 도메인 이름의 등록을 접수하는 사업자가 레지스트라인 경우도 있고, 리셀러인 경우도 있음

1.4. 레지스트리·레지스트라 모델(Registry·Registrar model)에서 역할의 분리

2. 레지스트리(Registry)

• 레지스트리(Registry)는 등록된 도메인명의 데이터베이스를 유지 관리하는 기관
• 같은 도메인명이 이중 등록되지 않도록 레지스트리는 데이터베이스를 일원적으로 관리
• 최상위 도메인(TLD) 별로 레지스트리는 하나만 존재하며, 하나의 레지스트리가 복수의 최상위 도메인을 관리하기도 함

• 레지스트리(Registry) 예시
  • .com의 레지스트리는 VeriSign → VeriSign은 .com 이외에 .net도 관리
  • 레지스트리는 등록된 도메인명이 인터넷 상에서 접속될 수 있도록 최상위 도메인(TLD)의 도메인 네임 서버(DNS)를 운용하고 있음
    
    
    

3. 레지스트라(Registrar)

• 레지스트라는 도메인 네임 등록 대행 업체
• 레지스트라는 등록자로부터 도메인 네임의 등록 신청을 접수하고, 등록 데이터를 레지스트리의 데이터베이스에 등록함
• 최상위 도메인 당 하나만 존재하는 레지스트리와 달리, 등록 서비스를 제공하는 레지스트라는 레지스트리와의 계약 하에 복수 존재 가능
• 도메인 등록•관리 비용은 레지스트라에 따라 차이가 있음
• 레지스트라로 인정되기 위해서는 국제 인터넷 주소 관리 기구(ICANN)에 의한 심사에 합격할 필요가 있음
• 아래 레지스트라(Registrar)의 역할 정리

3.1. 등록자로부터 등록 신청 접수

• 도메인 이름의 등록자로부터 등록 신청을 접수함

3.2. 레지스트리 데이터베이스에 등록 의뢰

• 등록자의 신청에 따라 레지스트리에게 도메인 이름의 등록을 의뢰
• 등록 의뢰 결과를 등록자에게 알려줌

3.3. Whois 서비스 제공

• 자신이 취급하는 도메인 이름에 관한 Whois 서비스를 제공

3.4. 등록자 정보 관리

• 도메인 이름의 등록을 신청한 등록자의 정보를 관리함
• 레지스트리와 레지스트라의 역할 분담은 TLD의 종류에 따라 달라짐
• 예시)
  • KR 도메인 이름에서 Whois 서비스는 레지스트리만이 제공
  • 등록 정보를 관리하는 책임의 범위도 KR 도메인 이름과 gTLD가 서로 다름
    
    
    

4. 리셀러(Reseller)

• 리셀러는 레지스트라를 경유하여 도메인 등록 업무를 대행하는 업자를 말함
• 리셀러는 SRS(Shared Registry System)이라는 도메인 관리 시스템의 접속 권한 없음
• 리셀러는 반드시 레지스트라를 경유하여 도메인을 관리하게됨
  
  
  

5. ICANN(국제 인터넷 주소 관리 기구)

• ICANN은 The Internet Corporation for Assigned Names and Numbers의 약자
• ICANN은 국제 인터넷 주소 관리 기구를 의미
• 인터넷 주소 체제(DNS)의 효율적인 관리를 목적으로 설립된 비영리 기관 → 인터넷 도메인 관리와 정책을 결정하는 도메인 관련 국제 최고 기구
  
  
  

6. 관계 정리 : ICANN → 레지스트리 → 레지스트라 → 리셀러

• 인터넷은 전체를 집중 관리하지 않는 분산 관리가 기본 → DNS도 계층화와 위임을 통해서 각 조직에 의한 분산 관리를 실현하기 위한 구조 중 하나
• 인터넷에 연결된 호스트를 식별하기 위한 IP 주소(번호)나 도메인 이름(이름)과 같은 식별자는 예외적으로, 이용자가 혼란하지 않도록 통일되고 일원화된 관리를 해야함
• 레지스트리(registry)는 인터넷상의 번호나 이름을 할당하고 등록하여, IP와 도메인을 이용자가 혼란하지 않도록 통일되고 일원화된 관리하는 조직
• 레지스트리와 그 관계자에 의한 도메인 이름의 등록 관리 구조와 세계적인 관리 체계를 설명

1. 레지스트리 오퍼레이터의 2가지 의미

• 식별자를 할당하고 등록 관리를 하는 레지스트리 오퍼레이터 → DNS에서 레지스트리 오퍼레이터를 레지스트리라고 함
• 레지스트리 오퍼레이터가 취급하는 등록대장인 레지스트리 데이터 베이스
  
  
  

2. IP 주소와 도메인 이름 관리의 차이

• IP 주소와 도메인 이름은 할당 및 등록 관리에 대한 처리가 다름

2.1. IP 주소

• 한정된 자원을 인터넷 전체에서 공유하기 때문에, 이용 효율이나 공평한 할당과 같은 점을 고려해 세계적으로 일관성 있는 관리가 필요
• 공평한 IP 관리를 하기 위해서, IP 주소 레지스트리는 규칙을 정하거나 레지스트리 간의 조정을 담당

2.2. 도메인 이름

• 하나의 네임 스페이스를 TLD마다 분할하고, 각 TLD의 특색에 맞게 이용자의 다양한 요구에 부합하는 서비스를 운용할 수 있다는 유연성을 가짐
• 도메인 이름은 이용자에게 친근한 단체명, 서비스명, 상품명을 연상시키기 때문에 등록, 이용 중에 발생한 트러블, 분쟁을 해결하기 위한 구조도 필요
  
  
  

3. 레지스트리의 역할

• 도메인 이름을 사용할 수 있도록 하기 위해서는 레지스트리에게 '이 도메인 이름을 사용하고 싶다'라는 등록 신청함
• 신청을 접수한 레지스트리는 그 내용이 등록 요건에 부합하는지를 심사 및 확인하고 데이터베이스에 등록
• 위 과정을 거쳐서 신청자는 도메인 이름을 사용할 권리를 얻게 됨
• 등록한 도메인 이름에는 만료일이 설정되며, 수명 주기(life cycle)에 따라 운용해야합니다.
• 레지스트리는 신규 등록 외에, 등록자의 신청에 따라서 이미 등록된 도메인 이름의 등록 정보 갱신, 만료일 갱신, 삭제 등을 하면서 도메인 이름을 관리

• 도메인 이름의 수명 주기란
  • 도메인 이름은 한번 등록하면 영원히 사용할 수 잇는 것이 아니라 만료일이 존재합니다.
  • 만료일이 지난 도메인 이름은 일정 기간 후에 '삭제'로 취급되며, 삭제된 도메인 이름은 다시 등록할 수 있게 됩니다.
  • KR 도메인 이름의 등록부터 삭제까지 수명 주기에 대한 추가 정보 → 도메인 주소에서 생명 주기(Life Cycle)란
    
    
    

4. 레지스트리의 주된 역할 여섯가지

4.1. 레지스트리 데이터베이스의 운영 관리

• 등록 정보를 축적하고 관리하는 등록 대장인 '레지스트리 데이터베이스'를 운용
• 등록 정보란, 도메인 이름을 등록하기 위해 필요한 개인의 이름, 조직명, 연락처와 같은 정보

4.2. 정책에 따른 등록 규칙의 제정

• 레지스트리는 자신이 등록 관리하는 도메인 이름의 정책을 정함
• 정책을 실현하기 위한 등록 규칙과 세칙을 정하고 이용자에게 알려줌

4.3. 등록 신청 접수

• 레지스트리는 등록자로부터 도메인 이름의 등록 신청을 접수함
• 신청된 도메인 이름을 규칙에 따라 심사하고 접수한 정보를 레지스트리 데이터베이스에 등록함

4.4. Whois 서비스 제공

• 레지스트리는 자신이 관리하는 도메인 이름의 정보를 Whois 서비스로 제공
• Whois의 자세한 자료 → WHOIS 서버란

4.5. 네임 서버 운용

• 관리 대상인 도메인 이름을 인터넷에서 이용할 수 있도록 하기 위한 네임 서버를 관리 및 운용함
• 레지스트리의 네임 서버는 등록자가 등록한 위임 정보를 관리

4.6. 정보 전달 및 교육 활동

• 인터넷 전체를 원활하게 운용하기 위해 많은 레지스트리가 인터넷에 관한 정책, 거버넌스, 기술 등 각 분야의 정보를 전달하거나 교육 활동을 하고 있음
  
  
  

5. 레지스트리와 TLD의 관계

• TLD마다 레지스트리가 존재하며, 각 레지스트리가 TLD를 관리하고 관리 정책이나 등록 규칙을 정함
• TLD의 두가지 종류
  1. 국각나 지역마다 할당되는 도메인 : ccTLD(Country Code Top Level Domain)
  2. 국가나 지역에 상관없는 도메인 : gTLD(Generic Top Level Domain)

5.1. ccTLD

• 문자열(라벨)에는 원칙적으로 ISO(국제 표준화 기구)의 ISO 3166-1로 규정된 두 글자의 국가코드가 사용됨
• 한국에는 국가코드 'KR'이 할당

• ccTLD가 두 글자가 된 이유
  • ISO 3166-1에는 알파벳 두 글자를 사용한 'alpha-2', 알파벳 세 글자를 사용한 'alpha-3', 숫자 세글자를 사용한 'numeric-3'가 규정
  • ccTLD를 정할 때 세 글자 TLD인 '.com'과 '.net' 등은 이미 사용
  • 숫자는 IP 주소와 혼돌할 우려가 있어서 채택되지 못하고 알파벳 두 글자를 사용한 'alpha-2'가 채택

5.2. gTLD

• gTLD는 등록하는데 특별한 제한이 없는 것과 일정 요건이 필요한 것 2가지가 있음
• '.com'과 '.net'을 등록하는 데 특별한 제한이 없는 gTLD임
• '.edu'나 '.gov'와 같은 gTLD는 등록 제한이 있으며, 등록 가능한 대상은 미국의 교육기관이나 정부 기관으로 한정됨

• gTLD의 변천
  • 인터넷에 도메인 이름과 DNS가 도임된 1985년에 창설된 gTLD는 .com, .edu, .gov, .mil, .net, .org로 여섯 개가 있음
  • 이후 1988년에 국제단체가 사용하는 .int가 도임되어 일곱 개의 gTLD가 운영됨
  • ARPANET에서 기술을 이전하기 위한 용도로 .arpa도 추가 생성 → .arpa는 인프라스트럭처 도메인으로 전환되어 IP 주소의 역방향 등에서 사용
  • 1990년대 후반부터 인터넷의 급속한 발전과 상용으로 새로운 TLD 도입이 요구
  • 많은 gTLD가 추가되면서 현재 1,200개가 넘는 gTLD가 운영되고 있음

• 새로운 gTLD
  • 커뮤니티 TLD(Community-based TLD 또는 Community TLD)
  • 특정 커뮤니티나 그룹의 이용을 전체로 한 gTLD
  • 예를 들어 제약 업계를 대상으로 한 '.pharmacy'나 은행 업계를 대상으로 한 '.bank'가 있음

• 지리명 TLD(Geographical TLD 또는 Geographic names TLD)
  • 각국의 도시, 지역명 등을 대상으로 한 gTLD
  • 지리명 TLD
    

    

• 브랜드 TLD(Brand TLD)
  • 기업명이나 조직명, 상표 등의 문자열을 사용하는 gTLD

5.3. TLD의 예시와 레지스트리

• 도메인 또한 한 번 등록하면 영원히 내 것이 되는 것이 아니라, ‘등록 기간’에 따라 만료일이 정해져 있음
• 만료일에 가까워졌을 때 기간을 ‘연장’을 하지 않으면 도메인이 곧 삭제됨
• 삭제된 도메인은 다른 사람에 의해 다시 등록되어 새 생명을 얻을 수 있음
• 도메인의 등록→연장→삭제→방출→재등록에 이르는 순환 과정을 생물의 생존 주기에 빗대어 ‘Domain Name Life Cycle’이라 함

1. COM, NET으로 대표되는 ‘gTLD’의 등록 주기

1.1. 등록 기간

• 거의 모든 Registrar의 gTLD 등록 기간은 1~10년
• 도메인 등록 기간이 끝나기 전에 연장을 해야 지속적으로 보유 혹은 사용 가능
• 만기일(Expiration Date)이 돌아오기 전에 도메인을 지속적으로 연장을 한다면 사실상 도메인의 등록 기간은 영구적이라 볼 수 있음

1.2. 신규 등록 취소 가능 기간 (5일)

• Registrar에서 Registry로 신규 등록 취소 요청을 하고 환불을 받을 수 있는 기간
• 대부분의 Registrar는 신규 취소 기간을 제공하지 않음
• 대표적인 이유는 어떤 사용자가 다량으로 도메인을 등록한 후, 5일의 기간 동안 트래픽이 좋은 극히 일부 도메인을 제외하고 나머지 도메인은 취소하여 환불을 받아내는 ‘Domain Tasting’ 행위 때문임
• 무엇보다 가장 큰 문제는 다른 사용자가 도메인을 등록할 수 있는 기회를 박탈하게 된다는 점

1.3. Auto-Renew Grace Period (만기 후 추가 연장 가능 기간, 0~45일)

• 만기일 이후 자신의 의사에 반하여 사이트가 중단되거나 도메인이 삭제되는 일을 방지하기 위하여 유예 기간(45일)을 둠
• 만기 후 추가 연장 가능 기간을 'Auto-Renew Grace Period'라고 함

1.4. Redemption Grace Period (2차 추가 연장 기간, 30일)

• '등록 취소 가능 기간' 혹은 'Auto-Renew Grace Period' 두 기간에도 연장을 하지 않아 Registrar가 삭제한 도메인에 대하여 2차로 연장을 할 수 있도록 부여된 기간(30일)을 의미
• 국내에서는 주로 ‘도메인 복구(Restore) 기간’
• 이미 한번의 추가 기회가 주어졌음에도 불구하고 연장을 하지 않았기 때문에 복구를 통한 연장은 훨씬 비싼 비용이 부과됨

1.5. Pending Delete (방출 대기 기간, 5일)

• 복구 기간에도 연장되지 않은 도메인은 5일 후에 Registry에서 누구나 등록할 수 있도록 방출하게 되는데, 이 5일의 대기 기간을 ‘Pending Delete’라 함
• Pending Delete가 지난 후, 도메인은 다시 ‘등록 가능한’ 상태가 됨

1.6. 방출(등록 가능)

• 이전에 사용하던 도메인이 남아있어서 그것을 누군가가 다시 등록하는 개념이 아니라, 아무에게도 등록되지 않은 ‘존재하지 않는’ 도메인을 새로이 등록하는 개념
• gTLD는 이러한 주기를 거쳐 생을 마감하고, 새 생명을 얻음
  
  
  

2. KR로 대표되는 ‘ccTLD’의 등록 주기

2.1. 등록 기간

• KR 도메인의 등록 주기는 1~10년으로 gTLD의 등록 주기와 동일

2.2. 신규 등록 취소 가능 기간 (7일)

• 도메인 신규 등록을 취소하고 환불을 받기 위해서는 공휴일 여부와 상관없이 등록일로부터 7일 내 말소 요청을 해야함

2. 3. 추가 연장 가능 기간 (1개월)

• KR 도메인은 만기일이 지나면 단 1개월의 추가 연장 기간만 있음
• Pending Delete(방출 대기 기간)도 운영하지 않기 때문에 만기일이 속해 있는 월에 따라 만기일 후 30일, 31일이 지난 다음 날 오전에 누구나 등록할 수 있도록 방출됨
• 추가 연장 기간(1개월)만 부여한 후, 누구나 등록할 수 있도록 방출
• 사용자가 도메인을 등록한 후 연장하지 않는다면, 같은 날, 같은 기간으로 등록된 KR 도메인의 방출일은 모두 동일

참고 URL : https://library.gabia.com/domain-lifecycle/

• 도메인 이름 등록 구조에서 최상위에 위치는 ICANN 단체임 → 전세계에 있는 IP주소를 관리함과 동시에 Root 네임서버 관리자 역할을 함
• ICANN은 a.root-servers.net ~ m.root-server.net 이라고 하는 서버들을 관리 → 성능좋은 수많은 서버들은 전세계에 흩어져 웹 통신이 가능하도록 역할을 함
• Top-level 도메인을 관리하는 등록소가 있음
• 등록자가 도메인을 등록하는 작업을 대행해주는 등록대행자가 있음

1. Root 네임서버에 세팅

• Root DNS 서버는 전세계의 Top-level DNS 서버의 주소를 기억
• "com NS a.gtld-servers.net"의 의미는 "com 이라고 하는 Top-level 도메인의 네임서버는 a.gtld-servers.net 이라는 주소에 존재한다"
• Root 네임서버는 .com을 누가(Top-level DNS 서버) 관리하는 것인지 알게됨

2. Top-level DNS에 세팅

• Top-level DNS에 서버도 등록자의 네임서버를 알고 있어야 함
• "hippotest.com NS a.iana-servers.net"의 의미는 "hippotest.com 이라고 하는 등록자의 네임서버(nameserver)는 a.iana-servers.net 이라는 주소에 존재한다"

3. 등록자의 네임서버(nameserver) 세팅

• 등록자의 네임서버는 등록자의 IP주소를 알고 있어야 함
• 등록자는 자신의 IP주소 118.222.88.11를 "hippotest.com A 118.222.88.11"의 형식으로 네임서버(nameserver)에 IP 주소를 알려줌
• "hippotest.com A 118.222.88.11"의 의미는 "hippotest.com의 주소는 118.222.88.11입니다"

4. 도메인 이름 등록 프로세스 간략화

5. 도메인 이름 등록 프로세스

1. 첫번째 작업

• hippo 서버를 운영하고 싶은 운영자는 스스로 서버 1대를 마련해서 네임서버(nameserver)를 설치
• 네임서버(nameserver)를 설치한 컴퓨터를 a.iana-servers.net이라고 간주하고, 서버에 도메인을 세팅
• 네임서버(nameserver)는 운영자가 직접 구축할 수도 있지만 대부분의 경우 등록대행자(등록대행업체 : 카페24, 닷홈 등)가 네임서버를 제공
• 무료로 제공되는 네임서버(nameserver)도 이용 가능

2. 두번째 작업

• hippo 서버는 hippotest.com을 쓰고 싶다고 등록대행자에게 요청 → 수수료를 지불
• 수수료로 도메인 등록 체계가 운영
• 요청하는 과정에서 "hippotest.com NS a.iana-servers.net"이라는 정보를 등록대행자에 알려주게 됨

3. 세번째 작업

• 등록대행자는 등록소에 hippotest.com을 등록하는것이 가능한지 요청
• "hippotest.com NS a.iana-servers.net"이라는 정보를 등록소에 알려줌

4. 네번째 작업

• 등록소는 hippotest.com이 등록가능한지 여부를 조회하고 등록가능하다면 계약된 기간동안 해당 도메인이 사용가능하다는 것을 알려줌
• hippotest.com의 소유권을 등록대행자를 통해서 등록자가 인식할 수 있도록 통보 → 소유권이 없는 다른 사람이 사용하지 못하도록 설정 필요
• "hippotest.com NS a.iana-servers.net"이라는 정보를 등록소가 관리하는 Top-level DNS 서버에 저장 → 등록자의 네임서버를 알게됨

5. 다섯번째 작업

• 클라이언트 컴퓨터는 인터넷에 접속하자마자 자신이 지정한 또는 통신사에서 지정한 DNS 서버에 자동으로 접속하게 됨

6. 여섯번째 작업

• hippotest.com의 IP 주소를 Root DNS 서버에 요청
• Root DNS 서버는 .com을 관리하는 Top-level DNS 서버의 주소인 a.gtld-servers.net로 가보라고 알려줌

7. 일곱번째 작업

• Top-level DNS 서버의 주소인 a.gtld-servers.net에 hippotest.com의 IP주소를 요청
• Top-level DNS 서버는 hippo 네임서버 주소인 a.iana-servers.net으로 가보라고 알려줌

8. 여덟번째 작업

• hippotest.com 네임서버 주소인 a.iana-servers.net에 hippotest.com의 IP주소를 요청
• hippotest.com 네임서버는 "hippotest.com의 IP 주소는 118.222.88.11입니다."라고 클라이언트 컴퓨터의 지정된 DNS서버로 알려줌

9. 아홉번째 작업

• 지정한 DNS 서버는 hippotest.com의 IP 주소를 알게됨 → 전달받은 서버 IP인 118.222.88.11를 통해 hippotest.com 웹사이트와 통신 가능

참고 URL : https://boojafactory.tistory.com/172