DNS 서버란 무엇인가?

도메인 이름을 입력할 때마다, 당신은 질문을 던지고 있습니다. "IP 주소가 뭐지?"라는 질문만이 아니라, "누가 이 답을 줄 권한이 있는 걸까?"라는 질문도 함께요.

두 번째 질문이 흥미로운 부분입니다. 누구든 google.com이 어디에 있는지 안다고 주장할 수 있습니다. DNS 시스템은 오직 권한 서버에서만 답을 받을 수 있도록 보장하기 위해 존재합니다.

권한의 계층 구조

DNS는 신뢰 체계를 기반으로 합니다. 최상단에는 루트 서버가 있습니다—모든 최상위 도메인(.com, .org, .app)에 대해 알고 있는 13개의 주소입니다. 그 아래에 TLD 서버는 자신의 접미사 아래 등록된 모든 도메인에 대해 알고 있습니다. 최하단에는 특정 도메인의 실제 IP 주소를 알고 있는 권한 서버가 있습니다.

connected.app을 요청하면, 컴퓨터는 모든 서버에 직접 물어보지 않습니다. 대신 재귀 리졸버에 물어봅니다—당신을 대신해 탐색을 해주는 서버(보통 ISP나 Cloudflare 같은 공개 제공업체가 운영)입니다.

리졸버는 맨 위에서 시작합니다. 루트 서버에게 묻습니다: "connected.app이 어디 있나요?"

루트 서버는 모릅니다. 다음에 누구에게 물어야 할지만 알고 있습니다. "저는 .app 도메인을 담당하지 않지만, 담당하는 곳이 여기입니다."

리졸버는 .app 서버에 묻습니다: "connected.app이 어디 있나요?"

.app 서버도 모릅니다. "저는 그 특정 도메인을 담당하지 않지만, connected.app의 권한 서버가 여기입니다."

마침내 리졸버는 그 권한 서버에 묻고, 최종 답을 받습니다: connected.app이 실제로 있는 IP 주소입니다.

이 과정은 밀리초 단위로 이루어집니다. 루트 서버는 google.com이 어디 있는지 모릅니다—다음에 누구에게 물어야 할지만 알고 있습니다. 이것은 한계가 아닙니다. 바로 이것이 핵심입니다. 어떤 단일 서버도 모든 것을 알 필요가 없습니다. 각 단계는 올바른 방향을 가리킬 수 있을 만큼만 알면 됩니다.

세 가지 서버, 세 가지 역할

재귀 리졸버는 당신을 위해 일합니다. 질문을 받아 계층 구조를 따라 추적하고, 답을 캐시하여 돌려줍니다. 8.8.8.8(Google)이나 1.1.1.1(Cloudflare)을 사용할 때, 당신은 어떤 리졸버가 이 작업을 대신할지 선택하는 것입니다.

권한 서버는 최종 정보 출처입니다. example.com을 소유하고 있다면, 당신의 권한 서버만이 example.com이 어디를 가리키는지 말할 수 있습니다. 이 서버들은 질문하지 않습니다—오직 답할 뿐입니다.

포워딩 서버는 중간자입니다. 가정용 라우터가 대개 이 역할을 합니다—기기에서 오는 DNS 요청을 받아 ISP의 리졸버로 전달합니다. 속도를 높이기 위해 결과를 캐시하지만, 계층적 조회는 직접 하지 않습니다.

이 인프라를 누가 운영하는가?

ISP는 기본 서비스의 일환으로 재귀 리졸버를 운영합니다. Comcast나 Verizon을 통해 연결하면, 라우터는 자동으로 그들의 DNS 서버를 사용하도록 설정됩니다. Cloudflare, Google, Quad9 같은 공개 제공업체는 대안을 제공합니다—대개 더 빠르고, 때로는 더 프라이버시 친화적입니다.

도메인 소유자는 권한 서버를 직접 운영하거나 Cloudflare나 AWS 같은 제공업체에 맡깁니다. Connected가 connected.app을 운영할 때, 우리는 우리 도메인에 대한 쿼리에 응답하는 서버를 책임집니다.

