Q. SOA 레코드 필드 값은 어떤 기준으로 어떻게 설정해야 하나?

Q. SOA 레코드는 왜 있는 건가요?

A. SOA 레코드는 필수 레코드입니다. SOA레코드는 도메인 영역을 표시하는 역할을 합니다. 또 네임서버에게 어떤 기준에 의해 이 도메인을 관리하여야 하는지 알려주는 역할을 합니다.

 

 

SOA 레코드는 도메인 존 파일 작성에서 반드시 작성해야 하는 레코드입니다. 이것은 표준 사항인 동시에 인터넷 도메인 이름(domain name) 체계의 기본 원칙에 관련된 사항입니다.

SOA 레코드는 이 도메인 영역이 구분된 관리영역을 갖는 독립적인 도메인 존(zone)임을 표시해 줍니다.

예를 들어 도메인 이름 tistory.com에 SOA 레코드가 설정되어 있으면, 인터넷 전체 도메인 영역 중 tistory.com 이름 이하의 도메인 영역(zone)은 독자적인 관리주체에 의해 관할 관리되는 영역임을 알 수 있습니다. 즉, com 도메인 영역에 속하기는 하지만 com 영역관리 주체와는 다른 주체에 의해서, 또는 별도의 독자적인 관리정책으로 tistory.com 이하의 내부 영역이 관리되고 있음을 표시합니다.

만일 SOA 레코드가 누락된 도메인 존 파일을 네임서버에 반영시키려 하면, 네임서버는 에러 로그를 몇 줄 남기고 처리하지 않고 무시해 버립니다. 네임서버가 지나치게 깐깐해서 그렇게 무시해 버리는 것은 아닙니다. 네임서버 입장에서는 SOA 레코드가 누락된 도메인 존을 ‘어떻게 관리해야 하는지 도무지 알 수가 없기 때문’에 아예 처음부터 반영하지 않음으로써 문제발생을 미연에 방지하려는 것일 뿐입니다.

SOA 레코드는 이 도메인 존(zone)으로 별도로 구분된 도메인 영역이며 이 도메인 영역은 이러이러한 기준으로 관리되어야 한다고 “네임서버에게” 알려주는 정보를 담고 있습니다. 이때 “네임서버”는 마스터 네임서버, 슬레이브 네임서버는 물론, 캐시DNS서버까지 포함하는 모든 네임서버를 지칭합니다.

SOA 레코드는 “Start Of Authority”의 약자입니다. 여기서 Authority는 관리권한을 의미하는 것으로 번역할 수 있습니다. 관리권한이 시작되는 곳으로 도메인 존 영역의 시작점을 의미합니다. 이 지점부터는 관리영역이 나뉘어 지는 것을 표시합니다. 한마디로 쉽게 말하자면 “영역 표시” 역할입니다. “여기부터는 내가 관할하는 영역이다”라는 표시를 SOA 레코드가 해 줍니다.

크게 보면, Domain Name System(DNS) 체계는 루트 도메인(.)이 전체 도메인 영역을 대표하고 그 내부에 다시 도메인 영역들을 분할하여 각자 알아서 분할된 영역을 관리하는 방식으로 구성되어 있습니다. 나누어진 각 도메인 영역을 표시하는 수단이 SOA 레코드입니다. 도메인 존(domain zone)은 SOA 레코드에 의해 그 영역의 범위가 구체적으로 규정됩니다.

도메인에 서브 도메인을 두어 하위 영역을 분할하는 경우, 즉 도메인을 위임(delegation)하는 경우, NS레코드(글루레코드)로 해당 서브 도메인(또는 자식 도메인)이 소재한 네임서버를 지정해 주고, 서브 도메인의 마스터 네임서버에서는 이 서브 도메인 이름에 대해 “반드시” SOA 레코드를 설정해야 합니다. 위임(delegation)이라는 것은 일정 도메인 영역의 관리권한을 위임한다는 의미이고, 이렇게 위임받은 주체는 독자적인 관리정책으로 그 도메인 영역을 관리하게 됩니다. 이때 그 관리정책 중 네임서버가 알아야 할 도메인 존의 관리정책을 DNS 레코드로 표현한 것이 바로 SOA 레코드입니다.

 

Q. SOA 필드 값은 어떤 기준으로 작성해야 하나요?

