Defaults.Exposed › 수정 › 네임서버 설정 (다양성 & SOA)

네임서버 설정 (다양성 & SOA) 수정 방법

네임서버는 전체 인터넷에 귀사 웹사이트와 이메일의 위치를 알려주는 디렉터리입니다. 모두 하나의 네트워크에 있고 그것이 다운되면 귀사 비즈니스는 동시에 인터넷에서 사라집니다 — 사이트도, 이메일도, 아무것도 없이. 그리고 그 서버의 시계 설정이 잘못되면 변경 사항이 며칠 동안 막혀 있을 수 있습니다.

비즈니스에 미치는 핵심 영향: 귀사 도메인의 모든 네임서버가 단일 네트워크에 있다면 그 네트워크의 장애 하나가 웹사이트와 이메일을 동시에 오프라인으로 만듭니다 — 직원과 광고 비용은 계속 나가지만 어떤 고객도 귀사에 접근할 수 없습니다. 또한 잘못된 SOA 타이머는 새 서버, 이메일 공급업체 변경, 긴급 리디렉션 같은 DNS 변경이 몇 시간이 아닌 며칠 동안 전파되게 합니다.

발생 가능한 비용

• 모든 네임서버가 있는 단일 네트워크가 장애나 DDoS 공격으로 장애를 겪으면 웹사이트와 이메일이 동시에 사라집니다. 고객은 오류 페이지를 받고 영업 메일함은 반송되며 웹 담당자는 다른 사람의 네트워크가 복구되기를 기다리는 것 외에 할 수 있는 일이 없습니다.
• 큰 고객사의 보안 팀이 공급업체 검토를 실행하여 모든 네임서버가 하나의 제공업체에 있고 이중화가 없다는 것을 보고 귀사 도메인을 단일 장애점으로 표시합니다 — 그렇지 않으면 수주했을 계약에서 마찰이 생깁니다.
• 새 웹 호스트로 이전하거나 이메일 공급업체를 변경하지만 SOA 레코드의 잘못된 '새로고침' 타이머 때문에 다른 DNS 서버가 며칠 동안 이전 주소를 제공합니다 — 일부 고객은 죽은 사이트에 도착하고 이메일이 두 곳으로 분산됩니다.
• 보안 사고로 긴급하게 트래픽을 리디렉션해야 하지만 SOA 타이머가 세상에 일주일 동안 이전 레코드를 캐시하라고 했기 때문에 한 시간 전에 한 변경이 문제가 계속되는 동안 인터넷의 절반에 아직 도달하지 못합니다.
• 두 개의 네임서버가 기술적으로는 두 개의 이름이지만 같은 네트워크의 같은 랙으로 해석됩니다 — 생각하는 이중화가 환상이며 단일 장애가 여전히 모든 것을 다운시킵니다.

중요한 이유. 귀사 웹사이트에 대한 모든 방문과 귀사에게 보내는 모든 이메일은 네임서버에 대한 조회로 시작됩니다. 그것은 귀사 온라인 존재의 나머지 모든 것이 기반으로 하는 기반입니다. 그 기반에 이중화가 없으면 단일 장애로 모든 것이 한 번에 다운됩니다; 타이밍 값이 잘못되면 모든 변경이 가장 여유 없는 시점에 느리게 적용됩니다.

쉬운 설명

누군가 귀사 웹사이트에 방문하거나 이메일을 보내기 전에 컴퓨터가 간단한 질문을 해야 합니다: “이 도메인이 실제로 어디에 있나요?” 그 질문에 답하는 서버가 네임서버입니다. 귀사 전체 온라인 존재에 대한 디렉터리 항목 — 모든 방문자와 모든 이메일이 귀사 사이트나 메일함이 관련되기 전에 처음 접촉하는 것.

이 페이지는 디렉터리를 올바르게 설정하는 두 가지 부분을 다룹니다:

