도메인과 네임서버
누구 이름인가 다음에 누가 열 수 있나, 바꾼 다음에는 권위 서버에
도메인 회수와 사이트 직접 관리를 이어 쓰는 글입니다. 그 글이 외주에 묶인 도메인을 조직 명의로 되찾는 순서를 다뤘다면, 이 글은 협동조합과 교육기관과 의료사협 현장에서 도메인을 추적하고 네임서버를 옮기다가 넘어진 자리를 모았습니다. 조직 이름과 도메인 실물과 업체 이름은 지웠습니다.
요지
도메인은 「누구 이름으로 되어 있나」를 확인한 다음에 「그 함을 누가 열 수 있나」를 물어야 합니다. 도메인을 추적할 때는 도메인 종류와 관리 계층부터 보고, 등록 기록의 항목 이름을 내가 알고 싶은 뜻으로 옮겨 읽지 않습니다. 네임서버를 옮기는 날에는 메일 레코드를 먼저 지키고, 방금 쓴 값은 권위 네임서버에 직접 물어 확인합니다.
1. 이름이 조직 것인 것과 조직이 열 수 있는 것은 다른 칸이다
한 협동조합의 도메인을 점검했더니 등록자, 소유자 이메일, 등록기관 계정이 모두 조합 명의였습니다. 우리는 여기서 「명의 깨끗함」으로 닫으려 했는데, 그것은 점검의 절반이었습니다. 소유자 인증 메일은 소유자 이메일 함으로 가기 때문에, 통제권은 그 함의 비밀번호와 2단계 인증 복구 연락처를 누가 쥐고 있느냐에서 정해집니다.
두 단으로 보는 점검 방법과 담당자 개인 번호를 다루는 원칙은 도메인 회수와 사이트 직접 관리의 1절에 있습니다. 여기서는 그 현장 기록이 덧붙인 일반화 하나만 적어 둡니다. 열쇠가 어디 있는지 물을 때 「누구 이름으로 되어 있나」 다음에 「누가 열 수 있나」를 붙이는 질문은 도메인에만 해당하지 않습니다. 클라우드 계정, 결제 수단, 공용 메일, 코드 저장소에도 같은 질문을 던집니다.
2. 도메인 종류마다 공개 규정이 다르다
우리 기록에 따르면 국가 도메인인 .kr은 국내 등록소가 관리하고, 등록인과 관리 책임자의 이름과 이메일이 공개 조회에 나옵니다. 한 단체의 .kr 도메인은 조회 한 번으로 소유자 이메일을 찾았습니다. 그런데 다른 조직의 .org 도메인에 같은 방법을 썼더니 아무것도 나오지 않았습니다. .org 같은 일반 도메인은 국제 개인정보 규정이 시행된 뒤로 등록인 정보가 모두 가려지고, 등록기관 이름과 신고 연락처만 공개됩니다.
- 한 번 통한 방법을 종류가 다른 도메인에 그대로 쓰지 않습니다. 최상위 도메인이 무엇인지부터 봅니다.
- 조회 도구가 설치되지 않은 서버에서는 새로 설치하지 않고 HTTPS로 묻는 DNS 조회와 RDAP 조회로 대신합니다.
- 공개 조회로 소유자를 찾을 수 없으면 옛 계정을 되살리려 애쓰지 않고, 등록기관에 법인 서류로 지금의 등록인과 계정 복구 가능 여부를 묻습니다. 도메인의 통제권은 옛 로그인 계정이 아니라 등록인 명의가 정하기 때문입니다.
3. .kr 도메인의 관리 주체는 세 층일 수 있다
한 협동조합이 도메인을 직접 관리하게 하려고 나섰는데 세 번 막혔고, 그 기록을 보면 세 번 다 원인이 달랐습니다.
| 막힌 곳 | 처음 내린 판단 | 실제 |
|---|---|---|
| 공개 조회의 등록인이 낯선 주소였다 | 남의 것일 수 있다 | 등록기관의 개인정보 보호 서비스 주소였고, 명의는 처음부터 조합이었다 |
| 등록기관에 조합 계정이 있는데 도메인이 0개였다 | 계정이 우리 것이 아니다 | 계정은 조합 것이었고, 도메인이 다른 계정에 있었을 뿐이다 |
| 도메인을 추가하자 「다른 고객의 자산」이라고 떴다 | 같은 등록기관의 제3의 계정이다 | 그 등록기관의 하청 리셀러 계정이었다 |
.kr 도메인은 등록소 아래에 공개 조회에 찍히는 등록대행자가 있고, 그 아래에 실제 계정과 관리 화면을 가진 리셀러가 있을 수 있습니다. 공개 조회의 등록대행자 이름만 보고 그 회사 사이트로 가면 헛걸음할 수 있습니다.
- 「다른 고객의 자산」 문구가 뜨면 웹에서 더 누를 것이 없으므로 등록대행자 고객센터에 전화해 어느 리셀러가 관리하는지 묻습니다.
- 그 화면이 가려서 보여 주는 소유자 이메일의 글자 수와 모양으로 주소를 거의 되살릴 수 있고, 그 주소로 아이디 찾기를 하면 계정이 잡힙니다. 법인이면 기업 회원으로 찾습니다.
- 계정에는 퇴사한 사람의 휴대폰이 남아 있을 수 있으니 인증 수단은 이메일로 고르고, 계정을 되찾으면 연락처부터 바꿉니다.
- 화면 주소를 짐작해서 안내하지 않습니다. 그 등록기관은 없는 경로에도 모두 200을 돌려줘서 밖에서는 진짜 경로를 가려낼 수 없었습니다.
리셀러 계정을 열어 보니 목표였던 도메인과 함께 아무도 몰랐던 도메인이 하나 더 나왔습니다. 관리권을 되찾으면 모르던 자산까지 같이 드러납니다.
4. 등록기관은 호스팅 운영사가 아니다
한 의료사협이 쓰는 업무 프로그램이 어느 호스팅에서 도는지 밝히다가, 그 주소의 도메인 등록기관을 보고 「이 업체의 호스팅이고 다른 업체는 아니다」라고 단정한 일이 있었습니다. 현장에서 「다른 업체 계정과도 물려 있다」고 정확히 말한 사람의 말을 우리가 「정정」해 버린 것입니다. 등록기관은 그 도메인을 어디서 샀는지를 말할 뿐, 그 서버를 누가 돌리는지는 말하지 않습니다.
우리가 정한 운영사 확인 순서는 이렇습니다.
- 먼저 IP를 조회하는데, 국내 통신사 대역이면 최종 사용자가 등록돼 있지 않아 여기서 막힙니다.
- 그 주소가 내놓는 TLS 인증서의 이름 목록을 봅니다. 공유 호스팅은 업체의 와일드카드 인증서를 그대로 쓰기 때문에 이것이 가장 싸고 확실합니다. 그날은 접속 실패 메시지에 찍힌 인증서 이름이 답이었습니다.
- 같은 IP를 가리키는 다른 도메인을 찾아 운영사를 짐작합니다.
- 도메인 등록기관은 마지막에, 참고로만 봅니다.
현장 사람이 한 말은 데이터라고 봅니다. 그 말을 뒤집으려면 그보다 센 증거가 있어야 하고, 등록기관 한 줄은 그만한 증거가 아닙니다.
5. API로 만든 DNS 존은 비어 있다
작업 기록에 따르면 클라우드플레어 대시보드에서 사이트를 추가하면 기존 네임서버의 레코드를 훑어 가져오지만, API로 존을 만들면 레코드가 0개인 빈 존이 생깁니다. 그 상태로 네임서버를 넘기면 메일을 포함해 도메인 전체가 죽습니다.
- 존을 만든 뒤 지금의 권한 서버에 이름마다 직접 물어 레코드 전체를 뜹니다. 존 전체를 한 번에 넘겨받는 요청은 대개 막혀 있습니다.
- 인증서 투명성 기록에서 그 도메인으로 인증서를 받은 적이 있는 호스트 이름을 찾아 빠진 것이 없는지 대조합니다.
- 남의 권한 서버에 물을 때는 간격을 둡니다. 간격 없이 훑다가 시간 초과가 쏟아졌는데, 그것을 「레코드가 있다」로 읽을 뻔했습니다. 시간 초과는 오류로 따로 셉니다.
- 새 존에 심은 뒤 옛 값과 글자 단위로 비교하고, 비교 스크립트가 마지막 줄을 흘리지 않는지도 봅니다. 차이가 나오면 데이터보다 내 캡처부터 의심합니다.
- 서버를 가리키는 레코드는 처음엔 프록시를 끈 채로 넣어 지금과 똑같이 동작하게 하고, 옮길 준비가 된 호스트만 프록시를 켭니다.
6. 네임서버를 바꾸는 날
메일 레코드를 가장 먼저 넣는 순서와 네임서버 값을 손으로 옮겨 적게 하지 않는 원칙은 도메인 회수와 사이트 직접 관리의 3절과 AI가 사람 손을 먼저 쓰지 않게의 4절에 있습니다. 같은 현장 기록이 남긴 나머지를 적습니다.
네임서버 한 글자 오타는 절반 고장이 아니라 점점 번지는 전면 장애입니다. 존을 다른 계정으로 옮긴 현장 기록에 따르면 한 글자 빠진 이름이 들어가자 새 존의 위임 확인이 실패해 대기 상태로 굳었고, 터널로 내보내던 호스트부터 죽었으며, 나머지는 옛 네임서버의 캐시로 버티다 캐시 시간이 끝나는 순서대로 하나씩 죽었습니다. 처음엔 호스트 하나만 죽고 나머지 열일곱 개는 200이라 「일시적」으로 보였습니다. 캐시가 버텨 주는 것이지 정상이 아닙니다.
- 교체 직후 등록기관에 들어간 값을 기대값과 글자 단위로 대조합니다.
- 호스트 하나만 죽고 나머지가 멀쩡하면 전파 문제부터 의심합니다.
- 클라우드플레어의 네임서버 쌍은 계정이 아니라 존마다 다르므로, 다른 도메인에서 쓴 값을 다시 쓰지 않고 매번 새로 받은 값을 씁니다.
- 전체 호스트를 HEAD 요청으로 점검했더니 세 곳이 405를 돌려줘 장애처럼 보였는데, GET으로 다시 재니 모두 200이었습니다. 앱 서버는 HEAD 요청을 받지 않을 수 있으니 앱이 물린 호스트는 GET으로 잽니다.
국내 등록기관 화면은 직접 보고 안내합니다. 카페24의 네임서버 변경 화면에서는 「다른 네임서버」를 고르고 호스트 이름만 넣은 채 저장을 누르면 IP 주소를 확인하라는 경고가 뜹니다. 줄마다 「IP 확인」 버튼을 눌러 IP 칸을 채워야 저장된다는 것이 한 협동조합 현장의 실측 기록입니다. 우리는 그 화면을 본 적 없이 「IP 칸은 비워 두셔도 됩니다」라고 안내했고, 현장에서 그대로 막혔습니다. 안 본 화면은 「보이는 대로 하시고, 막히면 화면을 보내 주십시오」라고 안내합니다.
화면에는 변경 완료까지 24시간에서 48시간이 걸린다고 나오지만, 우리가 잰 .kr 도메인 전파는 몇 분에서 15분 사이였습니다. 이틀을 기다린다고 손을 놓지 않습니다.
7. 방금 쓴 레코드는 권위 네임서버에 묻는다
기록을 보면 도메인 소유권 확인용 레코드를 넣고 바로 확인했는데, 같은 순간 공개 리졸버에서는 0건이고 권위 네임서버에서는 정상이었습니다. 공개 리졸버는 직전에 「없음」이라고 받은 답까지 캐시해 두기 때문에 그 시간이 지날 때까지 새 값을 보여 주지 않습니다.
- 내가 방금 쓴 레코드는 권위 네임서버에 직접 묻습니다. 거기 있으면 쓰기는 성공한 것이니, 전파를 기다리는 것과 실패한 것을 가릅니다.
- 「아직 안 올라갔네」 하고 다시 넣으면 같은 레코드가 겹쳐 쌓입니다.
- 사용자가 실제로 보는 값을 확인할 때는 공개 리졸버가 맞습니다.
- 「이 작업이 메일 레코드를 건드리지 않았다」는 증거도 권위 네임서버에서 뜹니다.
네임서버를 옮긴 뒤 내 컴퓨터에서 옛 서버가 응답하면 대개 내 쪽 리졸버의 캐시입니다. 시스템 리졸버와 공개 리졸버가 주는 값을 나란히 놓고, 다르면 캐시로 봅니다. 엣지 서버 주소를 직접 지정해 물어보면 지금 상태를 볼 수 있고, 이때 인증서 오류가 나는 것은 새 인증서가 발급되기 전이라면 정상입니다.
「내 컴퓨터에서는 되는데 저 사람 컴퓨터에서는 옛 화면이다」라는 말을 들으면, 그 사람에게 정적 호스팅이 처음 준 기본 주소를 열어 보게 합니다. 거기서 새 사이트가 뜨면 배포는 멀쩡하고 그 사람 쪽 DNS 캐시가 원인입니다. 윈도에서 DNS 캐시를 비우고 강력 새로고침을 하면 대개 풀립니다.
8. 새 CDN 계정에서 먼저 볼 것
- 한 협동조합의 새 계정 기록에 따르면 클라우드플레어는 이메일 인증을 마치기 전에는 API 토큰을 오류 없이 조용히 만들지 않았습니다. 화면에 아무 경고도 없이 토큰 목록만 비어 있었습니다. 새 서비스 계정에 무엇을 시키기 전에 인증, 결제, 요금제 같은 계정 상태부터 봅니다.
- 신규 가입 화면에는 소셜 로그인이 없었습니다. 문서의 「이미 인증된 계정만」이라는 조건을 「가입도 소셜로 된다」로 넓혀 읽었다가 사람에게 없는 버튼을 찾게 했습니다.
- 가입이 막혔을 때 메일 주소를 바꾸자 막는 이유가 다른 것으로 바뀌었는데, 그 변화가 곧 처음 원인이 메일 주소 쪽이었다는 증거였습니다. 사람이 머리로 지은 비밀번호는 복잡해 보여도 유출 목록 대조에 걸리기 쉬워서 무작위 비밀번호로 통과했습니다.
- 계정 단위 토큰을 사용자 토큰 확인 주소로 재면 「잘못된 토큰」이 나옵니다. 계정 토큰은 계정 단위 확인 주소로 잽니다. 멀쩡한 토큰을 죽은 것으로 읽을 뻔했는데, 같은 토큰으로 존 조회가 성공해서 잡았습니다.
도구 메모
- DNS 조회 도구가 없을 때: HTTPS로 묻는 DNS 조회 API에 도메인과 레코드 종류를 넣는다
- 등록 정보: RDAP 조회. .org 같은 일반 도메인은 등록인이 가려져 나온다
- 방금 쓴 레코드: 그 도메인의 권위 네임서버를 먼저 찾고, 그 서버를 지정해 레코드를 묻는다
- 호스팅 운영사: 그 주소에 HTTPS로 붙어 인증서의 이름 목록을 본다