A. 이러이러한 값으로 꼭 설정해야 한다고 정해진 특별한 값은 없습니다. 자신의 인터넷 서비스 특성과 운영방식을 고려해서 정하면 됩니다. 하지만 몇 가지 주요하게 고려해야 할 사항은 있습니다.

 

먼저 SOA 레코드의 구체적인 사례를 보면 다음과 같습니다. 가장 만만해 보이는(?) 여기 티스토리의 SOA 레코드 경우를 선택해 보았습니다.

$ dig tistory.com soa +multi +noall +answer 
; <<>> DiG 9.9.5-9ubuntu0.3-Ubuntu <<>> tistory.com soa +multi +noall +answer 
;; global options: +cmd 
tistory.com. 600 IN SOA ns.daumzone.com. hostmaster.daum.net. ( 
                     2015090300 ; serial 
                     2700       ; refresh (45 minutes) 
                     900        ; retry (15 minutes) 
                     604800     ; expire (1 week) 
                     3600       ; minimum (1 hour) 
                     ) 
$

SOA 레코드가 가지는 필드는 그 순서에 따라 개괄하면 다음과 같습니다. 필드명은 표준 명칭을 기준합니다.

용도 구분	SOA 필드 명칭	개요
마스터 네임서버 표시	mname	‘master name’의 약자 마스터 네임서버의 도메인 이름을 설정함
존 관리자 연락처 표시	rname	‘responsible name’의 약자 도메인 존 관리자/담당자의 e-mail 주소를 도메인이름 형식으로 표현하여 설정
존 데이터 동기화 관리기준	serial	도메인 존의 갱신 버전번호 정보 설정
	refresh	도메인 존을 갱신하는 주기 시간을 초단위로 설정
	retry	도메인 존 갱신여부 확인에 실패한 경우, 재시도 주기 시간을 초단위로 설정
	expire	도메인 존 갱신이 실패하여 도메인에 대한 DNS질의응답을 중단해야 하는 기간을 초단위로 설정
존에 없는 레코드의 TTL 값	minimum	존에 없는 도메인/레코드 응답 경우, 이 도메인/레코드(부재 도메인/레코드) 부재정보의 캐싱에 적용하는 TTL 값

 

SOA 필드의 용도 구분을 먼저 보면, 위 표에서 보는 바와 같이 대략 4개로 구분할 수 있습니다.

이 중에서 존 관리자 연락처를 표시하는 rname 필드를 제외한 나머지 필드들은 네임서버에게 알려주어야 할 "이 도메인 존을 어떤 기준으로 관리해야 하는가"에 대한 정보를 담고 있습니다. 캐시DNS서버를 위한 필드인 minimum 필드를 제외한 mname, serial, refresh, retry, expire 필드는 마스터 네임서버와 슬레이브 네임서버가 참조하는 필드입니다.

 

mname 필드는 이 도메인 존의 마스터 네임서버 도메인 이름을 설정합니다. 한마디로, 도메인 존(zone)이 “어디에 본거지를 두고 있는지”를 표시합니다. 마스터 네임서버가 도메인 존의 마스터 존 데이터를 가지고 있습니다. 이 마스터 네임서버의 도메인 이름을 설정합니다. SOA mname 필드에 설정된 마스터 네임서버 정보를 제외하고는, 외부에서 어떤 도메인의 여러 네임서버 중 어느 것이 마스터인지 어느 것이 슬레이브인지를 구분하는 방법은 따로 없습니다.

mname 필드값은 네임서버의 DNS Notify 처리 절차에서 참조되므로, 도메인 존에 대한 네임서버의 존 전송 관리에 관련되어 있습니다.

티스토리 도메인의 SOA 사례에서 mname은 ‘ns.daumzone.com’으로 설정되어 있습니다. 이상하죠? tistory.com의 네임서버 리스트를 질의해 보면 ‘ns1.daum.net’과 ‘ns2.daum.net’만 네임서버로 설정되어 있습니다. 외부에서 질의하는 네임서버 중에는 마스터 네임서버가 없는 경우입니다. 이것을 “Hidden Master”라고 합니다. tistory.com의 마스터 네임서버 ‘ns.daumzone.com’은 숨겨진 마스터 네임서버(Hidden Master)입니다.

