DNS가 영역에 할당할 네임서버를 선택하는 방법

Yeap DNS에 도메인을 추가하면 콘솔에 네임서버(NS) 두 개가 표시됩니다. 이를 도메인 등록기관에 설정하면 도메인이 Yeap에 위임됩니다. 간단한 단계처럼 보이지만 여러 요구 사항을 동시에 충족해야 합니다. 이 글에서는 이 두 네임서버를 선택하는 방법을 설명합니다.

세 가지 요구 사항

1. 안정성. 네임서버는 도메인 등록기관과 TLD 레지스트리의 위임 레코드에 기록됩니다. 한 영역에 오늘은 A와 B, 내일은 C와 D가 할당된다면 등록기관 설정을 계속 수정해야 하고, 그 사이에 이름 해석이 실패할 수 있습니다. 주어진 영역에 대한 결과는 결정적이어야 합니다.
2. 분산. 모든 영역에 같은 조합을 할당하면 부하가 소수의 노드에 집중되며, 한 네임서버의 문제가 모든 사용자에게 영향을 줍니다. 영역마다 서로 다른 조합을 할당해야 합니다.
3. 실제 응답 가능 여부. 제공하는 네임서버에는 실제로 실행 중인 노드가 연결되어 있어야 합니다. 연결된 노드가 없는 네임서버로 영역을 위임하면 질의는 응답을 받을 수 없는 곳으로 향하게 됩니다.

풀 모델

다른 여러 호스팅형 DNS 서비스와 마찬가지로 저희 모델도 세 계층으로 구성됩니다.

• 풀: 네임서버의 집합입니다. 각 요금제는 하나의 풀을 가리키며, 무료 요금제와 유료 요금제는 별도의 풀을 사용합니다.
• 네임서버: 풀의 각 항목은 하나의 NS 호스트 이름이며, 최종적으로 도메인 등록기관에 입력하는 이름입니다.
• 노드: 실제로 권한 있는 DNS 서비스를 실행하는 서버입니다. 여러 노드가 하나의 네임서버를 서비스할 수 있으며, 해당 네임서버의 글루 레코드는 그 노드들의 주소를 가리킵니다.

영역에 네임서버를 할당한다는 것은 해당 영역의 요금제에 연결된 풀에서 네임서버 두 개를 선택한다는 의미입니다.

안정적인 무작위성: 영역을 시드로 사용하는 해시 정렬

안정성과 분산을 함께 확보하기 위해, 본질적으로 최고 무작위 가중치 해싱(랑데부 해싱, HRW)에 해당하는 전통적인 기법을 사용합니다.

1. 풀의 각 네임서버에 대해 hash(zoneName + ":" + nameserverId)를 계산합니다.
2. 해시를 기준으로 정렬합니다. 값이 같으면 ID로 순서를 정하여 항상 결정적인 순서를 보장합니다.
3. 처음 두 개를 선택합니다.

function pickNameservers(pool, zoneName, count = 2):
    if len(pool) <= count:
        return pool
    sort pool by (crc32(zoneName + ":" + ns.id), ns.id)
    return first count items of pool

이 방식에는 몇 가지 유용한 특성이 있습니다.

• 결정적 결과: 입력은 영역 이름과 풀의 내용뿐입니다. 몇 번 계산하더라도 같은 영역에는 같은 결과가 나오며, 무작위 상태나 할당 시점의 부하에 영향을 받지 않습니다.
• 고른 분산: 영역마다 무작위처럼 보이는 서로 다른 순서가 생성되므로, 전체적으로 풀의 네임서버 조합에 고르게 분산됩니다.
• 확장 시 제한적인 영향: 풀에 네임서버를 추가하면 새 네임서버가 상위 두 개 안에 들어가는 영역의 결과만 바뀝니다. 나머지 영역의 결과는 그대로 유지됩니다. 이것이 단순 모듈로 해싱과 비교한 HRW의 주요 장점입니다.

선택 결과는 영역 생성 시 저장됩니다. 이후 풀을 변경해도 기존 영역의 네임서버가 자동으로 바뀌지 않으므로, 용량을 추가했다는 이유로 위임 대상이 변경되는 일은 없습니다. 결정성이 특히 유용한 지점은 콘솔, API, 요금제 구매 후 자동 프로비저닝 등 어떤 경로로 영역을 생성하더라도 동일한 할당기를 거쳐 같은 결과를 얻는다는 점입니다.

시드로 사용할 영역 이름이 없는 일부 드문 내부 처리 경로에서는 "호스팅 영역 수가 가장 적은 순서"를 사용합니다. 이 역시 결정적인 부하 분산 방식입니다.

