[네트워크] DNS

 

네트워크 프로토콜은 크게 데이터 프로토콜과 컨트롤 프로토콜로 크게 나눌 수 있다.

• 데이터 프로토콜
  • 실제 데이터의 전송을 담당
• 컨트롤 프로토콜
  • 데이터 프로토콜을 지원하며 통신 관계를 설정하고 유지하는 역할
  • TCP/IP 프로토콜 체계에서 주요 컨트롤 프로토콜로는 ARP, ICMP, DNS가 있다.

DNS(Domain Name System)는 도메인 주소를 IP 주소로 변환하는 중요한 역할을 한다. 사용자에게 친숙한 도메인 주소를 이용하고, 서버 IP가 변경되어도 쉽게 대응할 수 있도록 도와주는 것

최근에는 클라우드 기반 인프라와 MSA(Micro Service Architecture) 기반의 서비스가 많아짐에 따라, DNS의 역할이 더욱 중요해지고 있다. 클라우드 환경에서는 인프라가 자주 변경되므로 DNS 설계가 중요하며, MSA에서는 다수의 API가 사용되므로 DNS의 역할이 더욱 확대되었다.

1. DNS란?

우리는 직접 IP 주소를 입력하지 않고 도메인 주소를 사용한다.

이는 숫자로 이루어진 IP 주소보다 의미 있는 문자열로 구성된 도메인 주소가 인식하고 기억하기 더 쉽기 때문

도메인 주소 기반의 서비스 운영이 효율적인 이유

• 하나의 IP 주소를 이용해 여러개 웹 서비스 운영 가능
• 서비스 중인 IP 주소가 변경되어도 도메인을 그대로 유지해 접속 방법에 변경이 없음
• 지리적으로 여러 위치에서 서비스 가능

물론 도메인을 이용해도 실제로 패킷을 만들어 통신하려면 3계층 IP 주소를 알아야 한다.
이때 DNS(Domain Name System)가 이런 도메인 주소를 IP 주소로 변환하는 역할을 한다.

그림 출처 https://pioharu.tistory.com/120

도메인 변환

1. 사용자가 도메인 주소를 이용해 서비스를 요청하면,
   • 사용자가 웹 브라우저에 'naver.com'을 입력
2. DNS는 해당 도메인에 대한 IP 주소를 제공
   • DNS 서버는 naver.com의 IP 주소를 알려주어 사용자가 실제로 naver.com에 접속할 수 있게 

내부 시스템의 서비스 간 연결에도 DNS를 사용한다. IP로 서비스 간 연결을 구현하게 되면, 한 서비스의 IP 변경이 필요한 경우 복잡한 설정 변경이나 프로그램 재배포가 필요할 수 있다. 하지만 도메인 주소를 사용하면 DNS 설정 변경만으로 서비스 간 연결을 쉽게 변경할 수 있다.

2. DNS 구조와 명명 규칙

• 계층 구조이며 역트리 구조
  • 루트 도메인부터 시작
  • Top-Level 도메인
  • Second-Level 도메인
  • Third-Level 도메인
• 최대 128계층까지 구성 가능
• 각 계층의 길이는 최대 63바이트
• 전체 도메인의 길이는 최대 255바이트까지 사용 가능

도메인 계층

• '.'으로 각 계층의 경계 표시
• 뒤에서 앞으로 해석
• 알파벳, 숫자, "-"만 사용할 수 있고 대소문자 구분이 없다.

2.1 루트 도메인

• 도메인을 구성하는 최상위 영역
• DNS 서버는 사용자가 쿼리한 도메인에 대한 값을 직접 갖고 있거나 캐시에 저장된 정보를 이용해 응답
• 만약 DNS 서버에 해당 도메인의 정보가 없으면 루트 DNS(루트 도메인 관리)에 쿼리하게 된다.
• 루트 DNS는 전 세계에 13개
• DNS 서버를 설치하면 루트 DNS의 IP 주소를 기록한 힌트(Hint) 파일을 가지고 있어 루트 DNS 관련 정보를 별도로 설정할 필요가 없다.

2.2 Top-Level Domain(TLD)

TLD는 IANA(Internet Assigned Numbers Authority)에서 구분한 6가지 유형으로 구분할 수 있다.

각 유형은 다음과 같다.

*전체 리스트는 IANA 사이트에서 확인할 수 있다.

• Generic TLD(gTLD)
  • 특별한 제한없이 일반적으로 사용되는 최상위 도메인
  • 세 글자 이상으로 구성
  • 초기 gTLD: .com, .edu, .gov, .int, .mil, .net, .org
  • 필요에 의해 새로운 gTLD가 지속적으로 만들어지고 있다.