mname 필드에 마스터 네임서버를 지정하여야 하지만, 임의의 네임서버 이름을 설정하는 경우도 적지 않습니다. 다만, mname 필드에 마스터 네임서버가 아닌 서버를 설정했을 때 SOA mname 필드 정보를 이용하는 표준 DNS기능(DNS Notify, DNS Update 등)이 이상하게 동작할 수도 있습니다.

rname 필드는 이 도메인 존을 관리하는 담당자의 연락처를 도메인이름 형식로 설정합니다. 도메인과 관련하여 도메인 관리자에게 전자메일을 보내야 할 경우에 사용할 수 있는 담당자 전자메일 계정정보가 기재됩니다.

rname 필드 값의 형식은 도메인이름입니다. 전자메일 계정정보는 해당하는 도메인이름 형식으로 변환하여 rname 필드에 설정하도록 되어 있습니다. 예를 들어 admin@example.com이 담당자 전자메일 계정이라면 ‘admin.example.com’으로 설정합니다. 규칙을 단순하게 말하자면, ‘@’문자를 ‘.’으로 대체하는 방식입니다.

만약 설정하고자 하는 전자메일 계정이 ‘dns.admin@example.com’이라면? 도메인 존 파일에 메일계정 사용자 아이디에 포함된 ‘.’을 문자 그대로 해석하도록 escape문자 ‘\’을 사용해서 ‘dns\.admin.example.com’이라고 표기해야 합니다. rname에 설정한 도메인 이름의 첫번째 레이블 ‘dns\.admin’은 전자메일 계정의 사용자 아이디로 설정하도록 약속되어 있습니다.

만약 rname 필드를 비워두고 싶다면? 곧, 전자메일 계정정보를 설정하고 싶지 않다면? 그냥 루트 도메인이름(‘.’)을 설정하면 됩니다. ‘.’으로 설정하면 전자메일 계정정보가 없다는 것을 의미합니다.

tistory.com의 SOA 레코드에 설정된 rname 값은 “hostmaster.daum.net”이므로 이 경우 담당자의 전자메일 주소는 “hostmaster@daum.net”이 됩니다.

rname 필드는 사람(관리자)이 참조하는 필드입니다. DNS 표준기능 중에는 이 rname 필드를 참조하여 동작하는 기능은 없는 것으로 보입니다.

serial, refresh, retry, expire 필드는 슬레이브 네임서버에게 아주 중요한 정보를 제공하는 필드입니다. 이 도메인 존의 주기적인 데이터 동기화 관리를 어떤 기준으로 해야 하는지를 표시합니다.

serial 필드는 도메인 존의 버전번호를 표시합니다. 도메인 존은 그 영역 내부에 설정된 DNS 레코드 값이 변동될 때마다 serial 버전번호를 “증가”시킵니다. serial 번호는 최신 도메인 존 정보여부를 확인하는 용도로 사용됩니다. 도메인 존 데이터 동기화 절차(존 전송절차)에서 마스터 네임서버의 도메인 존 데이터가 갱신된 최신 데이터인지 여부를 판별하는 “유일한 기준”입니다.

serial 필드에 설정하는 값은 그냥 10진수의 정수값입니다. 여기에 어떤 포맷으로 설정해야 한다는 규정은 없습니다.

다만, 관리운영상의 편의를 위해 주로 많이 사용하고 있는 통상적인 형식은 ‘YYYYMMDDnn’입니다. 관리자가 이해하기 쉬운 형식의 표현입니다. ‘YYYY’는 4자리의 연도, ‘MM’은 2자리로 표현한 월, ‘DD’는 2자리의 일자, ‘nn’은 해당일자에 이루어진 수정버전 일련번호를 2자리 숫자로 표현한 것입니다. 물론 이 형식으로 설정한 값은 그저 10진수 값이고 네임서버는 단순한 10진수 정수값으로 해석합니다. (serial 번호 관리 편이성를 위해 BIND DNS는 특정한 경우에 한해 이 serial 번호를 몇 가지 특정한 포맷으로 네임서버가 해석하여 관리하도록 하는 옵션을 제공하고 있기도 합니다.)

tistory.com의 SOA 예시에서 tistory.com 도메인 존의 serial 값은 2015090300으로 설정되어 있습니다. 이 설정은 ‘YYYYMMDDnn’ 형식에 해당합니다. 2015년 09월 03일에 첫번째(00)로 변경한 버전이라는 것으로 해석할 수 있습니다. 이 형식을 사용하면 이 도메인 존의 데이터가 언제 최종 갱신되었는지를 관리자가 쉽게 파악할 수 있는 이점이 있습니다.

