NS 레코드: 도메인 위임하기

모든 도메인 확인은 모름에서 시작됩니다.

www.example.com을 조회하면 루트 서버는 답을 모릅니다. .com 서버도 마찬가지입니다. 각 서버는 같은 메시지로 응답합니다: "저는 모르지만, 여기 아는 곳이 있습니다." NS 레코드가 가능하게 하는 이 연쇄적인 위임이 바로, 어떤 단일 서버도 모든 것을 알지 못하면서도 DNS가 수십억 개의 도메인으로 확장되는 방식입니다.

NS 레코드의 역할

NS (Name Server) 레코드는 단 하나의 질문에 답합니다: "이 도메인의 권한은 누가 가지고 있나요?"

example.com.    86400    IN    NS    ns1.nameserver.com.
example.com.    86400    IN    NS    ns2.nameserver.com.

이 레코드는 리졸버에게 알려줍니다: "example.com에 관한 모든 것은 ns1.nameserver.com 또는 ns2.nameserver.com에 물어보세요." 여러 NS 레코드를 두면 이중화가 됩니다—네임 서버 하나가 장애가 나도 다른 서버들이 응답할 수 있습니다.

위임 체인

DNS는 계층 구조이며, NS 레코드가 각 단계를 다음 단계로 연결합니다. www.example.com을 조회하면:

1. 루트 서버는 example.com을 모릅니다. 루트 서버의 NS 레코드는 .com TLD 서버를 가리킵니다.
2. TLD 서버도 example.com을 모릅니다. TLD 서버의 NS 레코드는 해당 도메인의 권한 네임 서버를 가리킵니다.
3. 권한 네임 서버가 마침내 답을 갖고 있습니다—A, AAAA, MX, 또는 찾고 있는 레코드입니다.

체인의 각 서버는 직관에 반하는 일을 합니다: 자신이 모른다는 사실을 당당히 선언하는 것입니다. "example.com은 모르지만, 아는 곳이 여기 있습니다." 이 의도적인 모름이 DNS를 작동시킵니다. 어떤 서버도 모든 것을 알 필요가 없습니다. 각 서버는 다음 단계만 알면 됩니다.

NS 레코드는 두 곳에 존재합니다

이 차이를 이해하면 몇 시간의 디버깅을 줄일 수 있습니다:

도메인 등록 기관

도메인을 등록할 때, 등록 기관은 TLD 레지스트리에 NS 레코드를 저장합니다. 인터넷이 처음 보게 되는 레코드가 바로 이것입니다. 등록 기관 관리 패널에서 "네임 서버 변경"을 하면 이 레코드가 업데이트됩니다.

여기서 잘못된 서버를 가리키면 도메인에 접근할 수 없습니다. 이 부분이 올바르게 설정될 때까지 다른 설정은 아무 의미가 없습니다.

존(Zone) 파일

권한 네임 서버의 존 파일에도 NS 레코드가 있습니다. 등록 기관의 NS 레코드와 일치해야 합니다. 두 가지 역할을 합니다:

• 존 자체의 권한 선언을 완성
• 서브도메인 위임 가능

등록 기관과 존 파일의 NS 레코드가 일치하지 않으면 확인이 예측 불가능해집니다. 일부 쿼리는 성공하고 일부는 실패하며, 불일치 때문에 디버깅이 매우 힘들어집니다.

글루 레코드 문제

진짜 역설이 있습니다: 네임 서버 자체가 여러분의 도메인에 호스팅되어 있다면 어떻게 될까요?

example.com.    IN    NS    ns1.example.com.
example.com.    IN    NS    ns2.example.com.

example.com을 확인하려면 ns1.example.com에 물어봐야 합니다. 그런데 ns1.example.com을 찾으려면 먼저 example.com을 확인해야 합니다. 닭이 먼저냐 달걀이 먼저냐의 문제입니다.

글루 레코드가 이를 해결합니다. 일반적인 확인 과정을 우회해 TLD 레지스트리에 IP 주소를 직접 저장하는 방식입니다:

ns1.example.com.    IN    A    192.0.2.1
ns2.example.com.    IN    A    192.0.2.2

이제 TLD 서버는 NS 레코드와 함께 해당 서버에 접근하는 데 필요한 IP 주소까지 반환할 수 있어, 순환 의존성이 해결됩니다.

서브도메인 위임