gTLD
com	일반 기업체
edu	4년제 이상 교육기관
gov	미국 연방정부기관
int	국제기구, 기관
mil	미국 연방군사기관
net	네트워크 관련 기관
org	비영리기관

• Country Code TLD(ccTLD)
  • 국가 최상위 도메인
  • ISO 3166 표준에 의해 규정된 두 글자의 국가 코드 사용 (우리나라의 경우 'kr')
  • 일반적으로 ccTLD를 사용하는 경우 Second Level TLD에는 사이트 용도에 따른 코드 사용(gTLD에서 구분한 것처럼)
    • 일반 회사 : co.kr
    • 정부기관 : go.kr
  • 우리나라는 gTLD를 두 글자로 줄여 사용하지만 호주나 대만처럼 gTLD를 그대로 사용하는 나라도 있다.
    • com.au, gov.au, com.tw, gov.tw 등
• Sponsored(sTLD)
  • 특정 목적을 위한 스폰서를 두고 있는 최상위 도메인
    • 특정 민족공동체, 전문가 집단, 지리적 위치 등
  • STL의 종류 : ‘.aero’, ‘.asia’, ‘.edu', '.museum' 등
• Infrastructure
  • 운용상 중요한 인프라 식별자 공간을 지원하기 위해 전용으로 사용되는 최상위 도메인
  • Infrastructure에 속하는 TLD는 '.arpa'
    • 인터넷 안정성을 유지하기 위해 새로운 모든 인프라 하위 도메인이 배치될 도메인 공간 역할
    • ex) 'IN-ADDR.ARPA’ : IPv4 주소를 도메인 이름에 매핑하는 역방향 도메인에서 사용
• Generic-restricted(grTLD)
  • 특정 기준을 충족하는 사람이나 단체가 사용할 수 있는 최상위 도메인
  • '.biz', '.name', '.pro'
• Test(tTLD)
  • IDN(Internationalized Domain Names) 개발 프로세스에서 테스트 목적으로 사용하는 최상위 도메인
  • '.test'

3. DNS 동작 방식

도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 하지만 DNS 서버없이 로컬에 도메인과 IP 주소를 직접 설정해 사용할 수도 있다.

hosts 파일*에 도메인과 IP 주소를 설정해두면 해당 도메인 리스트는 항상 DNS 캐시에 저장된다.

*hosts 파일 : 로컬에서 도메인과 IP 주소를 관리하는 파일

• DNS 캐시 정보는 도메인을 쿼리할 때 사용
• 이를 통해 DNS 서버에 질의하기 전에 로컬에서 캐시를 확인
  • 동일한 도메인에 대한 반복적인 질의를 피하고 성능을 향상시킬 수 있다.
• DNS 캐시 정보에는 동적 DNS 캐시와 정적 DNS 캐시가 함께 저장
• 도메인 정보가 캐시에 없는 경우,
  1. DNS 서버에 질의를 수행
  2. 응답을 받으면 그 결과를 캐시에 저장
  3. 이후에 같은 도메인에 대한 쿼리가 있을 때는 DNS 서버에 별도로 질의하지 않고 캐시 정보를 사용

windows DNS 캐시

C:W>ipconfig /displaydns

인터넷이 상용화되기 전과 후의 호스트 관리 방식과 DNS 체계의 변화

1. 상용화 이전 호스트 관리
   
   • 인터넷에 연결된 단말이 적어 호스트 정보는 각 단말의 hosts 파일에 저장
   • 각 단말의 hosts 파일에는 호스트 이름과 IP 주소의 매핑이 단순한 테이블 형태로 저장
   • 정적인 테이블 > 단순한 정보 검색으로 주소 변환 > 캐시 개념 필요X
2. 인터넷 상용화와 DNS 체계의 등장
   
   • 인터넷이 상용화 > 연결된 단말 수가 폭증 > 효율적으로 관리하기 위해 DNS(Domain Name System) 체계 도입
   • 기존 호스트 관리 방식의 문제 해결 > 중앙집중식 시스템 구성
   • 복잡한 단말 수용 > 단순한 플랫 구조가 아닌 계층 구조로 구성
   • 기존 hosts 체계와 DNS 체계가 결합 > 도메인 이름 쿼리 프로세스가 복잡해보이는 형태로 발전

로컬 캐시 유무에 따른 도메인 쿼리 방법

