ERR_ICANN_NAME_COLLISION: Chrome 해결

문제

Chrome이 페이지를 ERR_ICANN_NAME_COLLISION — “사이트에 연결할 수 없음” — 으로 로드하지 못합니다. 타임아웃도, 인증서 경고도, 서버 오류도 없습니다. 당신이 입력한 이름은 해석에 실패한 게 아니라, 일부러 엉뚱한 것으로 해석됐고 Chrome이 그걸 잡아낸 겁니다.

증상

• Chrome이 ERR_ICANN_NAME_COLLISION을 표시하고 페이지가 열리지 않습니다.
• 짧은 내부 이름, 개발용 호스트명, 또는 .corp·.home·.mail·.dev 같은 지어낸 TLD 아래 이름에서 발생합니다 — 웹 전반이 아니라.
• 같은 이름이 수년간 잘 되다가 최근에야 깨졌을 수 있습니다.
• 그 이름에 대한 ping·nslookup이 127.0.53.53 주소를 보여 줍니다.
• 새 네트워크에 접속했거나, DNS 서버를 바꿨거나, 내부에서 쓰던 TLD가 진짜 공개 도메인 확장자가 된 직후 시작된 경우가 많습니다.

이 오류의 진짜 의미

사설 네트워크 안에서만 사는 이름의 부류가 있습니다: 인트라넷을 http://wiki/로 부르는 회사, 모든 걸 .corp 아래 두는 설정, printer라고 치면 실제로는 printer.office.example을 뜻하도록 DNS 검색 도메인이 설정된 노트북. 이런 이름은 공개 DNS에 없었으므로 네트워크 바깥의 누구도 답할 수 없었고, 그건 문제없었습니다 — 공개 DNS가 그와 일치하는 이름을 갖기 전까지는.

ICANN의 새 gTLD 프로그램은 수백 개의 최상위 도메인을 추가했습니다. 하나를 위임할 때마다, 그 문자열이 누군가 이미 사설로 쓰던 이름과 충돌할 위험이 있습니다. 당신 네트워크가 something.dev를 내부적으로 해석하는데 .dev가 진짜 위임된 공개 TLD가 되면(실제로 그렇습니다 — Google이 운영하고 HSTS 프리로드돼 있습니다), 당신의 질의가 갑자기 공개 DNS에 닿아, 안에 두려던 이름에 대해 진짜 답이나 엉뚱한 답을 받을 수 있습니다.

그 일이 조용히 일어나지 않도록, 2014년 승인된 ICANN의 Name Collision Occurrence Management Framework는 새로 위임된 TLD 운영자가 새 존 전체를 90일 동안 단일 주소 — 127.0.53.53 — 로 가리키게 요구합니다. 이 controlled interruption(제어된 중단) 기간의 주소는 일부러 놓은 덫입니다. 127.x.x.x는 루프백이라 이를 따라간 브라우저는 자기 자신과 대화할 뿐 아무 일도 안 일어나고, 53.53은 DNS(포트 53)를 연상시키는 니모닉이라 로그에서 눈에 띕니다. 조용하고 위험한 오유도(misdirection)를 요란하고 명백한 실패로 바꾸는 게 핵심입니다. Chrome은 한 걸음 더 나아가, 127.0.53.53을 충돌 신호로 인식해서 무의미하게 자기 기기에 연결하는 대신 멈추고 ERR_ICANN_NAME_COLLISION을 보여 줍니다.

그러니 이 오류는 웹사이트가 말하는 게 아닙니다. 당신이 쓴 이름이 있어선 안 될 곳을 가리킨다고, 당신 자신의 해석 경로가 알리는 겁니다.

가장 흔한 원인 3가지

1. 공개 DNS와 충돌하는 내부 전용 TLD - 누군가 네트워크를 지어낸 최상위 도메인 중심으로 구축한 경우: .corp·.home·.mail·.lan, 느슨하게 쓴 .dev·.local 등. ICANN 보안위원회는 .corp·.home·.mail을 충돌 고위험으로 지목해 결코 위임하지 않았습니다 — 하지만 다른 많은 문자열은 진짜 gTLD로 위임됐습니다. 공개 루트가 그 문자열에 답하는 순간, 당신의 질의는 인트라넷을 탈출해 controlled interruption 존에 닿을 수 있습니다. 지문: 특정 TLD 하나 아래 모든 게 한꺼번에 깨짐.
2. 검색 도메인이 짧고 미완성된 이름을 확장 - intranet이나 wpad 같은 맨 호스트를 입력한 경우. 리졸버에 검색 목록이 있어 접미사를 붙이고, 이제 위임된 TLD나 controlled-interruption 존과 충돌하는 완전 수식 이름으로 바꿉니다. 지문: 새 네트워크 접속이나 DNS 서버 변경 후 깨짐, 짧은 이름만 영향받고 완전 수식 이름은 정상.
3. 공개 위임 후의 낡은 내부 이름 - 수년간 내부 서버로 해석되던 이름이 127.0.53.53을 반환하기 시작 — 일치하는 TLD가 공개 루트로 승격해 90일 중단 기간에 들어갔기 때문입니다. 당신 쪽은 아무것도 안 바뀌었고, 글로벌 네임스페이스가 바뀐 겁니다. 지문: 로컬 변경 없이 “그냥 멈춤”, 새 TLD가 개통된 무렵과 겹침.

