DNS 레코드 유형, A와 CNAME과 TXT를 쓰는 자리

유형은 하는 일로 세 묶음으로 나뉩니다

레코드 유형이 많아 보이지만 하는 일로 묶으면 세 가지입니다. 첫째는 주소를 알려 주는 유형입니다. 이름에 대해 서버 주소를 직접 알려 줍니다. 둘째는 다른 이름으로 넘기는 유형입니다. 자기 자신은 주소를 모르고 다른 이름을 가리킵니다. 셋째는 정보를 담는 유형입니다. 메일 수신 서버를 알려 주거나 소유 확인용 문자열을 담습니다. 이렇게 나누면 어떤 상황에 어떤 유형을 써야 하는지 바로 정해집니다. 또 유형마다 같은 이름에 함께 둘 수 있는지가 다르므로, 묶음을 알면 충돌하는 조합을 피할 수 있습니다.

루트 도메인에는 넘기는 유형을 쓸 수 없습니다

가장 자주 걸리는 제약이 여기 있습니다. 다른 이름으로 넘기는 유형은 같은 이름에 다른 레코드와 함께 둘 수 없고, 루트 도메인에는 쓸 수 없는 것이 원칙입니다. 그런데 루트 도메인을 전송 서비스나 호스팅 플랫폼에 연결해야 하는 경우가 흔합니다. 해결 방법은 두 가지입니다. 첫째, DNS 공급자가 제공하는 평탄화 기능을 쓰는 것입니다. 겉으로는 넘기는 유형처럼 적지만 응답은 주소 유형으로 나갑니다. 둘째, 루트는 주소 유형으로 고정하고 실제 서비스는 하위 도메인에 두고 루트에서 리다이렉트하는 것입니다. 두 방법의 차이를 문서에 적어 둡니다.

레코드 수를 세고 점검 시간을 계산합니다

학습용 가정으로 계산합니다. 가정값은 루트 도메인 1개, 하위 도메인 6개, 메일 관련 3개, 소유 확인용 2개로 총 12개 레코드를 둔다고 하겠습니다. 변경 작업 뒤 각 레코드가 의도대로 응답하는지 확인하는 데 2분이 걸리면 24분입니다. 내부 시간 비용을 시간당 30,000원으로 가정하면 12,000원입니다. 이것이 중간 계산값입니다. 최종 판단은 누락 비용과 비교해서 합니다. 소유 확인용 레코드를 잘못 지우면 외부 서비스 연동이 끊기고, 메일 레코드를 놓치면 메일이 들어오지 않습니다. 24분의 점검이 그 두 사고를 막는 유일한 단계입니다.

지우기 전에 누가 쓰는지 확인합니다

결론을 뒤집는 조건은 용도를 알 수 없는 레코드입니다. 정체를 모르는 레코드가 있을 때 지우는 쪽이 깔끔해 보이지만, 외부 서비스의 소유 확인용이면 지우는 순간 그 서비스가 해지됩니다. 그래서 정리 원칙을 이렇게 둡니다. 용도가 적혀 있지 않은 레코드는 지우지 않고, 대신 용도 조사 목록에 올립니다. 조사 방법은 레코드 값으로 검색해 어느 서비스 형식인지 확인하는 것입니다. 두 번째 조건은 TTL입니다. 지우거나 바꾸기 전에 보관 시간을 낮춰 두지 않으면 변경이 느리게 퍼지므로, 변경 전날에 보관 시간을 먼저 낮춥니다.

웹호스팅 실행 전 점검표

• 레코드를 주소·전달·정보 세 묶음으로 분류했다
• 루트 도메인에 전달 유형을 쓰지 않도록 대안을 정했다
• 변경 뒤 레코드별 응답을 확인했다
• 용도를 모르는 레코드는 지우지 않고 조사 목록에 올렸다