'chaeyami.net' 이라는 도메인을 쿼리하기 위해 먼저 로컬 캐시를 조회하고, 로컬 캐시에 없으면 DNS 서버로 다시 쿼리해 도메인 쿼리를 수행한다.

---

지금까지 클라이언트 관점에서 DNS 질의 과정을 살펴봤다.
이제 반대로 DNS 시스템 관점에서 도메인에 대한 결과값을 클라이언트에 보내주는 과정을 살펴보자.

클라이언트가 DNS 서버에 도메인에 대한 쿼리를 보냈을 때,
DNS 시스템은 다음과 같은 과정을 거쳐 결과값을 클라이언트에 보내준다.

1. 클라이언트 → DNS 서버에 도메인 쿼리
2. DNS 서버 → 자신이 가지고 있는 도메인 정보인지 확인. 만약 해당 정보를 가지고 있지 않다면 다른 DNS 서버에 질의를 보내야 함.
3. DNS 서버 → 루트 DNS에 쿼리
4. 루트 DNS → 해당 도메인의 최상위 도메인(TLD) 값을 확인.
5. 루트 DNS → 해당 TLD 값을 관리하는 DNS 서버의 주소 정보를 DNS 서버에 응답
6. DNS 서버 → TLD 값을 관리하는 DNS 서버에 도메인 쿼리를 보낸다.
7. TLD 값을 관리하는 DNS 서버 → 다시 해당 도메인을 관리하는 DNS 서버의 정보를 DNS 서버에 응답한다.
8. DNS 서버 → 해당 도메인을 관리하는 DNS 서버에 도메인 쿼리를 보내고, 최종 결과값을 받게 된다.
9. 처음 쿼리를 받은 DNS 서버는 이 정보를 클라이언트에 응답

이 과정에서 클라이언트는 한 번의 쿼리를 보내지만, DNS 서버는 여러 단계로 쿼리를 상위 DNS 서버에 보내고 정보를 획득한다. 👉🏻 재귀적 쿼리(Recursive Query)

DNS 서버가 상위 DNS 서버에 질의한 방식 👉🏻 반복적 쿼리(Iterative Query)

✏️ 참고 | 재귀적 쿼리(Recursive Query)와 반복적 쿼리(Iterative Query)

• 재귀적 쿼리 : 쿼리를 보낸 클라이언트에 서버가 최종 결값을 반환하는 서버 중심 쿼리
  • 클라이언트와 로컬 DNS 간에서 사용
• 반복적 쿼리 : 최종값을 받을 때까지 클라이언트에서 쿼리를 계속 진행하는 방식
  • 로컬 DNS 서버와 상위 DNS 구간에서 사용
  • 이때 로컬 DNS는 클라이언트로 동작해 상위 DNS에 반복적으로 쿼리

위에서 설명한 쿼리 과정

도메인의 재귀척 쿼리와 반복적 쿼리

1. 사용자 호스트 → 'yamigarden.net'이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어있는지 확인한다.
2. 'yamigarden.net'이 로컬 캐시에 저장되어 있지 않으면 사용자 호스트에 설정된 DNS에 'yamigarden.net'에 대해 쿼리한다.
3. DNS 서버 → 'yamigarden.net'이 로컬 캐시와 자체에 설정되어 있는지 직접 확인한다.
   • 없으면 해당 도메인을 찾기 위해 루트 NS에 .net에 대한 TLD 정보를 가진 도메인 주소를 쿼리한다.
4. 루트 DNS → 'yamigarden.net'의 TLD인 '.net'을 관리하는 TLD 네임 서버 정보를 DNS서버에 응답한다.
5. DNS → TLD 네임 서버에 'yamigarden.net'에 대한 정보를 다시 쿼리한다.
6. TLD 네임 서버 → 'yamigarden.net'에 대한 정보를 가진 yami 네임 서버에 대한 정보를 DNS 서버로 응답한다.
7. DNS → yami 네임 서버에 'yamigarden.net'에 대한 정보를 쿼리한다.
8. yami 네임 서버 → 'yamigarden.net'에 대한 정보를 DNS 응답한다.
9. DNS → 'yamigarden.net'에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 'yamigarden.net'에 대한 정보를 응답한다.
10. 사용자 호스트 → DNS로부터 받은 'yamigarden.net'에 대한 IP 정보를 이용해 사이트에 접속한다.

4. 마스터와 슬레이브