종종 도메인 데이터를 수정한 관리자가 SOA serial 번호 수정 처리를 깜박해서 낭패를 겪는 경우가 발생합니다. 도메인 존의 레코드 데이터가 갱신되었지만 존의 SOA serial 번호가 증가되지 않으면, 슬레이브 네임서버들은 자신이 보유한 존 데이터의 버전과 동일하다고 보고 도메인 존 전송 요청을 하지 않는 일이 발생합니다. 관리자는 존 데이터를 수정 갱신하여 네임서버에 반영했다고 믿고 있지만 정작 슬레이브 네임서버들은 이전 버전의 존 데이터를 그대로 유지하는 상태에 놓여있게 됩니다. 슬레이브 네임서버는 도메인 갱신여부 체크에 있어 도메인 존의 레코드를 일일이 비교 검사하는 것이 아니라, 단순하게 SOA serial 번호의 증가 여부만 체크하여 판단합니다.

refresh, retry, expire 필드는 도메인 존의 “정기적인” 데이터 갱신주기에 대한 기준 값입니다. 각 필드 값은 초단위로 설정합니다. 슬레이브 네임서버는 이 3개 필드에 지정된 시간 값을 적용하여 도메인 존의 데이터 갱신 동기화 관리를 합니다.

refresh는 도메인 존의 데이터 변경여부를 어떤 주기로 체크할 것인지를 표시합니다. retry는 refresh에 지정된 주기로 체크하다가 장애 등으로 인해 도메인 존 변경여부를 확인하지 못한 경우에 다시 시도하는 재시도 주기를 표시합니다. 따라서 retry 값은 그 목적상 refresh 시간보다는 짧은 시간이어야 하겠죠. expire는 존 데이터 동기화 절차에 장애가 발생하여 retry를 수차례 반복하는 가운데 결국 존 데이터의 갱신시도를 최종적으로 포기하고 이 도메인 존을 폐기하여 서비스 중단처리하는 최대 기한을 표시합니다. expire 필드는 데이터 동기화 유지에 실패하고 있는 도메인 존을 그 상태 그대로 무한정 유지할 수는 없으므로, 동기화 실패상태 지속의 최대 시한으로 한정하는 데에 사용합니다.

그러면, refresh, retry, expire 필드 값을 어떤 값으로 설정하면 될까요? 설정 기준 값이 제시된 것이 있을까요? 꼭 이렇게 설정해야 한다는 규정은 없지만, 여러 가지 테스트 결과와 운영경험을 토대로 권고하고 있는 설정 기준값은 제시되어 있습니다. 이를 요약하여 정리하면 다음과 같습니다.

필드 구분	고려가능 기준값	비고 / 고려사항
refresh	3600 (1시간)	- RFC1912는 refresh 값으로 20분~2시간(고속 네트워크), 2시간~12시간(저속 네트워크) 설정 권고 - 현재 국내 네트워크 여건을 고려하면 1시간 정도가 무난 (RFC1912의 고속 네트워크 환경에 해당)
retry	900 (15분)	- RFC1912 : retry 값의 정수배가 refresh 값이 되도록 설정 권고 - 900 (retry) x 4 = 3600 (refresh)
expire	604800 (1주) 에서 2419200 (4주) 사이	- RFC1912 : 2주~4주 설정 권고 - 하지만 RFC1912 작성된 1997년보다 현재 네트워크 상황이 안정화 향상된 점 고려, 1주~4주 설정도 무난 - 서비스 환경, 시스템 관리운영 여건 등을 고려하여 설정 - 최악의 상황 고려하여 설정 (마스터 네임서버 장애가 방치된 상황에서 서비스 유지에 필요한 최소 시간 등)

 

구체적으로 위에 제시된 tistory.com의 사례를 보겠습니다.

tistory.com 도메인의 refresh는 2700초로 설정되어 45분 간격으로 마스터 도메인 존이 최신 정보로 변경되었는지를 확인하도록 되어 있습니다. retry는 900초로써 serial 번호확인이나 존 전송에 문제가 발생한 시점부터 15분 간격으로 재시도 하도록 되어 있습니다. expire는 604800초로 설정되어, 최신버전 확인 및 갱신처리가 실패한 시점부터 장애 지속상태가 1주일이 경과하면 슬레이브 네임서버가 tistory.com 도메인 존에 대한 DNS 서비스를 중단하도록 되어 있습니다.

