업데이트됨 1개월 전
기본 네임서버에서 A 레코드를 변경했습니다. 그런데 전 세계 보조 네임서버들은 그 존의 복사본을 각자 보유하고 있습니다. 이들은 수백만 개의 존을 관리해야 하기 때문에 여러분의 서버를 계속 지켜볼 수 없습니다. 그래서 규칙이 필요합니다: 얼마나 자주 확인할지, 무엇이 "업데이트됨"으로 간주되는지, 연결할 수 없을 때 언제 포기할지.
Start of Authority 레코드가 바로 그 규칙집입니다. 모든 DNS 존에는 정확히 하나씩 존재하며, 존 최상위(apex)에 위치해 세 가지를 관장합니다: 권한 있는 원본 서버가 어느 것인지, 복사본들이 어떻게 동기화를 유지하는지, 그리고 무언가가 존재하지 않는다는 사실을 인터넷이 얼마나 오래 기억해야 하는지.
일곱 가지 필드
SOA 레코드는 일곱 가지 필드에 존 운영에 필요한 조율 정보를 담습니다:
MNAME (ns1.example.com)은 기본 네임서버—데이터의 원본 소스—를 지정합니다. 보조 서버들이 최신 데이터가 필요할 때 이곳에서 가져옵니다.
RNAME (admin.example.com)은 DNS 방식으로 인코딩된 관리자 이메일입니다. 즉, admin@example.com인데, DNS는 @ 기호 대신 점을 사용합니다. @ 기호가 존 파일에서 특별한 의미를 가지기 때문입니다. 로컬 부분에 점이 포함된 경우(john.smith@example.com), 역슬래시로 이스케이프됩니다.
Serial은 버전 번호입니다. 존을 변경할 때마다 반드시 증가해야 합니다. 보조 서버는 자신의 시리얼을 기본 서버의 것과 비교하여, 더 높은 값이면 "최신 데이터를 가져오라"는 신호로 받아들입니다. 형식은 중요하지 않습니다—2024031501(날짜 + 수정 번호) 또는 단순히 증가하는 정수 모두 가능합니다. 절대적인 규칙은 단 하나: 항상 올라가야 한다는 것입니다.
Refresh (7200 = 2시간)는 보조 서버가 업데이트를 얼마나 자주 확인할지 지정합니다. 간격이 짧을수록 전파는 빨라지지만 기본 서버에 더 많은 쿼리가 발생합니다.
Retry (3600 = 1시간)는 갱신이 실패했을 때의 재시도 간격입니다. 보조 서버가 예정된 시간에 기본 서버에 접근할 수 없는 경우, 다음 전체 갱신 주기를 기다리지 않고 이 짧은 간격 이후에 다시 시도합니다.
Expire (1209600 = 14일)는 신뢰 기한입니다. 보조 서버가 기본 서버에 접근하지 못할 때, 점점 더 오래된 데이터로 쿼리에 계속 응답합니다. Expire 타이머는 언제부터 오래된 데이터로 응답하는 것보다 아예 응답을 중단하는 것이 나은지를 결정합니다.
Minimum TTL (86400 = 24시간)은 네거티브 캐싱을 제어합니다—리졸버가 이름이 존재하지 않는다는 사실을 얼마나 오래 기억하는지입니다. nonexistent.example.com을 쿼리하고 NXDOMAIN을 받으면, 그 "해당 이름 없음" 응답이 이 기간 동안 캐시됩니다.
시리얼 번호 문제
시리얼 번호 증가를 잊어버리는 것은 DNS에서 가장 흔한 실수 중 하나입니다. 존 파일을 편집하고, 새 레코드를 추가하고, 저장하고, 네임서버를 다시 로드합니다. 기본 서버에서는 모든 것이 정상으로 보입니다. 그런데 보조 서버들이 확인할 때 시리얼을 비교해보고 일치하면 전송을 건너뜁니다.
업데이트는 단 하나의 서버에만 존재하고 다른 어디에도 없게 됩니다.
이것이 날짜 기반 시리얼이 효과적인 이유입니다—2024031501은 누가 봐도 2024년 3월 15일, 첫 번째 수정을 의미합니다. 3월 16일에 변경을 가할 때는 자연스럽게 2024031601을 적게 됩니다. 형식 자체가 증가를 습관으로 만들어줍니다.
존 전송에는 두 가지 방식이 있습니다: AXFR은 존 전체를 전송하고, IXFR은 특정 시리얼 이후의 변경 사항만 전송합니다. 증분 전송이 작동하는 것은 시리얼이 신뢰할 수 있는 타임라인을 형성하기 때문입니다.
값 설정 가이드
Refresh: 자주 변경되는 동적 존은 18003600초가 적합합니다. 변경이 거의 없는 안정적인 존은 2160086400초까지 늘릴 수 있습니다. 갱신 간격이 짧을수록 전파는 빠르지만 기본 서버의 부하가 증가합니다.
Retry: Refresh보다 짧게 유지하세요—보통 4분의 1에서 2분의 1 정도가 적당합니다. 다음 예정된 갱신 전에 여러 번 재시도할 수 있어야 합니다.
Expire: 7~14일이면 보조 서버가 응답을 중단하기 전에 기본 서버 장애를 복구할 충분한 시간을 확보할 수 있습니다. 동시에 장기 장애 시 심하게 오래된 데이터를 서비스하지 않을 만큼 짧아야 합니다.
Minimum TTL: 3003600초가 대부분의 상황에 적합합니다. 짧은 값(300900)은 마이그레이션 중이거나 서브도메인을 자주 추가할 때 유용합니다. 긴 값(1800~3600)은 존재하지 않는 이름에 대한 반복 쿼리 부하를 줄여줍니다.
현대 DNS는 NOTIFY 메시지를 지원합니다: 기본 서버가 업데이트되면 보조 서버들에게 즉시 확인하도록 알림을 보내, 다음 예정된 갱신을 기다리지 않아도 됩니다. 전파가 거의 즉시 이루어지며, SOA 타이밍은 신뢰할 수 있는 대안 메커니즘으로 남습니다.
네거티브 캐싱의 함정
Minimum TTL 필드는 마이그레이션 중에 예상치 못한 문제를 일으킬 수 있습니다. 리졸버가 존재하지 않는 이름을 쿼리하면 NXDOMAIN 응답을 캐시합니다. Minimum TTL이 86400초라면, new-subdomain.example.com을 찾으려다 실패한 리졸버는 해당 레코드를 생성한 이후에도 24시간 동안 재시도하지 않습니다.
새 인프라로 이전하면서 새 서브도메인을 만들었다고 합시다. 누군가의 리졸버가 어제 그 이름을 조회했다가 NXDOMAIN을 받아 캐시해뒀습니다. 이제 레코드가 실제로 존재함에도 불구하고 그 사용자는 서비스에 접근할 수 없습니다. 여러분은 이유를 몰라 답답하고, 그들도 마찬가지입니다.
주요 변경 전에 Minimum TTL을 낮추세요. 상황이 안정되면 다시 올리면 됩니다.
SOA로 문제 진단하기
SOA 레코드는 훌륭한 진단 도구이기도 합니다. 각 네임서버의 시리얼을 비교하면 동기화 문제를 즉시 파악할 수 있습니다. 기본 서버가 시리얼 2024031505를 보여주는데 보조 서버가 2024031502를 보여준다면, 존 전송이 제대로 이루어지지 않는 것입니다—네트워크 문제, 권한 설정, 또는 보조 서버가 기본 서버에 전혀 접근하지 못하는 상황일 수 있습니다.
Expire 타이머는 해당 보조 서버가 응답을 멈추기까지 얼마나 남았는지 알려줍니다. Refresh 간격은 얼마나 자주 재시도하는지를 보여줍니다.
SOA 레코드의 모든 필드는 동기화를 제어하거나 문제 해결을 돕습니다.
SOA 레코드 자주 묻는 질문
시리얼 번호를 올리는 걸 깜빡하면 어떻게 되나요?
보조 네임서버는 자신의 시리얼과 기본 서버의 시리얼을 비교합니다. 두 값이 같으면 전송이 발생하지 않습니다. 시리얼을 증가시키고 보조 서버들이 업데이트를 가져올 때까지 변경 사항은 기본 서버에만 남아 있습니다.
RNAME 필드에서 @ 대신 점을 사용하는 이유가 무엇인가요?
@ 기호는 존 파일에서 특별한 의미를 가집니다—존 원점(origin)을 나타냅니다. DNS는 현대 이메일 표기 방식보다 먼저 생겨났기 때문에, SOA 형식에서는 @ 대신 점을 사용합니다. admin.example.com은 admin@example.com을 의미합니다.
존 전송이 정상적으로 작동하는지 어떻게 확인하나요?
각 네임서버에서 SOA 레코드를 쿼리해 시리얼 번호를 비교하세요. 값이 일치해야 합니다(방금 변경을 적용한 직후라면 아주 가까운 값이어야 합니다). 시리얼이 맞지 않으면 전송에 실패하고 있는 것입니다—네트워크 연결 상태, 방화벽 규칙, 전송 권한을 확인하세요.
적절한 Expire 값은 얼마인가요?
7~14일이 일반적입니다. 기본 서버에 문제가 생겼을 때 보조 서버가 침묵하기 전에 복구할 수 있을 만큼 충분히 길고, 장기 장애 시 심하게 오래된 데이터를 서비스하지 않을 만큼 짧은 값입니다. Expire 타이머는 재해 복구를 위한 유예 기간입니다.
이 페이지가 도움이 되었나요?