SOA 레코드란? DNS 존 권한 설명

SOA는 Start of Authority(권한 시작)를 뜻합니다. SOA 레코드는 존의 루트(apex)에 반드시 있어야 하는 DNS 레코드로, 해당 존에 대한 관리 정보와 타이밍 정보를 담고 있습니다. 기본 네임서버 이름, 책임자 필드, 일련번호, 그리고 보조 권한 서버가 사용하는 여러 타이머를 식별합니다. 웹사이트의 IP 주소를 반환하지 않으며 일반적인 상태 증명서도 아닙니다. 관리자와 진단 도구는 존이 어떻게 버전 관리되는지, 보조 서버가 업데이트를 확인할 시점을 어떻게 아는지 이해하기 위해 SOA 데이터를 살펴봅니다. 그 값은 DNS 제공업체의 관리 모델과 일치해야 하는 운영 메타데이터입니다.

SOA 레코드의 필드

일반적인 SOA 레코드에는 존 모델에서 기본 소스 서버를 지정하는 MNAME과 존 관리자의 연락처 정보를 인코딩한 RNAME이 들어 있습니다. 또한 일련번호, 갱신(refresh) 간격, 재시도(retry) 간격, 만료(expire) 간격, 네거티브 캐시 TTL 값이 포함됩니다. 표시 방식은 도구마다 다르며, 제공업체가 관리하는 DNS는 일부 필드를 추상화하거나 자동으로 유지할 수 있습니다. RNAME은 일반적인 이메일 표기가 아니라 DNS 구문을 사용하며, 관례적으로 이스케이프되지 않은 첫 번째 점이 @ 기호를 나타냅니다. 대부분의 사용자는 이 레코드를 직접 수정할 필요가 없지만, 위임이나 동기화 문제를 조사할 때 유용할 수 있습니다.

일련번호는 운영 측면에서 가장 자주 논의되는 값입니다. 전통적인 기본-보조 DNS에서는 보조 서버가 자신의 일련번호를 기본 서버의 것과 비교하고, 기본 서버의 버전이 더 새로우면 업데이트를 요청합니다. 일련번호가 반드시 날짜인 것은 아니며, 범용 타임스탬프로 해석해서는 안 됩니다. 최신 제공업체는 독자적인 컨트롤 플레인으로 존 업데이트를 배포할 수 있지만, 눈에 보이는 SOA 일련번호는 여러 권한 서버가 같은 버전을 가진 것처럼 보이는지 판단하는 데 여전히 도움이 됩니다. 일련번호가 다르다면, 복제가 깨졌다고 결론짓기 전에 제공업체 내부에서 예상되는 전파 시간을 감안하고 제공업체가 문서화한 동작을 확인하세요.

SOA와 네거티브 캐싱

SOA는 네거티브 캐싱, 즉 어떤 이름이나 요청한 레코드가 없다는 정보를 리졸버가 얼마나 오래 보관할 수 있는지와도 관련됩니다. 실제로 적용되는 네거티브 캐시 수명은 DNS 표준과 SOA 필드를 따르지만, 리졸버의 동작과 제공업체의 표시 방식 때문에 사용자에게 보이는 결과가 복잡해질 수 있습니다. 존이 올바르게 설정되어 있어도 새로 만든 레코드가 즉시 나타나지 않을 수 있는 이유 중 하나입니다. 이전의 부정 응답이 한동안 캐시된 채 남아 있을 수 있기 때문입니다. 그 기간에 같은 리졸버로 질의를 반복하면 계속 없는 것으로 보일 수 있으며, 다른 리졸버에 질의하거나 권한 데이터를 확인하면 캐싱 때문인지 레코드가 없는 것인지 구분하는 데 도움이 됩니다.

• 존 수준의 권한이나 일련번호 정보가 필요할 때 SOA를 점검하세요.
• 도메인에 어떤 네임서버가 위임되어 있는지 보려면 NS 레코드를 사용하세요.
• 주소 관련 질문에는 A와 AAAA를 사용하세요. SOA는 주소 레코드가 아닙니다.
• 일련번호 차이가 장애를 뜻한다고 가정하기 전에 권한 서버들을 비교하세요.
• 운영상의 영향을 이해하지 못한 채 제공업체가 관리하는 SOA 필드를 변경하지 마세요.

SOA 조회가 유용한 경우

SOA 조회는 레코드 변경이 권한 서버마다 일치하지 않는 것처럼 보일 때, 존이 최근에 이전되었을 때, 또는 새 이름에 네거티브 캐싱이 관련될 때 문제 해결에 도움이 됩니다. 일반적인 웹사이트 장애에서 가장 먼저 확인하는 항목인 경우는 드뭅니다. 영향을 받은 호스트 이름과 레코드 유형부터 시작하고, 증거가 존 수준의 문제를 가리킬 때에만 위임과 SOA를 점검하세요. SOA 응답으로는 웹사이트에 접근할 수 있는지, 메일 서버가 메시지를 받는지, 모든 재귀 캐시가 갱신되었는지 확인할 수 없습니다.

DNS 데이터 전반에 대한 안내는 DNS 레코드 유형 설명을, 캐시 타이밍은 DNS TTL의 의미를 참고하세요. 목적에 맞는 DNS 조회로 기본적인 비교에 필요한 공개 응답을 확인할 수 있습니다. SOA를 제 역할에 두세요. SOA는 존의 권한과 조율을 기술하고, 주소, 메일, 정책 레코드는 서로 다른 질문에 답합니다. 이런 구분을 두면 모든 DNS 필드를 웹사이트 주소일 수 있다고 여기는 것보다 SOA 레코드를 훨씬 이해하기 쉬워집니다.

SOA 값을 추측으로 수정하지 마세요

관리형 DNS 플랫폼은 SOA 일련번호와 타이머를 자동으로 생성하고 유지하는 경우가 많습니다. 제공업체의 모델을 이해하지 못한 채 다른 존의 일련번호를 복사하거나 타이밍 필드를 낮추는 관리자는 전파를 개선하지 못한 채 혼란만 일으킬 수 있습니다. SOA 데이터를 수정하기 전에 제공업체의 문서를 확인하고 수동 제어를 허용하는지 파악하세요. 보조 DNS 서비스가 관련되어 있다면 그 전송 및 갱신 워크플로가 지원되는 구성을 따르는지 확인하세요. 대부분의 웹사이트 소유자에게는 SOA를 바꾸는 것보다 관찰하는 것이 더 유용합니다. 권한을 비교하고, 일련번호를 기록하고, 제공업체의 서버들이 수렴했는지 문의하세요. 직접 권한 DNS를 운영하는 것이 아니라면, 장애 증거는 보관하되 동기화 시스템에 속한 필드는 DNS 호스트가 관리하도록 두세요.