루트 서버는 흥미로운 사례입니다. 13개의 주소가 전체 인터넷을 서비스합니다—하지만 그 13개의 주소는 실제로 전 세계에 분산된 약 2,000대의 물리적 서버를 나타냅니다. 루트 서버에 쿼리하면, 애니캐스트 라우팅이 지리적으로 가장 가까운 서버로 요청을 보냅니다. 어떤 물리적 서버가 응답했는지는 알 수 없습니다.

이 인프라는 12개의 독립 기관이 운영합니다: Verisign(루트 서버 두 개를 운영), NASA, 미군, 대학들, ISC 등입니다. ICANN을 통해 조율하지만, 각 기관은 서버를 독립적으로 운영합니다. 루트를 통제하는 단일 기관은 없습니다.

장애를 견디도록 설계된 시스템

DNS는 장애를 전제로 설계되었습니다. 프로토콜은 모든 도메인에 최소 두 개의 권한 네임서버를 요구합니다. 루트 시스템은 13개의 주소 뒤에 약 2,000대의 서버를 운용합니다. 재귀 리졸버는 모든 것을 캐시하므로, 권한 서버가 일시적으로 오프라인 상태여도 계속 쿼리에 응답할 수 있습니다.

개별 DNS 서버는 끊임없이 장애가 발생합니다—유지보수, 공격, 중단—하지만 인터넷은 계속 작동합니다. 처음부터 장애를 가정하고 설계했기 때문에 단일 장애 지점이 없습니다.

이것이 DNS가 존재감 없이 작동하는 이유입니다. 아무 문제가 없어서가 아니라, 문제가 생기더라도 시스템이 우회하기 때문입니다.

DNS 서버에 대해 자주 묻는 질문

지금 내가 사용하는 DNS 서버는 무엇인가요?

기기는 아마 라우터가 자동으로 할당한 DNS 서버를 사용하고 있을 것입니다—대개 ISP의 리졸버입니다. 대부분의 시스템에서 네트워크 설정을 확인해 구성된 DNS 서버 주소를 볼 수 있습니다. nslookup 같은 도구나 온라인 DNS 누출 테스트를 통해 실제로 쿼리에 응답하는 리졸버가 무엇인지 확인할 수 있습니다.

1.1.1.1이나 8.8.8.8 같은 공개 DNS 제공업체로 바꿔야 할까요?

어떤 부분을 중요하게 생각하느냐에 따라 다릅니다. 공개 DNS 제공업체는 ISP 리졸버보다 빠른 응답 시간을 제공하는 경우가 많고, 일부(Cloudflare의 1.1.1.1 등)는 쿼리를 기록하지 않는 방식으로 개인 정보 보호를 강조합니다. 다른 것들(Quad9 등)은 알려진 악성 도메인을 차단합니다. 여기에는 절충점이 있습니다: ISP는 더 이상 DNS 쿼리를 볼 수 없지만, 선택한 제공업체는 볼 수 있습니다.

DNS 서버가 다운되면 어떻게 되나요?

설정된 DNS 서버에 장애가 생기면, 기기는 도메인 이름을 확인할 수 없습니다—웹사이트 자체는 멀쩡한데도 접속이 안 되는 것처럼 보입니다. 그래서 DNS 인프라는 강력한 이중화를 갖추고 있으며, 백업 DNS 서버를 설정해두면 여러분의 환경에서 단일 장애 지점을 방지할 수 있습니다.

DNS 변경 사항이 전파되는 데 시간이 걸리는 이유는 무엇인가요?

DNS 레코드를 업데이트하면, 이전 답이 전 세계 리졸버에 여전히 캐시되어 있습니다. 각 캐시된 레코드에는 TTL(Time To Live)이 있어 리졸버가 다시 확인하기 전까지 얼마나 오래 신뢰해야 하는지를 지정합니다. TTL이 만료되기 전까지, 일부 사용자는 이전 주소를 보고 다른 사용자는 새 주소를 봅니다. 이 "전파" 과정은 TTL 값에 따라 수 분에서 최대 48시간까지 지속될 수 있습니다.

참고 자료