이 설정은 도메인 존의 안정적인 관리운영을 기대할 수 있는 설정으로 통상적으로 권고하고 있는 기준범위에 적합한 설정이라 할 수 있습니다. retry 900초와 refresh 2700초 설정은 900 x 3 = 2700초로 refresh 시간이 retry 시간의 정수배가 되도록 설정하라는 권고 기준을 따르고 있습니다. expire는 1주를 설정하고 있는데 이는 체계적이고 상시적인 시스템 관리운영이 이루어지는 운영여건에서 볼 때는 문제를 인지하고 조치하는 데에 충분하고도 남아도는 시간설정이라 할 수 있습니다.

refresh, retry, expire 필드 값에 의한 “주기적인 도메인 존 데이터 동기화 처리” 기능은 사실 도메인 존 데이터 동기화 유지에 있어 “최후의 보루” 역할을 합니다. 실제로는 이 기능에 의한 동기화보다는 DNS Notify에 의해 데이터 변경이 발생할 때마다 그떄 그때 즉각 처리하는 존 데이터 동기화 방식이 먼저 적용되고 있기 때문입니다. 하지만 마스터 네임서버에 어떤 장애가 발생해서 DNS Norify에 의한 존 데이터 동기화가 작동하지 않게 되면, SOA refresh, retry, expire 필드에 의존하는 전통적인 “주기적인 도메인 존 데이터 동기화 처리” 기능에 의해 도메인 존의 운영관리가 유지됩니다.

이를 고려하면 SOA refresh, retry, expire 필드 값을 설정할 때는, 최악의 경우 곧 마스터 네임서버에 장애가 발생하고 이 장애가 일정시간 방치되는 등 최악의 경우를 상정하고 이에 적절한 값을 산정하여 설정하는 것이 필요하다고 볼 수 있습니다.

 

minimum 필드는 캐시DNS서버가 이 도메인에 설정되지 않은 도메인(부재 도메인) 또는 설정되지 않은 레코드(부재 레코드)를 에러응답으로 응답받았을 때 이 정보를 일정시간 동안 캐싱(caching) 처리해야 할 때 “얼마의 기간동안 캐싱해야 하는지”에 대한 시간정보를 제공합니다. 곧 캐시DNS서버에게 부재 도메인/부재 레코드에 대한 캐싱 시간을 도메인 관리자가 정해 주는 역할을 합니다. 따라서 이 minimum 필드를 참조하는 사용하는 주체는 캐시DNS서버입니다.

그러면, minimum 필드의 설정값은 어떻게 설정해야 할까요? 여기에도 역시 정답은 없습니다. 이 도메인을 사용하는 인터넷 서비스 특성을 감안하여 정하는 것이 필요합니다. minimum 필드값은 사이트 특성에 가장 영향을 많이 받을 수 있는 값이라 할 수 있습니다.

만약 이 도메인 내부의 레코드 추가가 자주 일어나는 편이라면, minimum 필드 값은 비교적 작은 값으로 설정하는 것이 좋습니다.

예를 들면 example.com 도메인에 원래 www.example.com의 A 레코드가 없는 상태였고 example.com의 SOA minumum 필드값이 1주(604800초)로 설정되어 있었다고 가정해 봅니다. 상당히 많은 이용자가 www.example.com으로 접속하려고 시도했다면, 이 사용자의 캐시DNS서버는 www.example.com 의 A 레코드 질의를 하고 그 응답으로 없는 도메인이름(NXDOMAIN)이라는 에러 응답을 받게 됩니다. 캐시DNS서버는 이 에러응답 정보를 캐싱합니다. 이를 네거티브 캐싱(Negative Caching)이라 합니다. 이때 example.com의 SOA minimum 필드 값을 보니 그 값이 1주(604800초)이기 때문에 이 에러응답 정보를 1주일간 캐싱하도록 처리합니다.

