NAPTR 레코드
NAPTR recordNAPTR(Name Authority Pointer)는 인터넷의 도메인 네임 시스템에 있는 자원 기록의 한 유형이다.[1][2]
NAPTR 레코드는 예를 들어 SIP(Session Initiation Protocol)의 서버 및 사용자 주소 매핑에서 인터넷 전화의 애플리케이션에 가장 일반적으로 사용된다.NAPTR 레코드를 서비스 레코드(SRV)와 결합하면 복수의 레코드를 체인으로 묶어 새로운 도메인 라벨이나 통일된 리소스 식별자(URI)를 생성하는 복잡한 다시 쓰기 규칙을 형성할 수 있다.
NAPTR 레코드의 DNS 유형 코드는 35이다.[1]
이론적 근거
URN(Uniform Resource Name)은 개인의 이름이나 전화번호와 같은 추상 식별자에 사용되는 URI(Uniform Resource Identifier)의 하위 집합이다.URN이 의미 있으려면, 어떤 종류의 구체적인 자원에 매핑되어야 한다.균일한 자원 로케이터(URL)는 종종 컴퓨터 호스트 이름이나 로컬 파일과 같은 자원을 설명하는데 사용된다.
NAPTR 레코드는 URN의 표준화에 도움이 된다. NAPTR 레코드 맵은 URN 세트, URL 및 일반 도메인 이름 사이의 것이며 매핑된 리소스와 통신할 수 있는 프로토콜을 고객에게 제안한다.[3]각 NAPTR 레코드에는 서비스 이름, 플래그 세트, 정규식 규칙, 주문 값, 기본 설정 및 대체 패턴이 포함되어 있다.여러 개의 레코드를 계단식으로 묶어 결정론적인 방법으로 URI를 다시 작성할 수 있다.이러한 계단식 규칙은 RFC2915 및 RFC3403에서 표준화되었다.
예
NAPTR 레코드의 일반적인 용도는 세션 개시 프로토콜에 있으며, 여기서 IP 네트워크를 통해 전화 세션을 라우팅하는 데 사용된다.예를 들어 미국 전화 번호 1-800-555-1234의 SIP URN은 tel:+1-800-555-1234 및 도메인 이름 4.3.2.1.5.5.5.0.0.8.1.e164.arpa일 수 있다.해당 이름을 쿼리하는 SIP 클라이언트는 다음을 받을 수 있다.
$ORGIN 4.3.2.1.5.5.5.0.0.8.1.e164.arpa.IN NAPTR 100 10 "U" "E2U+sip" "!^"*$!customer-service@example.com! .IN NAPTR 102 10 "U" "E2U+이메일"!^*$!mailto:information@example.com!"
1차 기록의 오더 값은 100으로 102보다 낮아 우선권이 있다.순서가 100인 다른 규칙이 없기 때문에 선호도 10은 중요하지 않다.서비스 이름 E2U+sip은 이 레코드를 전화 번호-SIP-URI 쿼리에 사용할 수 있음을 나타내는 ENUM 문자열이다.[4]고객은 정규식을 적용한다!^*$!customer-service@example.com!, 전체 URN 텔:+1-800-555-1234를 sip:customer-service@example.com으로 대체.U 플래그는 교체 문자열이 SIP URN이며, 더 이상의 규칙을 적용해서는 안 된다는 것을 나타낸다.
SIP URN을 해결하기 위해 클라이언트는 example.com에서 두 번째 NAPTR 조회를 수행하며 다음과 같은 결과를 제공한다.
$ORGIN example.com.IN NAPTR 100 10 "S" "SIP+D2U"!^*$!customer-service@example.com!" _reason._reason.example.com.IN NAPTR 102 10 "S" "SIP+D2T" "!^"*$!customer-service@example.com!" _reason._reason.example.com.
첫 번째 예시와 같이 발주 값이 가장 낮기 때문에 고객이 첫 번째 레코드를 선택한다.정규식 규칙은 쿼리 URN을 대체하며, 이번에는 도메인 이름 _sip으로 대체한다._reason.example.com.S 플래그는 결과 도메인 이름이 SRV 레코드를 가리킨다는 것을 나타낸다.따라서 고객은 _sip으로 마무리한다._reason.example.com. 이 경우 SRV 레코드를 가져와 전화 통화를 시작할 수 있다.
지원
| 노점상 | 제품 | NAPTR 지원? |
|---|---|---|
| ISC | 바인딩 | 네 |
| CZ.NIC | 매듭 DNS | 네 |
| 시스코 시스템즈 | CNR | 네 |
| 대니얼 J. 번스타인 | djbdns. | 일반 레코드 또는 패치 |
| 블루캣 네트워크 | 무결성 | 네 |
| 능률IP | SOLID서버 | 네 |
| 구글 | Google 클라우드 DNS | 네[5] |
| 인포블록스 | Infoblox Trinzic 어플라이언스 | 네 |
| 마이크로소프트 | Windows Server 2003 DNS 서버 | 아니요. |
| 마이크로소프트 | 윈도우즈 서버 2008 R2 DNS 서버 | 네 |
| 마이크로소프트 | 아즈레 DNS | 아니요. |
| NS1 | mDNS 및 DDI | 네 |
| PowerDNS/Open-Xchange | 파워DNS | 네 |
| NLnet 연구소 | NSD | 네 |
| 아마존 웹 서비스 | 아마존로53번길 | 네 |
| 샘 트렌홀름 | 마라덴스 | 버전 1.4 on[6] |
| Unixservice, LLC. | unxsBind | 네 |
| 사이먼 켈리 | 디즈마스크 | 네 |
| F5 네트워크 | F5 네트워크 BIG-IP DNS | 네 |
| OVH | DNS | 네 |
| DNS.com | 51DNS DNS | 아니요. |
| Citrix Systems | NetScaler GSLB | 네 |
| 스놈 | Snom VoIP 전화 | 네 |
| 얄링크 | 얄링크 폰스 | 네 |
| Voip 다이얼링 | 네 | |
| 클라우드플레어 | Cloudflare Authorized DNS | 네 |
| 무선 광대역 연합 | 오픈로밍 | 네 |
여러 NAPTR 레코드를 반환하는 응답은 일반적으로 일반적인 512바이트 패킷 크기 제한보다 크며 그렇지 않으면 UDP보다는 TCP에 대한 효율성이 떨어지기 때문에 NAPTR 구현도 일반적으로 EDNS를 구현한다.
참조
- ^ a b Mealling, M; Daniel, R (2000), RFC2915: The Naming Authority Pointer (NAPTR) DNS Resource Record, IETF Network Working Group
- ^ Mealling, M (2002), RFC3403: Dynamic Delegation Discovery System (DDDS), Part Three: The Domain Name System (DNS) Database, IETF Network Working Group
- ^ Sollins, K (1998), RFC2276: Architectural Principles of Uniform Resource Name Resolution, IETF Network Working Group
- ^ van der Berg, Rudolf (2010-01-13), ENUM: Dragging telephone numbers into the Internet Age, Ars Technica
- ^ "CloudDNS Documentation". Retrieved 2018-04-25.
- ^ "Updating MaraDNS". Retrieved 2009-01-17.
