도메인 소유 확인용 TXT 레코드 추가

구글 서치콘솔 접근 권한을 잃는 가장 흔한 경로는 해킹이 아닙니다. DNS 정리입니다.

마이그레이션을 끝낸 누군가가 존 파일에 남은 알 수 없는 google-site-verification=… 문자열을 보고 찌꺼기라 판단해 지웁니다. 몇 주 뒤 메일이 옵니다 — 서치콘솔이 더 이상 사이트를 확인할 수 없다는 내용입니다. 대시보드가 사라지고, 사이트맵 제출이 멈췄는데, 한 달 전 ‘정리’와 이 장애를 아무도 연결하지 못합니다. 인증 토큰은 나중에 버려도 되는 일회성 물건이라는 이 오해 하나를, 무언가를 손대기 전에 바로잡아야 합니다.

인증 TXT 레코드가 실제로 하는 일

어떤 서비스가 당신이 도메인을 통제한다는 증거를 요구할 때 — 구글 서치콘솔, 구글 워크스페이스, 마이크로소프트 365, 네이버 웹마스터도구 등 — 무작위 문자열을 주고 그걸 DNS TXT 레코드로 발행하라고 합니다. 논리는 단순하고 견고합니다. 도메인의 DNS에 접근할 수 있는 사람만 레코드를 추가할 수 있으니, 서비스의 비밀 문자열이 담긴 레코드가 곧 통제의 증거입니다. 파일 업로드도, 메타 태그도, 웹 호스트가 살아 있어야 하는 의존도 없습니다.

문자열은 서비스마다 다르고, 접두사가 누구 것인지 알려줍니다.

google-site-verification=rXhT8s...        (구글)
MS=ms12345678                             (마이크로소프트 365)
naver-site-verification=8a3f...           (네이버)

전부 그냥 TXT 레코드입니다. 특별한 마법은 없습니다.

레코드는 어디에 넣나

도메인 전체를 인증할 때 레코드 이름은 존의 루트입니다. DNS 호스트마다 ‘루트’를 적는 방식이 다릅니다 — 대개 @를 원하고, 어떤 곳은 칸을 비우라 하고, 일부는 도메인 그 자체를 넣으라 합니다. 공통점은 서브도메인이 아니라 정점(apex)을 가리킨다는 것입니다.

여기서 사람들이 오후 반나절을 날립니다. 많은 등록기관 패널이 이름 칸에 입력한 값 뒤에 도메인을 조용히 붙입니다. 그래서 이름 칸에 example.com이라고 치면 실제로 만들어진 레코드는 example.com.example.com — 검증기 입장에선 존재하지 않는 서브도메인입니다. 패널에선 멀쩡해 보이는데 모든 확인이 실패합니다. 해결은 @를 넣거나 이름을 비우고 패널이 도메인을 채우게 두는 것입니다.

일부 인증은 루트가 아니라 특정 호스트명을 요구합니다 — _someprefix.example.com 같은 전체 라벨을 줍니다. 그럴 땐 준 값을 정확히 붙여넣고 @를 덧붙이거나 잘라내려는 ‘친절’을 참으세요.

전파 대기는 실제이고, 양쪽으로 거짓말을 한다

DNS는 저장을 누르는 순간 갱신되지 않습니다. 새 레코드는 전파돼야 하고 — 이 부분이 사람들을 넘어뜨립니다 — 리졸버는 이미 그 이름의 부재를 캐시해 뒀을 수 있습니다. 이것이 네거티브 캐싱입니다. 레코드를 만들기 1분 전에 토큰을 조회한 리졸버는, 존의 네거티브 캐시 TTL이 지시하는 동안 — 흔히 한 시간, 때로는 더 길게 — ‘레코드 없음’을 계속 답할 수 있습니다.

그러니 레코드 저장 30초 뒤 실패한 인증은 알려주는 게 거의 없습니다. 기다리고, 외부 리졸버에서 레코드가 실제로 보이는지 확인한 뒤에 다시 시도하세요. 너무 일찍 확인하고 레코드가 틀렸다고 단정하면, 원래 맞았던 레코드를 ‘고치는’ 소용돌이에 빠집니다.

하나만 넣을 수 있는 게 아니다

한 도메인은 같은 이름에 여러 TXT 레코드를 가질 수 있고, 정상 설정이 실제로 그렇습니다. SPF 레코드, 구글 토큰, 마이크로소프트 토큰, 어떤 SaaS 도구의 도메인 인증 문자열이 전부 루트에 함께 살고, 리졸버는 그 전체를 반환합니다. 정상이고 문제없습니다.

실수는 이들을 하나의 필드로 취급하는 것입니다. TXT 레코드를 ‘깔끔하게’ 정리하려고 인증 토큰을 SPF 레코드 안에 붙여넣지 마세요. SPF는 고유 문법(v=spf1 …)이 있고, 토큰을 찾는 검증기는 SPF 문자열에서 그걸 파싱하지 못합니다 — 그러면서 SPF까지 깨질 위험이 있습니다. 토큰은 각각 독립된 TXT 레코드로 추가하세요.

길이 관련해 하나: 인증 토큰은 짧아서 대개 DNS TXT 문자열 하나의 255자 한도에 한참 못 미칩니다. 그래서 긴 DKIM 키를 괴롭히는 조각 분할 문제가 여기선 거의 없습니다. 만약 DNS 호스트가 TXT 레코드 길이를 문제 삼는다면 그건 다른 사안입니다 — TXT 레코드 255자 분할 가이드를 보세요.

검증기를 탓하기 전에 확인하라

• DNS 조회는 정확한 레코드 이름의 TXT를 조회해 공개 리졸버가 실제로 무엇을 반환하는지 보여줍니다 — example.com.example.com 이름 실수나 전파되지 않은 토큰을 가장 빨리 잡는 방법입니다.
• DNS 전파 확인은 여러 리졸버에서 동시에 레코드를 확인해, ‘아직 전파 안 됨’과 ‘진짜 틀림’을 구분해 줍니다.

요약

• 토큰을 서브도메인이 아니라 루트(@ 또는 빈 칸)의 TXT 레코드로 발행하세요 — 서비스가 명시적으로 호스트명을 준 경우는 예외.
• 등록기관이 이름 칸에 도메인을 붙이는지 살피세요.
• 전파를 기다리고 외부에서 레코드가 해석되는지 확인한 뒤 인증을 다시 시도하세요.
• SPF에 접지 말고 각각 독립된 TXT 레코드로 추가하세요.
• 서치콘솔 토큰은 계속 두세요 — 재확인되므로 지우면 인증이 풀립니다. 일회성 설정 토큰만 나중에 지워도 안전합니다.