도메인 설정 화면에서 A와 CNAME 중 무엇을 고를지 막히는 순간이 있다. 둘 다 이름을 연결하는 것처럼 보이지만 오른쪽에 적는 값이 다르다. A는 이름을 IPv4 주소에, CNAME은 한 이름을 다른 호스트 이름에 연결한다.
A 레코드와 CNAME은 무엇을 가리킬까?
가상의 app.example.test가 서버 주소 192.0.2.10을 가리키면 A 레코드다. www.example.test를 app.example.test의 별칭으로 만들면 CNAME이다. 뒤의 설정에서 CNAME 값은 IP 숫자가 아니라 다른 이름이다.
| 레코드 | 이름 | 값 | 읽는 법 |
|---|---|---|---|
| A | app.example.test | 192.0.2.10 | 이 이름의 IPv4 주소 |
| CNAME | www.example.test | app.example.test | 다른 이름으로 이어지는 별칭 |
이 예제에서 브라우저가 www.example.test를 찾으면 별칭을 따라 app.example.test의 주소를 알아내는 흐름이다. 그림에서도 A 화살표는 IP로, CNAME 화살표는 이름으로 향한다.
DNS를 바꿨는데 여전히 옛 주소가 보이면?
먼저 편집한 호스팅 영역이 실제로 위임된 영역인지 확인한다. 다른 영역에 같은 이름을 만들면 콘솔에는 레코드가 있어도 외부 응답은 달라질 수 있다. 다음으로 레코드의 이름·유형·값을 각각 비교한다. www를 바꾸려다 app만 바꾼 것은 아닌지도 흔한 확인 지점이다.
터미널에서는 실제로 소유한 도메인으로 바꿔 아래처럼 두 유형을 따로 조회할 수 있다. 이 예제의 .test 주소는 설명용이므로 그대로 조회해 정상 응답을 기대하지 않는다.
dig A app.example.test
dig CNAME www.example.test조회 결과가 기대와 다르면 먼저 조회한 이름이 정확한지, 레코드를 추가한 호스팅 영역이 실제 도메인에 연결된 영역인지 다시 본다. 서비스 전환이라면 기존 값을 기록해 두어야 잘못된 설정을 되돌릴 수 있다.
레코드를 새로 만들 때는 고정 IPv4 주소를 직접 가리키는지, 다른 호스트 이름을 따라갈지부터 결정한다. 유형을 고른 뒤에는 레코드 이름과 값을 따로 검토한다. 위 예제는 두 하위 도메인에 한정되므로 도메인 최상위 이름이나 AWS 리소스 별칭처럼 다른 제약이 있는 경우를 같은 두 행으로 처리하면 안 된다.
핵심 요약
Route 53의 A는 호스트 이름을 IPv4 주소에, CNAME은 다른 호스트 이름에 연결한다. 변경이 반영되지 않을 때는 위임된 호스팅 영역, 이름·유형·값, 캐시 순서로 확인하자. 레코드 선택은 주소의 모양보다 실제 연결 대상에서 시작한다.