• DNS 서버는 마스터(Master, Primary) 서버와 슬레이브(Slave, Secondary) 서버로 나눌 수 있다.
• 마스터 서버가 우선순위가 더 높지 않고 두 서버 모두 도메인 쿼리에 응답한다.
• 도메인에 대한 존(Zone) 파일을 직접 관리하는지 여부로 구분
  • 마스터 서버 : 존 파일을 직접 생성해 도메인 관련 정보를 관리
  • 슬레이브 서버 : 마스터에 만들어진 존파일을 복제
  • 👉🏻 '영역 전송(Zone Transfer)' 이라고 한다. 
• 즉, 마스터 서버는 도메인 영역을 생성하고 레코드를 직접 관리하지만 슬레이브 서버는 마스터 서버에 설정된 도메인이 가진 레코드값을 정기적으로 복제한다.

DNS 서버의 영역 전송(Zone Transfer)

• 슬레이브 서버를 만들 때 도메인 영역 전송을 위해 마스터 서버의 정보를 입력해야 한다. 
• 마스터 서버는 다른 DNS 서버가 도메인 정보를 복제하는 것을 제한하기 위해 슬레이브 서버를 지정할 수 있다.
• 보안을 위해 복제 가능한 슬레이브 서버 정보를 입력하는 것이 좋다.
• DNS 마스터 서버와 슬레이브 서버는 일반적으로 액티브-스탠바이(Active-Standby) 또는 액티브-액티브(Active-Active) 형태로 이중화되지 않는다.
• 슬레이브 서버는 만료 시간 내에 마스터 서버로부터 존 정보를 받지 못하면 사용할 수 없다.
• 만료 시간 내에 마스터 서버 복구 또는 슬레이브 서버를 마스터로 전환해야 서비스 장애를 방지할 수 있다.
• 도메인 타이머 설정은 SOA 레코드에서 지정할 수 있다.

✏️ 참고 | 액티브-스탠바이와 액티브-액티브

네트워크 서비스나 시스템 내부의 컴포넌트 일부가 정상적으로 동작하지 않더라도 서비스가 지속될 수 있도록 고가용성(High Availability) 기술을 사용하며, 이를 위해 일반적으로 사용하는 구조는 액티브-액티브와 액티브 스탠바이이다.

• 액티브-액티브 구조 : 두 개의 노드가 동시에 서비스를 제공
• 액티브-스탠바이 구조 : 액티브 노드와 스탠바이 노드로 구성되며, 액티브 노드에 장애가 발생하면 스탠바이 노드가 서비스를 시작한다.
• 두 가지 구조는 한 대의 노드에 장시간 문제가 생기더라도 다른 노드가 정상적으로 작동하여 서비스가 지속된다.

5. DNS 주요 레코드

레코드 종류	내용
A(IPv4 호스트)	도메인 주소를 IP 주소(IPv4)로 매핑
AAAA(IPV6 호스트)	도메인 주소를 IP 주소(IPV6)로 매핑
CNAME(별칭)	도메인 주소에 대한 별칭
SOA(권한 시작)	본 영역 데이터에 대한 권한
NS(도메인의 네임 서버)	본 영역에 대한 네임 서버
MX(메일 교환기)	도메인에 대한 메일 서버 정보(Mail exchanger)
PTR(포인터)	IP 주소를 도메인에 매핑(역방향)
TXT(레코드)	도메인에 대한 일반 텍스트

5.1 A(IPv4) 레코드

• 도메인 주소를 IP 주소로 변환하는 역할
• 사용자의 DNS 질의에 응답
• 한 개의 A 레코드에는 한 개의 도메인 주소와 IP 주소가 1:1로 매핑
• 여러 개의 동일한 도메인을 가진 A 레코드로 다른 IP 주소 매핑 가능
• 다수의 도메인에 동일한 IP를 매핑한 A 레코드 가능
• 서버 한 대에서 여러 웹 서비스 구분을 위해 동일한 IP를 매핑하고 HOST 필드로 도메인 구분

5.2 AAAA(IPV6) 레코드

• IPv6 주소 체계에서 사용되는 레코드
• 역할은 A 레코드와 같다.

5.3 CNAME(Canonical Name) 레코드

• CNAME 레코드는 별칭 이름을 사용하게 해주는 레코드
• 레코드값에 IP 주소를 매핑하는 A 레코드와 달리 CNAME 레코드는 도메인 주소를 매핑
• 네임 서버가 CNAME 레코드에 대한 질의를 받으면 CNAME 레코드에 설정된 도메인 정보를 확인하고 그 도메인 정보를 내부적으로 다시 질의한 결과 IP 값을 응답한다.
• 대표적인 예로 'www'가 있다.

