확장성 프로비저닝 프로토콜
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
확장성 프로비저닝 프로토콜(EPP)은 레지스트리 시스템 간의 비호환성 문제를 해결하기 위해 개발된 프로토콜이다. 2000년 베리사인의 스콧 홀렌벡이 IETF에 초안을 제출했으며, 2009년 IETF에서 표준으로 승인되었다. EPP는 세션 관리, 쿼리, 객체 변환 등의 명령어를 포함하며, XML을 사용하여 구조화된 텍스트 형식으로 데이터를 교환한다. 이 프로토콜은 DNSSEC, IDN, 프리미엄 도메인 이름 등 다양한 확장 기능을 지원하며, 보안을 위해 TLS 사용과 클라이언트 인증서 사용을 권장한다. .com, .net, .org 등 모든 gTLD와 여러 ccTLD에서 채택되었으며, 대한민국에서도 .kr 도메인 및 주요 gTLD 등록 대행자에서 사용되고 있다.
더 읽어볼만한 페이지
- 도메인 네임 시스템 - 국제화 국가 코드 최상위 도메인
국제화 국가 코드 최상위 도메인은 다양한 언어의 문자를 국가 코드 최상위 도메인에 사용할 수 있도록 하는 시스템으로, 2009년부터 신청을 받아 아랍어, 러시아어, 중국어 등 다양한 국가에서 도입되었으나 혼동 가능성과 보안 문제 등의 과제도 안고 있다. - 도메인 네임 시스템 - DNSSEC
DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다. - XML 기반 표준 - XAML
XAML은 마이크로소프트에서 개발한 XML 기반의 마크업 언어로, 사용자 인터페이스, 데이터 바인딩, 이벤트 처리 등을 정의하며 WPF, Silverlight, WF, WinRT API 앱, Xamarin.Forms 등에서 UI 개발에 널리 사용된다. - XML 기반 표준 - 아톰 (표준)
Atom은 웹 사이트 업데이트 정보와 콘텐츠 배포를 위한 XML 기반 문서 형식으로, Atom 배포 형식과 Atom 출판 프로토콜로 구성되어 있으며, RSS를 대체하기 위해 고안되었고 국제화 지원 및 모듈성에서 차이를 보인다.
| 확장성 프로비저닝 프로토콜 | |
|---|---|
| 기본 정보 | |
| 종류 | 컴퓨터 네트워크 프로토콜 |
| 약칭 | EPP |
| 목적 | 도메인 이름 등록 및 갱신과 같은 자동화된 도메인 이름 트랜잭션 |
| 개발자 | 인터넷 엔지니어링 태스크 포스(IETF)의 스콧 홀렌벡 |
| 날짜 | 2009년 |
| OSI 모델 계층 | 응용 계층 |
| 포트 | 700 |
| RFC | RFC 5730 RFC 5731 RFC 5732 RFC 5733 RFC 5734 |
2. 역사
EPP는 도메인 네임 레지스트리와 도메인 네임 등록 대행자 간의 통신을 표준화하고, 도메인 이름 등록 및 갱신 과정을 안정화하여 도메인 하이재킹을 방지할 목적으로 개발되었다. EPP 이전에는 레지스트리마다 서로 다른 독자적인 인터페이스를 사용하여 표준화의 필요성이 제기되었다. EPP는 구조화된 텍스트 형식인 XML에 기반하며, 주로 TCP를 통해 전송되지만, BEEP, SMTP, SOAP 등 다른 전송 프로토콜과도 사용될 수 있도록 유연하게 설계되었다.
EPP의 표준화 과정은 2000년 11월 Verisign의 Scott Hollenbeck이 첫 번째 인터넷 초안 문서를 IETF에 제출하면서 시작되었다.[2] 이 문서는 2000년 12월 IETF ''프로비저닝 레지스트리''(''provreg'') 워킹 그룹에 채택되어 공식적인 표준화 과정을 밟게 되었다.[3] 이후 표준화 단계를 거쳐, 2004년 3월에는 RFC 편집자에 의해 제안 표준(RFC 3730-3734)으로,[4] 2007년 5월에는 초안 표준(RFC 4930-4934)으로 공표되었다.[5] 마침내 2009년 8월, IETF는 EPP를 완전한 인터넷 표준으로 인정하고 STD 69 지위를 부여하였다.[6]
2. 1. 개발 배경
EPP(확장성 프로비저닝 프로토콜)가 개발되기 이전에는 도메인 네임 레지스트리들이 공통된 표준 없이 각자 다른 독자적인 인터페이스를 사용했다. 이로 인해 도메인 네임 등록 대행자와의 통신에 호환성 문제가 발생했고, 시스템 운영 및 유지보수에 어려움이 있었다. EPP는 이러한 문제를 해결하고, 레지스트리와 등록 대행자 간의 통신을 유연하고 안정적으로 제공하기 위해 만들어졌다. 또한, 도메인 이름 등록 및 갱신 과정을 표준화하여 도메인 하이재킹을 방지하는 목적도 가지고 있다.이러한 배경 속에서 Verisign의 Scott Hollenbeck은 2000년 11월, EPP의 첫 번째 초안을 IETF에 개인 제출 인터넷 초안 문서로 발표했다.[2] 이 초안은 2000년 12월 IETF-49에서 열린 BoF(Birds of a Feather) 세션 이후 결성된 IETF ''프로비저닝 레지스트리''(''provreg'') 작업 그룹에 의해 채택되었다.[3] 이후 표준화 과정을 거쳐 2004년 3월에는 RFC 편집자에 의해 제안 표준(RFC 3730-3734)으로 공표되었고,[4] 2007년 5월에는 초안 표준(RFC 4930-4934)으로 발전했다.[5] 마침내 2009년 8월, IETF는 EPP를 완전한 인터넷 표준(STD 69)으로 인정하였다.[6]
2. 2. IETF 표준화
초기 프로토콜 초안은 2000년 11월 베리사인의 스콧 홀렌벡(Scott Hollenbeck)에 의해 IETF 개인 제출 인터넷 초안 문서로 발표되었다.[2] 이 문서는 2000년 12월 IETF-49에서 BoF(Birds of a Feather) 세션 이후 결성된 IETF ''프로비저닝 레지스트리''(''provreg'') 워킹 그룹에 의해 채택되었다.[3]RFC 편집자는 2004년 3월 제안 표준(Proposed Standard) 문서(RFC 3730 - 3734)를 발표하였다.[4] 첫 번째 EPP 확장 기능인 구제 유예 기간 확장 기능(RFC 3915)은 2004년 9월 제안 표준으로 발표되었으며,[18] 이후 여러 제안 표준 확장 기능들이 뒤따랐다.[20]
2007년 5월에는 초안 표준(Draft Standard) 문서(RFC 4930 - 4934)가 발표되었다.[5] 2009년 8월, IETF는 EPP를 완전한 표준(Full Standard)으로 인정하고 STD 69 지위를 부여했다.[6]
3. 프로토콜 구성
EPP는 도메인 네임 레지스트리와 도메인 네임 등록 대행자 간의 통신을 유연하고 견고하게 제공하려는 목적으로 만들어졌다. 이 프로토콜은 도메인 이름이 등록되거나 갱신될 때마다 사용되는 일련의 트랜잭션들을 정의하며, 이를 통해 도메인 하이재킹을 방지하는 데 도움을 준다. EPP가 만들어지기 전에는 인터넷 레지스트리들이 공통된 표준 없이 서로 다른 독자적인 인터페이스를 사용하였기 때문에 이러한 표준 프로토콜의 필요성이 제기되었다. EPP는 기본적으로 도메인 이름 정보를 다루기 위해 만들어졌지만, 명령/실행 형태의 시스템이라면 어떤 시스템에서도 쓰일 수 있도록 설계되었다.
EPP 표준화 과정은 Verisign의 Scott Hollenbeck이 2000년 11월 IETF에 첫 번째 초안을 제출하면서 시작되었다. 이 초안들은 2000년 12월 IETF 49차 회의의 BoF 세션 이후 결성된 ''Provisioning Registry''(''provreg'') 워킹 그룹에 채택되었다. 이후 여러 차례의 개정을 거쳐 2004년 3월에는 Proposed Standard(RFC 3730-3734)로, 2007년 5월에는 Draft Standard(RFC 4930-4934)로 공표되었으며, 마침내 2009년 8월 IETF는 EPP를 완전한 인터넷 표준(IETF STD 69)으로 인정하였다.
3. 1. 기본 구조
EPP는 구조화된 텍스트 형식인 XML에 기반을 둔다. 하부 네트워크 전송 계층은 정해져 있지 않으나, 현재는 TCP만이 쓰이고 있다. 하지만 BEEP, SMTP 또는 SOAP와 같은 다른 전송 계층 프로토콜과도 쓰일 수 있도록 유연하게 설계되었다.3. 2. 명령어 종류
EPP(Extensible Provisioning Protocoleng)의 명령어는 크게 세션 관리, 쿼리, 객체 변환의 세 가지 유형으로 나뉜다.[1] 이러한 명령어들은 특정 객체와 연결되어 해당 객체의 기능을 보다 구체적으로 정의하고 실행하는 역할을 한다. 가장 일반적으로 사용되는 표준 객체로는 호스트[11], 연락처[12], 그리고 도메인[13]이 있다. 조직과 같은 다른 표준 객체도 존재하지만[14], 상대적으로 사용 빈도는 낮다.3. 2. 1. 세션 관리
클라이언트가 EPP 서버에 연결하면, 서버는 즉시 클라이언트에게 "인사" 메시지를 보낸다. 이 메시지에는 클라이언트가 연결하는 데 필요한 서버 정보가 포함되어 있다. 여기에는 서버의 이름, 서버의 현재 UTC 날짜와 시간, 지원되는 기능 및 개인 정보 보호 정책이 포함된다. 지원되는 기능에는 EPP 버전, 언어, 객체 및 확장이 포함된다.[1]세션 관리 명령어는 클라이언트와 서버 간의 연결 및 세션을 관리하는 데 사용되며, 다음과 같다.[1]
| 명령어 | 사용법 |
|---|---|
| hello | 서버로부터 다른 "인사" 응답을 요청한다. |
| login | 새 세션을 시작한다. 이 세션은 logout 명령어를 사용하거나 서버가 사용자를 로그아웃시킬 때까지 유지된다. 또한, 비밀번호를 변경하는 데에도 사용된다. 클라이언트는 로그인 시 "인사" 메시지에 명시된 EPP 버전 중 하나와 언어 하나를 선택해야 한다. 또한 서버에서 지원하며 해당 세션에서 사용하려는 모든 객체와 확장 기능도 선택해야 한다. |
| logout | 현재 세션을 종료한다. |
3. 2. 2. 쿼리
쿼리 명령어는 객체의 상태를 확인하거나 정보를 조회하는 데 사용된다.[1]| 명령어 | 사용법 |
|---|---|
| check | 객체를 여전히 생성할 수 있는지 확인한다. |
| info | 객체에 대한 모든 현재 정보를 가져온다. |
| poll | 사용자를 위해 서버로부터 메시지를 읽거나, 메시지 수신을 승인하여 다음 메시지를 받기 위해 삭제한다. (메시지 큐) |
| transfer | 시작된 객체 전송 프로세스의 현재 상태를 가져온다. |
3. 2. 3. 객체 변환
객체 변환 명령어는 객체를 생성, 삭제, 갱신, 이전, 업데이트하는 데 사용된다.[1] 객체 변환 명령어의 종류와 사용법은 다음과 같다.| 명령어 | 사용법 |
|---|---|
| create | 새로운 객체를 생성한다. |
| delete | 객체를 삭제한다. 호스트 및 연락처 객체는 즉시 삭제되지만, 도메인 객체는 대부분 구제 기간 상태로 변경된다. |
| renew | 도메인 이름의 등록 기간을 연장한다. 수명 개념이 없는 도메인이 아닌 객체(예: 호스트, 연락처)에는 사용할 수 없다. |
| transfer | 객체의 등록 기관 또는 소유자를 변경한다. 수신 전송 프로세스를 시작하거나 취소하고, 발신 전송을 승인하거나 거부하는 데 사용될 수 있다. |
| update | 객체의 정보를 업데이트한다. 일반적으로 도메인 소유자 변경과 같은 작업도 포함될 수 있으나, TLD에 따라 이러한 작업의 절차가 복잡하여 EPP 확장을 통해 구현되는 경우가 많다. |
3. 3. 확장 기능
EPP는 기본 명령을 변경하지 않고도 레지스트리가 새로운 기능을 추가할 수 있도록, 거의 모든 명령에 확장 객체를 전송하는 기능을 제공한다.[1] 이를 통해 프로토콜의 유연성을 높이고 변화하는 인터넷 환경의 요구사항에 효과적으로 대응할 수 있다.다수의 레지스트리에서 공통적으로 사용되는 표준화된 확장은 다음과 같다.
- DNSSEC (Domain Name System Security Extensions)[15]: 도메인 이름 시스템의 보안을 강화하기 위한 확장이다.
- IDN (Internationalized Domain Name)[16]: 다양한 언어의 문자를 도메인 이름에 사용할 수 있도록 지원한다.
- 프리미엄 도메인 이름[17]: 가치가 높은 특정 도메인 이름을 관리하기 위한 확장이다.
- 도메인 복원 (RGP, Redemption Grace Period)[18]: 만료된 도메인을 복구할 수 있는 유예 기간 관련 처리를 지원한다.
- 새로운 TLD 출시 처리 확장[19]: 새로운 최상위 도메인이 도입될 때 필요한 절차를 관리한다.[20]
또한, 일부 레지스트리는 특정 TLD의 고유한 요구사항을 충족시키기 위해 자체적인 확장을 개발하여 사용하기도 한다. 예를 들어, 특정 TLD 등록 시 부가 가치세 식별 번호와 같은 추가적인 등록자 정보를 수집하기 위해 비표준화된 확장을 활용하는 경우가 있다.[20]
4. 보안 고려 사항
EPP는 일반 텍스트 비밀번호만 제공하며, EPP 로그인 비밀번호 유형은 6~16자 길이의 문자열로 지정되어 있는데[1] 이는 오늘날의 표준에 비해 보안 수준이 매우 낮다고 볼 수 있다. 따라서 TCP를 통한 연결은 반드시 TLS를 사용해야 하며, 클라이언트 인증서 사용과 클라이언트 및 서버의 정확한 신원 확인이 강력히 권장된다.[21]
또한 많은 도메인 네임 레지스트리는 EPP 서버 연결을 위해 IP 화이트리스트 설정을 제공한다.
EPP는 클라이언트가 생성하는 `clTRID`를 통해 재전송 공격에 대한 일부 보호 기능을 제공하지만, 이는 선택 사항이므로 모든 서버 소프트웨어에서 사용되지는 않는다. 따라서 사용되는 전송 메커니즘에서 추가적인 재전송 방지 메커니즘을 구현해야 한다.[1]
5. 채택 현황
확장성 프로비저닝 프로토콜(EPP)은 도메인 네임 레지스트리와 도메인 네임 등록 대행자 간의 통신 표준으로, 전 세계적으로 널리 채택되어 사용되고 있다. 이 프로토콜은 gTLD와 다수의 ccTLD 레지스트리에서 표준으로 자리 잡았다.
특히, 도메인 네임 등록 대행자 간에 주요 최상위 도메인을 이전할 때 EPP 인증 정보(인증 코드 또는 키)가 요구되는 등, 도메인 관리의 안정성과 보안성을 높이는 데 중요한 역할을 한다.
5. 1. 국제 현황
ICANN은 기본 등록 계약에서 EPP 서비스 제공을 의무화했기 때문에, .com, .net, .org 등을 포함한 모든 gTLD는 이 프로토콜을 채택했다.또한, 확장성 프로비저닝 프로토콜은 아래 표와 같이 다수의 ccTLD 등록 기관에서도 채택되었다.
ENUM 레지스트리 중 +31, +41, +43, +44, +48 국가 코드를 운영하는 곳에서도 EPP를 사용한다.
EPP 서버 소프트웨어는 여러 오픈 소스 구현이 존재한다. 국가 코드 관리자 협의회(CoCCA)는 약 59개의 ccTLD와 6개의 gTLD에서 사용되는 EPP 서버 소프트웨어를 유지 관리하고 있다. CZ.NIC에서 유지 관리하는 FRED는 11개의 ccTLD에서 사용되고 있다.
5. 2. 대한민국 현황
최상위 도메인(.kr) 운영에 대한 직접적인 정보는 부족하지만, 대한민국의 인터넷 사용 환경과 밀접한 관련이 있는 gTLD 영역에서는 확장성 프로비저닝 프로토콜(EPP)이 표준으로 사용되고 있다. ICANN은 모든 gTLD 등록 기관에 대해 기본 등록 계약 조건으로 EPP 서비스 제공을 의무화하였으므로, .com, .net, .org, .biz, .info, .asia 등 주요 gTLD들은 모두 EPP를 통해 도메인 등록 및 관리 시스템을 운영한다.특히, 도메인 네임 등록 대행자 간에 .com, .net, .org, .biz, .info와 같은 gTLD를 이전할 때는 EPP 인증 정보(authInfo) 코드 또는 키가 필수적으로 요구된다. 이는 한국 내 도메인 등록 대행 업체들이 국제적인 gTLD 등록 서비스를 제공할 때 EPP 규약을 준수해야 함을 의미한다. .com과 .net 도메인의 경우, 2006년 4분기부터 EPP 키만을 요구하는 방식으로 변경되었다.
5. 3. 오픈 소스 구현
EPP 서버 소프트웨어의 여러 오픈 소스 구현이 존재한다. 국가 코드 관리자 협의회(CoCCA)는 약 59개의 ccTLD와 6개의 gTLD에서 사용되는 EPP 서버 소프트웨어를 유지 관리한다. 또 다른 오픈 소스 소프트웨어는 FRED(CZ.NIC에서 유지 관리)이며, 11개의 ccTLD가 이를 사용하고 있다.참조
[1]
논문
Extensible Provisioning Protocol (EPP)
https://www.rfc-edit[...]
2009-08
[2]
뉴스
Extensible Provisioning Protocol
https://datatracker.[...]
2023-03-13
[3]
웹사이트
IETF December 2000 Proceedings
https://www.ietf.org[...]
2023-03-13
[4]
논문
Extensible Provisioning Protocol (EPP)
https://www.rfc-edit[...]
2004-03
[5]
논문
Extensible Provisioning Protocol (EPP)
https://www.rfc-edit[...]
2007-05
[6]
논문
Extensible Provisioning Protocol (EPP)
https://www.rfc-edit[...]
2009-08
[7]
웹사이트
Implementation Report for RFCs 4930-4934 - Wayback Machine
http://www.ietf.org/[...]
2023-03-12
[8]
웹사이트
ICANN base registry contract
https://newgtlds.ica[...]
2023-03-12
[9]
웹사이트
Official CoCCA website
https://cocca.org.nz[...]
2023-03-12
[10]
웹사이트
Introducing FRED - fred
https://fred.nic.cz/[...]
2023-03-12
[11]
논문
Extensible Provisioning Protocol (EPP) Host Mapping
https://www.rfc-edit[...]
2009-08
[12]
논문
Extensible Provisioning Protocol (EPP) Contact Mapping
https://www.rfc-edit[...]
2009-08
[13]
논문
Extensible Provisioning Protocol (EPP) Domain Name Mapping
https://www.rfc-edit[...]
2009-08
[14]
논문
Extensible Provisioning Protocol (EPP) Organization Mapping
https://www.rfc-edit[...]
2019-03
[15]
논문
Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
https://www.rfc-edit[...]
2010-05
[16]
뉴스
Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)
https://datatracker.[...]
2023-03-11
[17]
논문
RFC 8748: Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
https://www.rfc-edit[...]
2023-03-11
[18]
논문
Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
https://www.rfc-edit[...]
2004-09
[19]
논문
Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
https://www.rfc-edit[...]
2018-03
[20]
웹사이트
Extensions for the Extensible Provisioning Protocol (EPP)
https://www.iana.org[...]
2023-03-11
[21]
논문
Extensible Provisioning Protocol (EPP) Transport over TCP
https://www.rfc-edit[...]
2009-08
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com