1. 다양성 — 최소 두 개의 네임서버가 있고 단일 장애로 모두 한 번에 침묵시킬 수 없도록 네트워크의 진정으로 별도 부분에 있나요?
2. SOA 레코드 — 나머지 인터넷이 귀사 DNS 응답을 신뢰하고 캐시하는 시간을 제어하는 타이밍 값을 보유하는 작은 “권한 시작” 레코드. 타이머가 잘못되면 모든 변경이 세상에 도달하는 데 더 오래 걸립니다.

둘 다 화려하지 않습니다. 둘 다 기반입니다. 올바르면 생각할 필요가 없고; 잘못되면 최악의 순간에 알게 됩니다.

비즈니스 피해 사례

• 모든 것이 동시에 오프라인. 모든 네임서버가 하나의 네트워크에 있고 그 네트워크에 장애가 발생하거나 DDoS 공격을 받으면 웹사이트와 이메일이 함께 어두워집니다. 네트워크 전반의 이중화로 단일 장애는 생존 가능합니다; 없으면 완전합니다.

• 공급업체 확인에서 잃은 거래. 더 큰 고객사의 보안 또는 구매 팀이 서명 전에 확인을 실행하여 모든 네임서버가 한 공급업체에 집중되어 있는 것을 보고 귀사 도메인을 단일 장애점으로 표시합니다.

• 적용되지 않는 변경. 웹 호스트를 변경하거나 이메일 공급업체를 이전하거나 급하게 트래픽을 리디렉션해야 합니다. SOA 레코드의 잘못된 “새로고침” 또는 “만료” 타이머로 다른 DNS 서버가 며칠 동안 이전 답변을 제공합니다.

• 끝낼 수 없는 비상 사태. 보안 사고 중에 지금 당장 손상된 서버에서 트래픽을 이동해야 합니다. SOA 타이머가 일주일 동안 레코드를 캐시하라고 세상에 말했다면 수정이 문제가 계속되는 동안 인터넷 전체에 천천히 퍼집니다.

• 진짜가 아닌 이중화. 두 개의 네임서버가 있어 안전하다고 생각하지만 둘 다 같은 네트워크의 같은 랙으로 해석됩니다. 첫 번째 하드웨어 장애로 모두 다운되며 의지했던 안전망은 없었습니다.

실제 내용

네임서버 다양성. 귀사 도메인은 최소 두 개의 네임서버를 나열해야 하며 이상적으로는 단일 장애로 모두 다운되지 않도록 진정으로 독립적인 네트워크 경로에 있어야 합니다.

기술 독자를 위한 참고: 검사는 NS 레코드를 세고 그 뒤에 있는 진정한 네트워크 다양성을 살펴봅니다. 기본 신호는 네임서버가 해석되는 고유 IP 네트워크 블록의 분산(IPv4의 경우 대략 /16 범위, IPv6의 경우 /32)이며 고유 제공업체 이름 수가 지원합니다. 이것은 의도적으로 Anycast 하이퍼스케일 제공업체 — Cloudflare, Google, AWS Route 53, Azure DNS — 를 인정합니다. 네임서버가 두 개 미만이면 전체 도메인에 대한 미해결 단일 장애점이기 때문에 이 검사에서 0점을 받고 높은 심각도로 취급됩니다.

SOA 레코드. 모든 DNS 영역에는 정확히 하나의 권한 시작 레코드가 있습니다. 주요 네임서버와 관리 연락처를 명명하고 각 변경에서 증가하는 일련번호를 가지며 — 비즈니스에 중요한 부분 — 네 가지 타이머를 보유합니다:

• 새로고침 — 보조 네임서버가 변경을 위해 주 네임서버를 다시 확인하는 빈도. 좋은 범위: 대략 1~24시간(3,600~86,400초).
• 재시도 — 새로고침이 실패하면 다시 시도하는 시간. 좋은 범위: 대략 5~60분(300~3,600초).
• 만료 — 보조 네임서버가 주 네임서버에 전혀 연결할 수 없을 때 레코드를 계속 제공하는 기간. 좋은 범위: 대략 1~4주(604,800~2,419,200초).
• 최소 TTL — 응답(존재하지 않는 이름 응답 포함)이 캐시되는 하한. 합리적인 양의 값이어야 합니다; 300초가 일반적인 선택입니다.