상태는 의도, 하트비트는 사실

정렬에 앞서 더 중요한 단계가 있습니다. 어떤 네임서버를 후보 풀에 포함할 수 있는지 결정하는 것입니다. 이를 서비스 가능 상태라고 부르며, 네임서버는 다음 조건을 모두 만족해야 합니다.

• 네임서버 자체가 활성화되어 있어야 합니다.
• 유효한 NS 호스트 이름이 있어야 합니다. 비어 있거나 테스트용 자리표시자여서는 안 됩니다.
• 해당 네임서버에 연결된 노드 중 적어도 하나는 상태가 활성화되어 있고, 최근 15분 이내에 하트비트를 전송했어야 합니다.

마지막 조건은 좀 더 자세히 살펴볼 필요가 있습니다. 데이터베이스의 노드 상태 필드는 운영자가 설정하며, "이 노드가 서비스를 제공하기를 원한다"는 의도를 나타냅니다. 바라는 상태와 실제 상태는 다릅니다. 서버가 활성화로 표시되어 있더라도 재설치, 네트워크 변경, 인증 정보 무효화 등의 이유로 오래전부터 응답을 중단했을 수 있습니다. 상태 필드만 신뢰하는 할당기는 실제로 존재하지 않는 서비스에 새 영역을 위임할 수 있습니다.

따라서 저희 원칙은 다음과 같습니다. 상태 필드는 의도이고, 하트비트 타임스탬프는 사실입니다. 각 노드는 설정을 폴링할 때마다 마지막 확인 시각을 갱신하며, 폴링을 중단한 노드는 일정 시간이 지나면 자동으로 오프라인으로 표시됩니다. 할당기는 사실만 신뢰합니다.

노드가 영역 데이터를 가져오는 방법

할당이 완료되면 영역 데이터가 올바른 노드에 반영되어야 합니다. 권한 있는 DNS 데이터 플레인은 풀 방식으로 동작하는 CoreDNS 맞춤 빌드를 사용합니다.

• 각 영역에는 설정 버전이 있으며, 이 값은 영역의 SOA 레코드에 있는 일련번호이기도 합니다. 레코드가 변경될 때마다 증가합니다.
• 노드는 인증을 거쳐 주기적으로 컨트롤 플레인에 현재 버전을 요청합니다. 버전이 바뀌면 새 영역 데이터를 가져와 표준 영역 파일로 저장하고 다시 로드합니다.
• 각 노드는 전체 데이터가 아니라 자신이 서비스하는 네임서버에 할당된 영역만 받습니다.
• 영역이 비활성화되거나 삭제되면 컨트롤 플레인은 일정 기간 노드에 삭제 신호를 계속 보냅니다. 노드는 로컬 영역 파일을 제거하고 해당 영역에 대한 응답을 중단합니다. 삭제된 영역이 일부 노드에 남아 있지 않도록 합니다.

SOA 일련번호가 설정 버전이므로 dig를 사용해 특정 네임서버가 최신 버전을 보유하고 있는지 확인할 수 있습니다.

dig +short SOA example.com @your-nameserver-hostname

모든 네임서버가 같은 일련번호를 반환하면 모두 최신 데이터를 보유하고 있습니다.

인프라 영역에서 얻은 교훈

NS 호스트 이름 자체도 이름 해석이 가능해야 하며, 이 이름들의 글루 및 주소 레코드는 고객 영역과 동일한 시스템에서 관리하는 전용 인프라 영역에 저장됩니다. 따라서 이 영역은 항상 활성화 상태를 유지해야 합니다. 실수로 비활성화하면 삭제 신호로 인해 노드가 해당 영역을 제거하고, 그 네임서버에 의존하는 모든 영역이 영향을 받게 됩니다. 삭제 신호를 활성화하기 전에 엔드투엔드 테스트로 이 부분을 별도로 확인했으며, 이제 이러한 영역은 영구 유지 대상으로 표시됩니다.

이 교훈은 자체 의존성을 호스팅하는 모든 시스템에 적용됩니다. 플랫폼이 스스로의 핵심 의존성을 호스팅한다면 해당 의존성에는 추가 보호가 필요합니다.

사용자가 할 일

사용자는 도메인을 추가한 뒤 콘솔에 표시되는 네임서버 두 개를 도메인 등록기관에 설정하기만 하면 됩니다. 영역 상세 페이지에는 할당된 네임서버와 각 네임서버의 현재 활성 노드 수가 표시되며, 콘솔의 NS 확인 기능으로 위임이 적용되었는지 알 수 있습니다. 나머지는 할당기와 동기화 파이프라인이 처리합니다.