NS 레코드를 사용하면 도메인의 일부를 완전히 다른 서버에 넘길 수 있습니다:

shop.example.com.    86400    IN    NS    ns1.shopify.com.
shop.example.com.    86400    IN    NS    ns2.shopify.com.

이제 Shopify 서버가 shop.example.com과 그 하위의 모든 것을 관리합니다. 나머지는 여러분의 서버가 처리합니다. 상위 존은 단순히 "shop에 대해서는 Shopify에 물어보세요"라고 알려줄 뿐입니다.

이를 통해 다음이 가능해집니다:

• SaaS 통합: 서비스 제공업체가 서브도메인을 직접 관리
• 조직 경계 분리: 부서별로 자체 DNS 관리
• 환경 격리: 프로덕션, 스테이징, 개발 환경에 별도의 네임 서버 운용

권장 사항

서로 다른 네트워크에 여러 네임 서버를 운용하세요. DNS 사양은 지리적으로 분산된 네임 서버를 권장합니다. 데이터 센터 하나가 다운되어도 나머지가 계속 응답합니다. 최신 제공업체들은 애니캐스트(anycast)를 사용해 전 세계 여러 위치에서 동일한 IP를 알립니다.

레코드를 일관되게 유지하세요. 등록 기관의 NS 레코드는 존 파일과 일치해야 합니다. 불일치는 간헐적 장애를 유발하는데, 이런 종류가 가장 디버깅하기 까다롭습니다.

마이그레이션 전에 TTL을 계획하세요. NS 레코드의 TTL은 보통 24~48시간입니다. DNS 제공업체를 변경하기 며칠 전에 TTL을 낮춰 두면 변경 사항이 더 빨리 전파됩니다.

NS 레코드가 CNAME을 가리키게 하지 마세요. NS 레코드는 A 또는 AAAA 레코드로 직접 확인되어야 합니다. CNAME을 대상으로 지정하면 DNS 사양에 위반되며 확인 실패가 발생합니다.

핵심 요약

• NS 레코드는 "이 도메인에 대해 누구에게 물어봐야 하나요?"라는 질문에 답함으로써 권한을 위임합니다
• 위임 체인은 루트 서버 → TLD 서버 → 권한 네임 서버 순으로 이어집니다
• NS 레코드는 두 곳에 존재합니다: TLD 레지스트리(등록 기관)와 존 파일—항상 동기화 상태를 유지하세요
• 글루 레코드는 네임 서버가 자체 도메인에 호스팅될 때의 순환 의존성을 해결합니다
• 서브도메인 위임을 통해 도메인의 각 부분을 다른 서버가 관리할 수 있습니다
• 서로 다른 네트워크에 여러 NS 레코드를 두면 장애 시 이중화가 됩니다

NS 레코드 자주 묻는 질문

네임 서버가 모두 다운되면 어떻게 되나요?

도메인에 접근할 수 없게 됩니다. 리졸버는 각 NS 레코드를 순서대로 시도하고, 아무것도 응답하지 않으면 쿼리가 실패합니다. 그래서 서로 다른 네트워크에, 이상적으로는 다른 지역에, 여러 네임 서버를 두는 것이 필요합니다.

NS 레코드 변경이 전파되는 데 얼마나 걸리나요?

기존 레코드의 TTL에 따라 다릅니다. TTL이 48시간이라면 일부 리졸버는 최대 이틀 동안 이전 서버를 캐시합니다. 마이그레이션 전 며칠 전에 TTL을 낮춰 두면 전파 속도가 빨라집니다.

NS 레코드가 등록 기관과 존 파일 양쪽에 있는 이유는 무엇인가요?

등록 기관의 NS 레코드는 TLD로부터의 공식 위임으로, 쿼리가 실제로 어디로 전달될지를 결정합니다. 존 파일의 NS 레코드는 존 자체가 자신의 서버를 선언하는 것으로, 완전성 유지와 서브도메인 위임에 사용됩니다. 항상 일치해야 합니다.

서브도메인별로 다른 네임 서버를 사용할 수 있나요?

네, 가능합니다. 존 파일에 해당 서브도메인을 다른 서버로 가리키는 NS 레코드를 추가하면 됩니다. 그 서버들이 해당 서브도메인과 그 하위의 모든 것에 대한 권한을 갖게 됩니다. 이것이 서브도메인 위임입니다.