좋은 상태는: 존재하고, 유효한 관리 연락처가 있고, 해당 범위 내 타이머를 보유하는 SOA.

수정 방법 (무료, 약 15분)

도메인이나 DNS를 관리하는 사람에게 이 섹션을 전달하세요 — 수정은 무료입니다.

1단계 — 최소 두 개의 네임서버가 다양한 인프라에 있는지 확인.

1. 현재 상태 확인. dig NS yourdomain.com 실행(또는 “DNS 조회” 웹 도구 사용)하고 네임서버를 읽습니다. 두 개 이상이 최소입니다.
2. 하나만 있거나 둘 다 단일 소규모 호스트에 있다면 기본적으로 이중화를 제공하는 공급업체로 DNS를 이전하세요:
   • Cloudflare — 도메인 추가 시 전 세계 Anycast 네트워크에 분산된 두 개의 네임서버를 자동으로 할당.
   • AWS Route 53 — 각 호스팅 영역은 별도 Route 53 네트워크의 네 개의 네임서버 획득.
   • Google Cloud DNS / Azure DNS — 마찬가지로 독립적인 인프라에 여러 네임서버 프로비저닝.
3. 전환을 위해 등록업체(도메인을 구입한 곳)에서 도메인 네임서버를 새 DNS 공급업체가 제공하는 것으로 설정합니다. 이 변경은 전체 전파에 24~48시간이 걸릴 수 있습니다.

2단계 — SOA 타이머 확인 및 필요시 수정.

1. dig SOA yourdomain.com 실행하고 새로고침, 재시도, 만료, 최소 TTL 값을 읽습니다.
2. 위의 범위와 비교합니다. 대부분의 경우 DNS 공급업체가 이미 합리적인 기본값을 설정했으므로 할 것이 없습니다.
3. 값이 범위를 벗어나면 DNS 호스팅 위치에서 수정합니다:
   • 관리형 공급업체(Cloudflare, Route 53, Google, Azure)에서 SOA는 대체로 자동으로 처리됩니다.
   • 자체 실행 네임서버(BIND, PowerDNS)에서 영역 파일의 SOA 줄을 직접 편집하고 영역을 재로드합니다.

흔한 실수

• “두 이름” = “두 네트워크”로 취급. 같은 박스나 랙으로 해석되는 두 개의 네임서버 이름은 변장한 단일 장애점입니다. 이름 수가 아닌 독립적인 네트워크 경로가 중요합니다.
• 다양성 없이 더 많은 것이 항상 더 낫다고 가정. 하나의 취약한 호스트에 있는 다섯 개의 네임서버는 하나보다 안전하지 않습니다.
• 너무 공격적으로 타이머 설정. SOA 새로고침이나 최소 TTL을 “변경을 즉각적으로” 하려고 낮추면 네임서버만 과부하되고 장애가 더 악화될 수 있습니다.
• expire를 너무 낮게 설정. 보조 서버가 너무 빨리 영역 제공을 중단하면 회복 가능한 결함이 완전한 장애가 됩니다. 만료는 주 범위로 유지하세요.
• 수동으로 영역 편집하고 일련번호 잊기. 자체 실행 네임서버에서 SOA 일련번호가 증가할 때만 보조 서버가 변경을 적용합니다.
• 도메인 등록업체의 기본 DNS에 남아 있기. 일부 등록업체의 내장 DNS는 단일 최소 설정입니다. 실제 공급업체로 이전하면 대개 한 번에 이중화와 합리적인 SOA 타이머가 제공됩니다.

요약

네임서버와 SOA 레코드는 다른 모든 것이 기반으로 하는 기반입니다. 진정으로 별도 네트워크의 두 네임서버는 단일 장애가 비즈니스 전체를 한 번에 오프라인으로 만들 수 없다는 것을 의미합니다; 합리적인 SOA 타이머는 변경이 실제로 즉시 세상에 도달한다는 것을 의미합니다. 둘 다 올바르게 하는 데 무료이며 대개 적절한 DNS 공급업체에 있으면 이미 좋은 상태입니다 — 2분 확인의 가치가 있습니다.

FAQ