그런데 얼마 지나지 않아 example.com에서 www.example.com 웹 사이트가 마련되고 DNS 도메인 존에 www.example.com의 A 레코드를 추가 설정했을 때 문제는 발생 할 수 있습니다. 분명히 도메인 존에 www.example.com A 정보를 반영했는데도 인터넷에서는 접속이 되지 않습니다. 이유는 이 www.example.com은 존재하지 않는 도메인이름이라는 정보가 네거티브 캐싱에 의해 캐시DNS서버에 1주일 동안이나 박혀 있기 때문입니다. 캐시DNS서버는 www.example.com에 대한 A 레코드 질의가 있을 때마다 캐싱 메모리에서 이 부재도메인 정보를 찾아내어 인터넷 이용자에게 www.example.com은 인터넷 상에 없는 도메인 이름이라고 계속 응답해 주기 때문입니다.

이 상황은 최대 1주일 동안 지속될 것이고 www.example.com 웹 사이트는 1주일 후에나 정상적으로 접속이 가능하게 될 것입니다. 네거티브 캐싱으로 캐싱된 정보가 캐시DNS서버에서 모두 사라지는 그 시점부터 웹 서비스는 원활하게 접속되기 시작합니다.

이를 감안한다면, SOA minimum 필드 값을 정할 때 “이 도메인 존에서 얼마나 자주 레코드 추가가 일어날 것인가”를 먼저 고려하는 것이 중요하다는 것을 알 수 있습니다. 만일 신속한 서비스 추가가 중요시 되는 사이트라면, 특히 갑작스레 서비스를 시작해야 하니 도메인이름과 레코드 하나 추가해서 “즉시” 반영해 달라는 요청이 심심치 않게 발생하는 그런 사이트라면 SOA minimum 값을 되도록 작은 값으로 미리 설정해 두는 것이 필요합니다. 이 경우 대략 10분에서 20분 정도 사이 값이면 문제가 없지 않을까요?

만일, 그렇지 않다면 SOA mininum 값을 좀 더 크게 잡는 것이 좋습니다. SOA minimum 값을 크게 잡으면 쓸데 없는 질의가 계속 들어오는 것을 방지할 수 있기 때문입니다. 예를 들어 www.example.com 이라는 도메인 이름이 설정되어 있지도 않은데, SOA minimum 값이 5초로 설정되어 있으면 이 이름에 대한 질의가 5초마다 유입될 수도 있습니다. 캐시DNS서버에서 www.example.com에 대한 부재도메인(NXDOMAIN) 에러응답 정보가 5초마다 사라지기 때문에 캐시DNS서버가 다시 질의해 오게 되니까요. 불필요한 DNS질의 트래픽 유입을 초래하는 원인이 되고, 캐시 DNS서버 입장에서도 불필요한 DNS질의응답 처리건이 늘어나는 부담을 안게 됩니다.

그런데 필드 이름이 왜 minimum 일까요? minimum 필드의 이름이 그 용도와 맞지 않아 혼동을 일으킬 수 있는데, 왜 이름을 이렇게 지었을까요? 원래 초기 DNS 표준에서는 SOA minimum 필드 값은 도메인 존의 모든 레코드에 적용하는 최소 TTL 값으로 정의되어 있어 “minimum TTL 값”이라는 의미를 가지고 있었습니다. 필드 명칭과 용도가 일치했었습니다. 그런데 이후에 네임서버의 DNS 질의응답 레코드 처리절차를 보다 명확하게 표준 정의하면서, SOA minimum 값의 용도를 보다 축소된 구체적인 용도의 필드로 개정했습니다. “네거티브 캐싱(negative caching)용 TTL 값”을 지정하는 용도로 한정하였습니다. 설정이 안된 없는 도메인 이름과 레코드는 TTL 정보도 설정된 것이 없으니, 캐시DNS서버는 도메인 존의 최소 TTL값(minimum TTL)을 캐싱 시간으로 적용한다는 의미로 아직 SOA minimum 필드 명칭을 그대로 사용하고 있습니다. 하지만 용도를 변경하면서 표준 명칭도 SOA ncaching 등으로 용도를 알기 쉬운 명칭으로 그때 바꾸었으면 좋았지 않았을까 생각합니다.

tistory.com의 경우는 SOA minimum 값으로 3600초(1시간)을 설정하고 있습니다. 티스토리 서비스는 새로운 DNS 레코드가 추가되더라도 최대 1시간 정도의 지연시간으로 인터넷에 반영 되기만 하면 문제가 없다고 판단해서 1시간으로 설정하고 있는 것 같습니다.