DechoNet으로 진단하기

• DNS 조회는 정확한 완전 수식 이름을 네트워크 바깥에서 해석해 공개 DNS가 실제로 무엇을 반환하는지 보여 줍니다. 공개 답이 127.0.53.53이면 controlled-interruption 존에 닿은 것 — 그 TLD는 이제 진짜 공개이고, 해법은 그 이름에서 벗어나는 것입니다. 공개 DNS가 정상 레코드를 반환하면(또는 그 이름이 진짜 공개 사이트면), 당신 로컬 기기가 127.0.53.53을 보는 건 당신 쪽 무언가 — 검색 도메인·hosts 항목·내부 리졸버 — 가 충돌을 주입하는 것입니다. 공개 DNS가 그 문자열에 아무것도 반환하지 않으면, 그 이름은 오직 당신 네트워크에만 존재했고 검색 접미사가 충돌 이름으로 바꾸는 것입니다.
• HTTP 진단은 완전 수식 이름을 아예 바깥에서 가져옵니다. Chrome은 충돌을 보이는데 외부 결과가 깨끗하면 문제는 목적지가 아니라 당신의 로컬 해석임을 확인해 줍니다.

해결 체크리스트

• 먼저 주소를 확인하세요. nslookup <이름>(또는 ping <이름>)을 돌려 127.0.53.53을 반환하는지 보세요. 그렇다면 이건 서버 장애가 아니라 이름 충돌입니다, 이상 끝.
• 어떤 이름이 충돌하는지 특정하세요. 방아쇠가 되는 TLD나 짧은 호스트를 적고, 완전 수식 이름은 되는데 맨 이름은 안 되는지(검색 도메인을 가리킴) 확인하세요.
• 네트워크를 소유하고 지어낸 내부 TLD를 쓴다면 거기서 벗어나세요. 내부 이름을 당신이 통제하는 도메인의 실제 서브도메인(svc.internal.example.com) 아래 두거나, 홈 네트워크라면 .home.arpa 아래 두세요. 새 TLD를 지어내지 마세요 — 다음 위임 라운드가 또 충돌할 수 있습니다.
• 충돌 상대가 진짜 공개된 TLD라면(.dev·.app 등은 진짜입니다) 그 이름을 유지할 수 없으니 내부 서비스를 개명하세요. 글로벌 루트와 싸우는 건 선택지가 아닙니다.
• 리졸버가 검색 접미사를 붙이지 못하도록 이름을 완전 수식하고(끝에 점 또는 전체 도메인), 필요 없는 검색 도메인은 제거하세요.
• 변경 후 캐시를 비우세요: chrome://net-internals/#dns(Clear host cache)와 OS 리졸버 캐시. 127.0.53.53 답은 TTL 만료 전까지 남을 수 있습니다.

에스컬레이션 시점

• 조직 전체가 이제 충돌하는 내부 TLD를 쓴다면, 이건 브라우저 수정이 아니라 네트워크·네이밍 프로젝트입니다 — DNS 담당에게 넘기세요. 내부 이름을 당신이 통제하는 위임 도메인으로 재배치해야 하고, 이는 DHCP 검색 목록·인증서·하드코딩된 모든 짧은 이름을 건드립니다.
• 내부 서비스에 닿던 이름이 당신 쪽 변경 없이 이제 127.0.53.53을 반환하면, 일치하는 TLD가 최근 위임돼 controlled-interruption 기간인지 DNS 팀에 확인하세요; 유일한 항구적 해법은 충돌 문자열에서 서비스를 개명하는 것입니다.
• 짧은 이름이 특정 네트워크(사무실 vs 집 vs VPN)에서만 충돌하면, 차이는 각 네트워크가 밀어 넣는 DNS 검색 도메인입니다 — 그 DHCP·리졸버 설정을 관리하는 쪽에 넘기세요.