도메인·호스팅

DNS

DNS는 도메인 이름에 관한 정보를 분산해 관리하고 조회하는 시스템입니다. 웹서버 주소뿐 아니라 메일 수신 서버 등 여러 종류의 정보를 레코드로 제공하므로, DNS 변경을 홈페이지 주소 하나 바꾸는 일로만 생각하면 안 됩니다.

검토 2026-11-03·작성 김종현

DNS는 도메인 이름에 관한 정보를 분산해 관리하고 조회하는 시스템입니다. 웹서버 주소뿐 아니라 메일 수신 서버 등 여러 종류의 정보를 레코드로 제공하므로, DNS 변경을 홈페이지 주소 하나 바꾸는 일로만 생각하면 안 됩니다.¹

제작 방식: AI로 자료 조사와 초안 작성을 보조했습니다.

쉬운 설명: 한 이름에 여러 종류의 정보가 있습니다

DNS 레코드는 이름과 유형, 값 등을 함께 읽습니다. A 레코드는 IPv4 주소를, MX는 메일 교환 서버를, CNAME은 다른 이름을 가리키는 별칭을 나타냅니다. TXT는 텍스트 정보를 담는 유형입니다. 화면에 여러 줄이 보여도 각 줄이 같은 역할을 하는 것은 아닙니다.¹

IPv6 주소는 AAAA 레코드로 표현합니다. 웹사이트 이전 때 A만 새 서버로 바꾸고 기존 AAAA를 남기면 이용 환경에 따라 서로 다른 서버로 접속할 가능성이 있습니다. IPv6를 쓰는지 확인하지 않은 채 'A가 맞으니 연결 완료'라고 판단해서는 안 됩니다.²

DNS 캐시도 구분해야 합니다. 조회하는 쪽에 이전 응답이 남을 수 있고, 이름이 없다는 부정 응답도 캐시될 수 있습니다. 따라서 설정 화면에 저장됐다는 사실과 모든 조회 지점에서 새 응답을 받는다는 사실은 다릅니다. 변경 뒤 무조건 같은 시간만 기다리면 해결된다고 약속하지 않습니다.³

네임서버 변경과 개별 레코드 변경은 영향 범위가 다릅니다. 현재 권한 있는 DNS가 어디인지 모르면 사용하지 않는 서비스의 설정만 수정할 수도 있습니다. 도메인 등록업체에서 본 값과 실제 질의 결과를 구분해 기록하는 이유입니다.

실무에서는 변경할 줄과 보존할 줄을 나눕니다

다음은 웹서버만 이전하는 가상의 적용 예시입니다. 메일서비스는 그대로 두는 상황을 전제로 합니다. 아래 표는 실제 변경 명령이 아니라 작업 전 비교표입니다.

항목	변경 전에 확인할 것	변경 뒤 확인할 것
루트·www 웹 이름	각각의 A·AAAA·별칭 구성	두 이름의 실제 응답과 목적지
MX	기존 메일 수신 서버	웹 이전 중 값이 보존됐는지
TXT	메일 인증·소유확인 등 사용 목적	무관한 인증값이 삭제되지 않았는지
TTL·캐시	기존 응답의 보존 조건	권한 서버와 재귀 조회 결과의 차이
HTTPS	새 서버가 제공할 인증서 이름	실제 접속 이름과 인증서 일치

변경 전에는 레코드 목록과 웹·메일 사용처를 정리합니다. 변경 후에는 '대시보드에서 저장됨'과 '실제 DNS 응답이 바뀜', '웹서비스가 정상 동작함'을 따로 확인합니다. DNS는 원하는 주소를 돌려줄 수 있어도 그 서버의 웹 프로그램이 실행되는지까지 보장하지 않습니다.

문제가 생겼을 때는 관측 위치도 남겨야 합니다. 어느 이름을 어떤 유형으로 조회했는지, 조회한 시각과 응답이 무엇인지가 없으면 캐시 차이인지 잘못된 설정인지 판단하기 어렵습니다. 전파라는 말 하나로 오류를 덮지 않고 비교 가능한 기록을 남깁니다.

웨비스튜디오 작업 기록

법률사무소 B에서는 웹 접속용 레코드를 고정 IP로 바꾸는 과정에서 기존 MX와 메일 인증·검증용 TXT를 유지하는 범위를 정했습니다. 연결 뒤 도메인과 인증서의 불일치도 별도로 해결한 기록이 있습니다. 웹 연결 변경과 메일 이전을 같은 작업으로 취급하지 않은 사례입니다.

자주 하는 실수와 수정 기준

기존 레코드를 모두 지우고 시작하는 것. 웹과 무관한 메일·인증 레코드가 섞여 있을 수 있습니다. 목적이 확인된 변경 대상만 정하고 보존할 항목을 먼저 기록합니다.

별칭과 HTTP 이동을 같은 것으로 보는 것. DNS에서 이름을 연결하는 일과 브라우저를 다른 URL로 보내는 일은 다릅니다. 주소창이 바뀌어야 하는 요구라면 웹서버의 이동 처리까지 별도로 검토합니다.

시간만 지나면 낫는다고 답하는 것. 권한 서버의 값이 틀리면 기다려도 원하는 응답이 되지 않습니다. 실제 설정과 캐시 응답을 구분해서 확인한 뒤 판단합니다.³

IPv4 접속만 검사하는 것. A와 AAAA를 함께 확인하고, 의도하지 않은 목적지가 남아 있으면 그 영향을 조사합니다. 사용하지 않는다고 추정해 무조건 삭제하는 대신 현재 사용 구성을 먼저 확인합니다.²

FAQ

DNS 변경은 언제 끝났다고 볼 수 있나요?

저장 완료만으로 판단하지 않습니다. 필요한 이름의 실제 응답, 웹 접속, HTTPS, 유지해야 할 메일 기능을 확인해야 합니다. 모든 환경에 같은 완료 시간을 약속하기보다 확인 범위와 남은 차이를 기록합니다.

A 레코드를 바꾸면 메일도 자동으로 옮겨지나요?

그렇게 단정할 수 없습니다. 메일 수신은 MX 등 별도 구성을 사용하며 웹 레코드와 역할이 다릅니다. 메일을 유지할지 이전할지부터 명확히 하고 해당 서비스의 안내를 따릅니다.¹

DNS를 고쳤는데 인증서 경고가 남는 이유는 무엇인가요?

새 목적지 서버가 올바른 인증서를 제공하지 않을 수 있습니다. DNS 응답과 인증서 이름 일치를 각각 확인해야 합니다. 같은 서버에 여러 사이트가 있으면 요청한 이름에 맞는 설정으로 응답하는지도 봅니다.

공식 출처

공식 문서 확인일: 2026-11-03. 특정 캐시 만료 시간이나 일괄 전파 시간을 제시하지 않았습니다.

IETF, RFC 1035 — DNS 레코드와 구현 규격: https://www.rfc-editor.org/rfc/rfc1035.html ↩ ↩² ↩³
IETF, RFC 3596 — DNS의 IPv6 확장과 AAAA: https://www.rfc-editor.org/rfc/rfc3596.html ↩ ↩²
IETF, RFC 2308 — DNS 부정 응답 캐시: https://www.rfc-editor.org/rfc/rfc2308.html ↩ ↩²