NAPTR 레코드: 동적 위임 탐색

전화 시스템과 인터넷은 각자의 길을 걸으며 성장했습니다. 전화번호는 E.164 방식을 따릅니다. 회선 교환망을 위해 설계된 계층적 체계입니다. 인터넷 주소는 DNS를 따릅니다. 패킷 교환망을 위해 설계된 계층적 체계입니다. 두 체계 모두 상대방의 언어를 말할 줄 모릅니다.

NAPTR 레코드가 바로 그 번역기입니다.

전화번호를 누르면 VoIP 서비스로 연결될 때, 또는 SIP 클라이언트가 도메인을 처리하는 서버를 찾을 때, NAPTR 레코드가 변환 작업을 수행합니다. 하나의 네임스페이스에서 식별자를 받아 패턴 매칭 규칙을 통해 다른 네임스페이스의 식별자로 변환합니다.

6개 필드 구조

NAPTR(Naming Authority Pointer) 레코드는 DNS 레코드 유형 중 가장 복잡한 형식을 갖고 있습니다:

example.com. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .

6개의 필드가 있으며, 각각 특정한 역할을 담당합니다:

순서 (100): 어떤 레코드를 먼저 처리할지 결정합니다. 숫자가 낮을수록 우선입니다. 가장 낮은 순서 값을 가진 레코드만 고려 대상이 됩니다.

우선순위 (10): 동일한 순서 값을 가진 레코드들 사이의 순위를 결정합니다. 마찬가지로 낮은 값이 우선합니다.

플래그 ("u"): 결과를 어떻게 처리할지 지정합니다. "u"는 출력이 URI임을 의미하며, 처리가 완료됩니다. "s"는 다음에 SRV 레코드를 조회함을 의미합니다. "a"는 다음에 A/AAAA 레코드를 조회함을 의미합니다. 비어 있으면 NAPTR 레코드 처리를 계속합니다.

서비스 ("E2U+sip"): 이 규칙이 처리하는 서비스와 프로토콜을 지정합니다. "E2U"는 ENUM(전화번호를 URI로 변환)을 의미합니다. "SIP+D2T"는 TCP 기반 SIP를 의미합니다.

정규식 ("!^.*$!sip:info@example.com!"): 입력값을 변환하는 정규식입니다. 구분자(보통 "!")가 매칭 패턴과 교체 문자열을 분리합니다.

대체 (.): 추가 DNS 조회가 필요할 때 다음에 찾을 위치입니다. 점(.)은 없음을 의미하며, 정규식 출력이 최종 결과입니다.

ENUM: 전화번호가 인터넷 주소로

ENUM(E.164 번호 매핑)은 NAPTR의 대표적인 활용 사례입니다. "이 전화번호로 이 사람에게 도달할 수 있는 인터넷 리소스는 무엇인가?"라는 질문에 답합니다.

변환 방식은 다소 이상하면서도 구체적입니다. +1-555-123-4567을 예로 들면, 서식을 제거하고, 숫자를 역순으로 배열하고, 각 숫자 사이에 점을 삽입한 후, e164.arpa를 뒤에 붙입니다:

7.6.5.4.3.2.1.5.5.5.1.e164.arpa

전화번호가 DNS가 읽을 수 있는 도메인 이름이 됩니다. 해당 도메인에서 NAPTR 레코드를 조회합니다:

7.6.5.4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:15551234567@voip.example.com!" .
7.6.5.4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 20 "u" "E2U+email" "!^.*$!mailto:user@example.com!" .
7.6.5.4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 30 "u" "E2U+web:http" "!^.*$!http://www.example.com/contact!" .

이 전화번호 소유자에게 도달하는 세 가지 방법: SIP 통화(우선순위 10), 이메일(우선순위 20), 웹 폼(우선순위 30). 애플리케이션은 자신이 지원하는 방식을 선택합니다.

SIP 라우팅: 프로토콜과 서버 선택

SIP(Session Initiation Protocol) 시스템은 NAPTR를 이용해 다른 질문에 답합니다: SIP 도메인에 연결할 때 어떤 전송 프로토콜과 서버를 사용해야 할까요?

user@example.com에 연결하려는 클라이언트는 example.com에서 NAPTR 레코드를 조회합니다:

example.com. IN NAPTR 100 10 "s" "SIP+D2T" "" _sip._tcp.example.com.
example.com. IN NAPTR 100 20 "s" "SIP+D2U" "" _sip._udp.example.com.
example.com. IN NAPTR 100 30 "s" "SIPS+D2T" "" _sips._tcp.example.com.

"s" 플래그는 이렇게 말합니다: 대체 필드를 가져다 SRV 레코드를 조회하세요. 이것이 연쇄 조회를 만들어냅니다:

1. NAPTR 레코드가 전송 프로토콜을 결정합니다 (TCP가 UDP보다 우선, 둘 다 TLS보다 우선)
2. _sip._tcp.example.com의 SRV 레코드가 특정 서버, 포트, 부하 분산 가중치를 식별합니다
3. A/AAAA 레코드가 실제 IP 주소를 제공합니다