✏️ 참고 | CNAME을 사용하는 예

yamigarden.net이라는 웹사이트에 접속하려면

보통 'yamigarden.net'나 'http://www.yamigarden.net'으로 접속한다.

'yamigarden.net'와 'http://www.yamigarden.net'을 각각 A 레코드로 매핑하면 IP 주소가 변경될 때 두 개의 레코드값을 모두 변경해야 하지만,
'yamigarden.net'만 A 레코드로 IP 주소를 매핑하고 'http://www.yamigarden.net'은 CNAME으로서 'yamigarden.net'으로 매핑하면
IP 주소가 변경될때, 'yamigarden.net'만 변경해도 동일한 결과값을 가져올 수 있다.

5.4 SOA(Start Of Authority) 레코드

• 도메인 영역에 대한 권한을 나타내는 레코드
• 현재 네임 서버가 이 도메인 영역에 대한 관리 주체임을 의미 → 해당 도메인에 대해서는 다른 네임 서버에 질의하지 않고 직접 응답
• 도메인 영역 선언 시 SOA 레코드는 필수 항목
  • SOA 레코드를 만들지 않으면 해당 도메인은 네임 서버에서 정상적으로 동작할 수 없다.
• 현재 도메인 관리에 필요한 속성값을 설정
  • 도메인 동기화에 필요한 타이머 값이나 TTL 값
  • 도메인의 네임 서버나 관리자 정보

5.5 NS(Name Server) 레코드

• 도메인에 대한 권한이 있는 네임 서버 정보를 설정하는 레코드
• 하위 도메인에 대한 권한을 다른 네임 서버로 위임(Delegate)하는 역할로도 많이 사용

5.6 MX(Mail eXchange) 레코드

• 메일 서버를 구성할 때 사용되는 레코드
• 해당 도메인을 메일 주소로 갖는 메일 서버를 MX레코드를 통해 선언
• 메일 서버에서 메일을 보낼 때는 MX 레코드를 참조해 동작
  • 우선순위 값을 이용해 다수의 MX 레코드를 선언할 수 있다.
  • 우선순위가 높은(값이 적은) 서버로 메일을 보내고 실패하면 다음 순서의 MX 레코드의 메일 서버에서 처리

5.7 PTR(Pointer) 레코드

• A 레코드와 반대로 IP 주소에 대한 질의를 도메인 주소로 응답하기 위한 레코드
• A 레코드 → 정방향 조회용 레코드
• PTR 레코드 → 역방향 조회용 레코드
• 하나의 IP에 대한 PTR 레코드는 오직 하나
• 주로 화이트 도메인 구성용으로 사용

5.8 TXT(TEXT) 레코드

• 간단한 텍스트를 입력할 수 있는 레코드(도메인에 대한 설명 등)
• 특정 기능으로 사용할 수도 있는데 ,주로 화이트 도메인을 위한 SPF 레코드로 사용됨.
• 공백 포함 가능, 대소문자 구분, 최대 255자

6. DNS에서 알아두면 좋은 내용

• 도메인 위임
• TTL
• 화이트 도메인
• 한글 도메인

6.1 도메인 위임(DNS Delegation)

• 도메인에 대한 정보를 관리하는 네임 서버를 지정하면서 일부 레코드를 다른 곳으로 위임하는 방식
• 도메인 관리 권한을 다른 곳으로 위임하고, 위임된 곳에서 세부 레코드를 관리할 수 있다.
• CDN(Content Delivery Network)이나 GSLB(Global Server Load Balancing)와 같은 기술을 사용해 구현
• 도메인의 계층 구조로 인해 특정 계층의 레코드를 위임하면 하위 계층의 레코드도 함께 위임된다.

1. 현재 yamigarden.net 도메인을 관리하는 네임 서버는 'A' DNS 서버
2. 'A' DNS 서버에 있는 레코드 정보
   • home.yamigarden.net
   • a.home.yamigarden.net
   • blog.yamigarden.net
   • b.blog.yamigarden.net
3. yamigarden.net 도메인 하위에 post 영역을 추가하고, 이 영역을 'B' GSLB에서 관리하고자 한다.
4. 'A' DNS 서버에 해당 영역을 위임하는 레코드 설정을 추가
5. post.yamigarden.net을 포함한 하위 영역의 세부 레코드 c.post.yamigarden.net은 'B' GSLB에서 관리된다.

6.2 TTL

