AAAA 주소에서 숫자 하나가 빠졌다: 펀치블로그의 IPv6 수정 기록

2026년 10월 6일 펀치블로그의 DNS를 점검하면서 루트 도메인의 AAAA 값이 서버에 할당된 IPv6 주소와 다르다는 것을 확인했다. 보관된 변경 전 응답에는 406:da12:43b:5300:708:d8d9:ca66:1e44, 변경 후에는 2406:da12:43b:5300:708:d8d9:ca66:1e44가 들어 있다. 첫 묶음의 맨 앞 숫자 2 하나가 차이였다.

이 글은 그때의 변경 전후 자료와 수정 직후 확인 결과를 다시 대조하고, 10월 15일 현재 접속을 새로 검사한 기록이다. 수정 전의 실패 요청이나 방문자별 오류율은 보관돼 있지 않다. 따라서 모든 IPv6 방문자가 실패했다고 단정하거나, 이 오타를 특정 외부 서비스의 심사 결과와 연결하지 않는다.

형식상 맞는 주소도 잘못된 목적지일 수 있다

IPv6 표기에서 한 묶음이 네 자리보다 짧을 수 있으므로 406이라는 묶음 자체는 문법 오류가 아니다. Python의 IPv6Address로 두 문자열을 읽어도 모두 주소 객체가 만들어졌다. 하지만 두 객체를 비교한 결과는 False였다. 입력란이 값을 받아들이거나 형식 검사 도구가 통과시켜도, 실제 서버에 할당된 주소와 일치하는지는 따로 대조해야 한다.

from ipaddress import IPv6Address

before = IPv6Address('406:da12:43b:5300:708:d8d9:ca66:1e44')
after = IPv6Address('2406:da12:43b:5300:708:d8d9:ca66:1e44')
print(before == after)  # False

이 주소는 당시 펀치블로그의 관찰값이다. 다른 서버에는 복사하지 않는다. 자신의 서버 관리 화면에 표시된 할당 주소와 해당 도메인의 AAAA를 비교해야 한다. 실제 수정 스크립트도 새 주소가 서버의 전역 IPv6 인터페이스에 존재하는지 검사한 뒤 진행하도록 작성돼 있었다.

수정한 DNS 영역과 변경 범위를 확인했다

9월의 최초 연결 기록에서는 Cloudflare가 DNS를 담당했지만, 10월 6일 수정은 AWS Lightsail DNS에서 수행했다. 예전 글에 적힌 관리 업체를 그대로 따라가기보다 현재 NS 위임을 먼저 확인해야 하는 이유다. 2026년 10월 15일 재검사에서도 NS는 네 개의 awsdns 이름으로 조회됐다.

dig +short punchblog.com NS
dig +short punchblog.com A
dig +short punchblog.com AAAA

보관된 AWS 응답을 대조하면 AAAA의 target뿐 아니라 그 레코드의 내부 ID도 달라졌다. 처음부터 모든 ID가 같아야 한다고 검사하면 정상 수정도 실패로 분류할 수 있는 상황이었다. 당시에는 ID를 제외한 레코드 필드를 정규화한 다음, 해당 AAAA의 target만 바뀌었고 다른 레코드 필드는 그대로인지 비교했다. 이번 원고 검토에서도 같은 비교를 다시 실행해 일치를 확인했다.

저장 성공 다음에는 DNS와 HTTPS를 나눠 확인했다

수정 직후에는 권한 DNS 네 곳, 공개 재귀 리졸버 두 곳, 서버의 기본 리졸버 한 곳을 조회했다. 보관된 일곱 결과 모두 수정된 2406으로 시작하는 주소를 반환했다. 이는 그때 조회한 지점의 결과이며 전 세계 DNS 캐시가 동시에 갱신됐다는 측정은 아니다.

DNS 답변이 맞아도 HTTPS 수신과 인증서가 맞는지는 별도 질문이다. 당시 보관된 HTTPS 검사에서는 -4와 -6을 각각 사용했고, 두 주소 체계 모두 홈과 개인정보처리방침에 도달했다. 일반 접속 한 번이 성공했다는 결과에 두 주소 체계의 상태를 묶지 않았다.

curl -4 -sS --connect-timeout 3 --max-time 10 \
  -o /dev/null -w 'HTTP=%{http_code} IP=%{remote_ip} TLS=%{ssl_verify_result}\n' \
  https://punchblog.com/
curl -6 -sS --connect-timeout 3 --max-time 10 \
  -o /dev/null -w 'HTTP=%{http_code} IP=%{remote_ip} TLS=%{ssl_verify_result}\n' \
  https://punchblog.com/

이 예제는 본문을 버리고 상태·연결 IP·TLS 검증 결과를 출력한다. -k로 인증서 검증을 생략하지 않는다. curl의 명령 성공과 HTTP 200도 구분해야 한다. 기본 curl은 HTTP 오류 응답을 받아도 전송 자체가 성공하면 종료 코드 0을 줄 수 있으므로 출력된 상태를 함께 읽는다. IPv6 검사만 실패하면 검사한 컴퓨터에 IPv6 경로가 있는지도 확인해야 한다.

10월 15일 재검사에서도 두 경로를 확인했다

2026년 10월 15일 공개 DNS를 조회하고 IPv4·IPv6 각각 홈과 개인정보처리방침에 GET을 보냈습니다. 네 요청 모두 HTTP 200, curl 종료 코드 0, TLS 검증 결과 0이었습니다. 그때 조회한 AAAA는 수정 후 주소와 같았습니다. 상세 시각과 연결 IP는 아래 원자료에 있습니다. 10월 6일 수정 직후 자료와 10월 15일 재검사는 다른 시점의 관찰이며, 두 시점 사이의 지속 가동이나 이 글을 읽는 날의 응답을 입증하지 않습니다.

같은 증상에서 다음에 확인할 것

이번 사례에서 바꾼 값은 작았지만 확인 단계는 주소 형식, 할당 주소, DNS 답변, HTTPS 응답으로 나뉘었다. 특히 관리 화면의 저장 성공과 실제 웹 요청의 성공 사이를 별도로 검사해야 했다. 운영 기록에는 변경 전 값과 되돌릴 값, 수정 직후 검사, 이후 재검사를 구분해 남기는 편이 다음 점검에 도움이 됐다.

• 도메인을 등록했는데 사이트가 안 열렸다: 펀치블로그 연결 기록

  9월 최초 연결 당시의 DNS·웹 서버·인증서 설정을 현재 기록과 구분해서 읽는다.

• curl -I의 200만으로 충분할까: HEAD·GET 배포 확인 실험

  200 응답 다음에는 GET 본문이 기대한 문서인지 확인한다.

python3 check-dual-stack.py --output new-observations.json