세 번의 DNS 조회, 각각 다른 질문에 답합니다: 어떤 프로토콜, 어떤 서버, 어떤 주소.

위임 체인

NAPTR 레코드는 거의 단독으로 작동하지 않습니다. 일반적인 패턴은 다음과 같습니다:

1. NAPTR를 조회하여 서비스와 프로토콜 결정
2. NAPTR의 "s" 플래그가 SRV 레코드로 위임
3. SRV를 조회하여 서버, 포트, 우선순위, 가중치 파악
4. A/AAAA를 조회하여 서버 이름을 IP 주소로 해석
5. 연결

이러한 분리는 중요한 의미를 가집니다. 관리자는 서비스 정책(NAPTR 레코드)을 건드리지 않고도 서버 인프라(SRV 및 A/AAAA 레코드)를 변경할 수 있습니다. 프로토콜 우선순위와 부하 분산은 서로 다른 레이어에 존재하며, 독립적으로 업데이트됩니다.

정규식의 힘

정규식 필드는 단순한 문자열 대체 이상을 할 수 있습니다. 패턴 그룹을 사용하면 정교한 변환이 가능합니다:

e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^\\+1(555)([0-9]{7})$!sip:\\2@sip.example.com!" .

이 패턴은 +1-555 번호에 매칭되고, 뒤 7자리 가입자 번호 부분을 캡처하여, 해당 부분만으로 SIP URI를 구성합니다. 다른 지역 코드는 다른 서버로 라우팅될 수 있습니다. 프리미엄 번호는 전문 처리기로 라우팅될 수 있습니다.

NAPTR 레코드가 사용되는 곳

대부분의 DNS 관리자는 NAPTR 레코드를 직접 다루지 않습니다. 특수한 환경에서만 등장합니다:

• 전화 인프라: ENUM 또는 SIP 라우팅을 구현하는 통신사와 기업
• 대형 서비스 제공자: 통합 식별자를 통해 여러 프로토콜을 제공하는 조직
• 표준 의무 통합: NAPTR를 요구하는 RFC를 구현하는 시스템

복잡한 구조 탓에 신중한 테스트가 필요합니다. 잘못된 정규식은 전체 조회를 망칩니다. 잘못된 플래그는 무한 루프나 막다른 길을 만들어냅니다. 디버깅은 전체 체인을 추적해야 합니다—NAPTR에서 SRV, A/AAAA까지—어느 단계에서 실패하든 증상은 같기 때문입니다: 연결 거부.

캐싱은 이를 더 골치 아프게 만듭니다. NAPTR 레코드의 TTL이 1시간이지만 SRV 레코드의 TTL이 24시간이라면, 새 인프라를 가리키도록 NAPTR를 업데이트해도 클라이언트는 캐시된 SRV를 따라 최대 하루 동안 폐기된 서버로 계속 연결을 시도합니다. 조회 체인은 그 안에서 가장 오래된 링크만큼만 신선합니다.

NAPTR 레코드에 관해 자주 묻는 질문

ENUM 조회에서 전화번호를 왜 역순으로 배열하나요?

DNS는 오른쪽에서 왼쪽으로 계층적으로 읽습니다—example.com은 "com을 찾고, 그 안에서 example을 찾아라"를 의미합니다. 전화번호는 왼쪽에서 오른쪽으로 계층적입니다—+1-555는 "국가 1, 그 다음 지역 555"를 의미합니다. 숫자를 역순으로 배열하면 전화번호의 계층 구조가 DNS의 계층 구조와 맞아떨어져, 각 수준에서 위임이 가능해집니다.

여러 NAPTR 레코드가 동일한 순서와 우선순위를 가지면 어떻게 되나요?

애플리케이션이 임의로 선택합니다. 이는 부하 분산을 위한 의도적인 설계입니다—결정적 동작을 원한다면 서로 다른 우선순위 값을 사용하세요. 무작위 분산을 원한다면 동일한 값을 사용하세요.

NAPTR 레코드가 IP 주소를 직접 가리킬 수 있나요?

아니요. 대체 필드는 반드시 도메인 이름이거나 비어 있어야 합니다. IP 주소로의 최종 해석을 위해 NAPTR는 A/AAAA 레코드로 위임("a" 플래그 사용)하거나, 먼저 SRV 레코드를 통해 체인을 이어갑니다("s" 플래그 사용).

NAPTR 레코드 설정을 어떻게 테스트하나요?

dig NAPTR example.com 명령을 사용하여 NAPTR 레코드를 직접 조회합니다. ENUM 테스트를 위해서는 먼저 전화번호를 역순 e164.arpa 형식으로 변환합니다. 전체 체인을 추적하세요: NAPTR → SRV → A/AAAA로 각 위임 단계가 올바르게 해석되는지 확인합니다.