• 도메인의 TTL(Time To Live) 값 : DNS에 질의해 응답받은 결과값을 캐시에서 유지하는 시간
• 로컬 캐시에 저장된 도메인 정보는 DNS에 설정된 TTL 값에 따라 그 시간만 로컬 캐시에 저장됨.
• TTL 값을 늘리면 재귀적 쿼리로 인한 응답 시간이 줄어들어 전체적인 네트워크 응답 시간이 단축
• 하지만 TTL 값이 큰 경우, 도메인 정보 변경 시 갱신이 지연될 수 있다.
• 반대로 TTL 값이 작은 경우, DNS의 정보 갱신은 빠르지만 쿼리량이 증가하여 서버의 부하가 증가할 수 있다.
• 따라서 서비스의 성질과 도메인 정보의 갱신 빈도에 따라 적절한 TTL 값을 설정하는 것이 중요
  • 변경이 빈번하지 않은 경우, TTL 값을 늘려 DNS 서버의 부하를 줄이는 것이 좋다.
  • 반면, IDC 이전이나 공인 IP, 서비스 변경 등이 예정되어 있을 때는 TTL 값을 줄여 변경사항을 빠르게 적용하는 것이 좋다.

6.3 화이트 도메인

정상적으로 발송하는 대량 이메일이 RBL 이력으로 간주되어 차단되는 것을 예방하기 위해 사전에 등록된 개인이나 사업자에 한해 국내 주요 포탈 사이트로의 이메일 전송을 보장해주는 제도입니다.

- 통합 White Domain 등록제 [한국인터넷진흥원 사이트]-

• 화이트 도메인 : 정상적인 도메인을 인증하고 관리하는 제도로, KISA RBL 사이트에서 등록
• 불법 스팸메일을 발송하는 사이트는 RBL(Realtime Blackhole List)에 등록되어 메일 발송이 제한
• 화이트 도메인 등록을 위해서는 해당 도메인에 SPF(Sender Policy Framework) 레코드를 설정해야 한다.
  • 메일 서버 정보를 공개
  • 수신 측 메일 서버는 해당 도메인을 통해 발송된 메일이 실제 메일 서버와 일치하는지 확인
  • 메일 정보와 도메인의 SPF 정보가 일치하지 않을 경우, 해당 이메일은 스팸으로 처리될 수 있다.
  • SPF 레코드의 길이는 최대 512바이트로 제한

6.4 한글 도메인

도메인 주소는 영문뿐만 아니라 "http://한국인터넷진흥원. 한국"처럼 한글로 주소를 만들 수 있다.

DNS에서는 해당 한글을 "퓨니코드"로 변경하고 이 퓨니코드로 DNS에 도메인을 생성해야 한다.

정의 | 퓨니코드[Punycode]

애플리케이션 국제화 도메인 네임(IDNA) 기반 하에서 다국어 도메인이 아스키로 변환(Encoding)된 구문.
다국어 문자 셋으로부터 온 코드 포인트들을 기본적인 문자열(영숫자, 하이픈)들로 유일하게 표현한 것으로 IDNA는 다국어 도메인 처리 작동 원리에 의해 인터넷 사용자가 입력한 다국어 도메인 질의는 클라이언트 단에서 아스키 기반의 퓨니코드 형태로 변환(xn-- 로 시작하는 문자열로 변환)되어 네임 서버에 전송되며 네임 서버는 퓨니코드 형태의 영역 데이터를 운영한다.
퓨니코드는 RFC 3492 에 정의되어 있다.

출처 | [네이버 지식백과] 퓨니코드[Punycode](IT용어사전, 한국정보통신기술협회)

• 즉, 퓨니코드는 한글뿐만 아니라 영어가 아닌 자국어 도메인을 사용할 수 있도록 해주는 표준 코드
• 유니코드 문자열을 인코딩하는 것이므로 유니코드가 지원하는 모든 언어 사용 가능
• 이처럼 자국어 도메인을 사용할 수 있는 것을 "다국어도메인 네임(IDN)"이라고 한다.
• 퓨니코드로 변환된 문자열은 접두어 'xn--'이 붙는다.
  • ex) "채야미.net" → 'xn--hg3b17o1sf.net'

퓨니코드 변환기

 

---

참고

⌜IT 엔지니어를 위한 네트워크 입문⌟ 길벗, 2023
[7장] 통신을 도와주는 네트워크 주요 기술 | 7.2 DNS (p.225~265)

* 책을 참고해 필요한 내용을 정리한 것이므로, 책의 내용과 다를 수 있습니다.