☰

내 브라우저는 가장 가까운 DNS 루트 서버를 어떻게 찾나요?

tag-icon • tag-icon linux dns
내 브라우저는 가장 가까운 DNS 루트 서버를 어떻게 찾나요?

DNS 이름 확인에서 브라우저는 여러 DNS 서버 중에서 사용 가능한 가장 가까운 DNS 서버를 어떻게 결정합니까?

루트 서버가 13개 있다는 것을 알고 있지만 ISP의 DNS 서버는 연결할 루트 DNS 서버를 어떻게 알 수 있습니까?

답변1

귀하의 브라우저는 그렇지 않습니다. 귀하의 브라우저는 호스트 이름을 확인하기 위해 표준 시스템 호출을 사용하며(보통 내 생각에는 getaddrinfo()), 이는 일반적으로 /etc/resolv.conf구성된 확인 네임서버를 찾기 위해 의 내용을 검사하고 쿼리합니다. 그러면 데스크탑의 OS 쿼리를 업스트림 서버로 전달하거나(응답을 캐시함) 자체적으로 재귀적 해결을 수행합니다. 위 체인의 대부분의 단계는 구성 가능하므로 브라우저가 실제로 수행하는 작업은 로컬에서 결정됩니다. 그러나 위의 시나리오는 일반적입니다.

루트 서버를 찾는 방법을 알아야 하는 것은 해당 체인(로컬로 구성된 권한 있는 네임서버이든 일부 ISP의 서버이든)의 재귀 확인 네임서버이며 사전 구성된 영역 파일을 통해 이를 수행합니다. for .(일반적으로 사용 가능한 루트 네임서버를 쿼리하여 주기적으로 업데이트됩니다).

편집하다: 그렇지 않습니다. 구현에 따라 다르지만 제 경우에는 BIND가 적용되어 하나만 선택하고 쿼리합니다. 제 시간에 응답을 얻는 한 거기에서 다시 발생합니다. 어떤 종류의 거리 측정 작업이 진행되고 있다고 생각하는 이유는 무엇입니까?

답변2

DNS 이름 확인에서 브라우저는 여러 DNS 서버 중에서 사용 가능한 가장 가까운 DNS 서버를 어떻게 결정합니까?

다른 답변에서 알 수 있듯이 귀하의 브라우저나 다른 클라이언트 프로그램은 이 선택을 수행하지 않습니다. 클라이언트 프로그램은 확인자라는 라이브러리를 호출하여 이름 서비스 확인을 요청합니다.

확인자는 쿼리를 요청하기 위해 접속해야 하는 서버를 결정합니다. 리졸버 구현에 따라 다르지만대개(정적 구성 또는 DHCP와 같은 메커니즘을 통해 수신하여) 구성된 재귀 확인자 목록을 순서대로 참조합니다.

요약하자면, (사용자 수준) 프로그램은 확인자에게 이름 확인을 요청하고 확인자는 일부 구성 메커니즘을 통해 제공된 네임서버에 요청합니다.

루트 서버가 13개 있다는 것을 알고 있지만 ISP의 DNS 서버는 연결할 루트 DNS 서버를 어떻게 알 수 있습니까?

이것은 또한 구현에 따라 다릅니다. BIND와 어떻게 작동하는지 설명하겠습니다.

  1. BIND는 매우 인기 있는 네임서버이며 귀하의 ISP가 이를 사용할 가능성이 상당히 높습니다.
  2. ISP가 BIND를 사용하지 않더라도 일부 대안은 NS 리소스 레코드 세트에서 이름 서버를 선택하기 위해 유사한 메커니즘을 사용합니다.

우선, 순환 네임서버가 특정 도메인과 통신하기 위해 어떤 네임서버를 선택해야 하는지 어떻게 아는지 먼저 살펴보겠습니다. 네임서버의 루트(".") 수준에서 연결할 수 있는 각 도메인에 대해 해당 도메인을 관리하는 관리자는 포함된 상위 도메인에 레코드 유형 NS(예: 네임서버)의 리소스 레코드 세트를 게시하여 네임서버에 공개적으로 위임합니다. 리소스 레코드 세트에 이름이 지정된 사람은 해당 도메인과 관련된 쿼리를 해결하는 책임을 집니다.

이 시스템의 장점 중 하나는 도메인 이름 시스템과 재귀 서버가 요구하는 유일한 도메인에 대한 분산 계층적 위임을 허용한다는 것입니다.선험적으로지식은 서버가 알도록 구성된 루트 수준입니다. BIND가 시작될 때 로드되는 "힌트" 파일을 통해 루트에 대한 NS RRset을 지정하는 것이 가장 일반적이었지만 지금은 한동안 루트 서버에서 사용하는 IP 주소가 BIND에 미리 정의되어 있습니다. [여담: 루트 힌트 영역을 지정하여 내장 기능을 무시할 수 있으며 실제로 d.root-servers.net의 주소는 최근에 변경되었으며 새 위치는 새로 생성될 때까지 내장 목록에 반영되지 않습니다. 새로운 정보를 포함하는 BIND 버전이 구축되어 배포됩니다. 현재 D 루트 서버의 새로운 IP 주소를 포함하는 버전은 베타 버전입니다.]

어쨌든 여기서 중요한 점은 각 도메인이 해당 도메인에 대해 공개적으로 발표된 네임서버를 포함하는 NS 레코드 RRset과 연결되어 있다는 것입니다. 몇 가지를 직접 살펴보아야 합니다. 루트를 살펴보겠습니다.

$ dig . ns +edns=0 @f.root-servers.net.

나는 예측할 수 없는 순서로 반환된 NS RRset를 포함하는 답변 섹션을 잘라낼 것입니다. . 다른 루트는 다른 순서로 응답할 수 있지만 주문되는 항목은 동일해야 합니다.)

    ;; ANSWER SECTION:
    .           518400  IN  NS  h.root-servers.net.
    .           518400  IN  NS  j.root-servers.net.
    .           518400  IN  NS  c.root-servers.net.
    .           518400  IN  NS  l.root-servers.net.
    .           518400  IN  NS  e.root-servers.net.
    .           518400  IN  NS  a.root-servers.net.
    .           518400  IN  NS  f.root-servers.net.
    .           518400  IN  NS  k.root-servers.net.
    .           518400  IN  NS  i.root-servers.net.
    .           518400  IN  NS  d.root-servers.net.
    .           518400  IN  NS  m.root-servers.net.
    .           518400  IN  NS  b.root-servers.net.
    .           518400  IN  NS  g.root-servers.net.

이것들은 모두 루트(".") 도메인에 대한 네임서버이며 루트 도메인에 대해 질문할 수 있습니다. 루트 도메인에 없는 것에 대해 질문하면 오류가 발생하거나 다른 이름 서버 세트(예: "example.com? example.com에 대한 질문에는 대답하지 않습니다. .com 도메인 네임서버에 물어보세요. 거기 있습니다..")

그렇다면 BIND는 NS RRset의 어떤 네임서버가 가장 빠른 응답을 제공하는지 어떻게 알 수 있습니까?

대답은 다음과 같습니다. 처음에는 그렇지 않습니다. 그러나 기본 동작에서는 시간이 지남에 따라 학습하고 정착합니다.대개왕복 시간이 가장 짧은 서버에 요청합니다.

왕복 시간 및 후보 네임서버 선택 BIND는 쿼리를 수신해야 하는 네임서버를 선택하기 위해 RRset의 네임서버에 대한 왕복 시간(RTT)을 사용합니다. 도메인에 대한 NS RRset가 캐시에 처음 추가되면 해당 세트의 모든 레코드에 몇 밀리초 정도의 작은 무작위 왕복 시간이 할당됩니다. 초기 프라이밍 이후 특정 도메인에 위임된 네임서버로 쿼리를 보내야 할 때 BIND는 캐시를 확인하고 (희망적으로) RRset를 찾습니다. 세트에서 RTT 시간이 가장 낮은 서버를 선택하고 쿼리를 수행합니다. 쿼리가 완료되면 BIND는 NS RRset에 대한 RTT를 다음과 같이 업데이트합니다.

  1. 방금 쿼리된 서버의 RTT는 실제 왕복 시간으로 설정됩니다.
  2. RRset의 다른 모든 서버는 RTT가 약간(~3-4% 정도인 것 같아요..) 감소했습니다.

예제를 통해 이것이 어떻게 작동하는지 살펴보겠습니다. 내 재귀 확인자가 도메인 example.com을 처음 발견하면 example.com에 대한 NS RRset을 캐시에 로드합니다. example.com의 관리자가 example.com에 대한 세 개의 이름 서버를 발표했기 때문에 NS RRset은 다음과 같습니다.

example.com    NS    servera.example.com
example.com    NS    serverb.example.com
example.com    NS    serverc.example.com

또한 이 예에서는 확인자가 이 집합의 각 서버로부터 응답을 받는 데 다음과 같은 시간이 걸린다고 가정해 보겠습니다.

servera  --  30 ms
serverb  --  45 ms
serverc  --  50 ms

이제 example.com NS RRset이 처음 로드되면 RTT 가중치가 작은 임의 값으로 프라이밍됩니다. 따라서 example.com 네임서버에 무엇이든 요청하기 전에 RTT 테이블은 다음과 같을 것입니다.

servera  --  8 ms
serverb  --  9 ms
serverc  --  7 ms

example.com을 처음 쿼리하면 serverc로 이동하여 질문을 하게 됩니다. Serverc가 응답하는 데 50ms가 걸리므로 쿼리가 완료된 후 RTT 테이블을 업데이트하여 이제 다음과 같이 읽습니다.

servera  --  7 ms    //  reduced by a small fraction
serverb  --  8 ms    //  reduced by a small fraction
serverc  --  50 ms   //  updated to reflect the actual round trip time.

다음 번에는 왕복 시간이 가장 낮은 servera를 선택할 것입니다. example.com 도메인에 대해 몇 번의 쿼리만 하면 어떤 네임서버가 가장 빠른 응답을 제공하는지 꽤 괜찮은 아이디어를 얻을 수 있으며 그 이후에는 해당 서버를 선호할 것입니다.최대그 시간의.

왜최대당시의 것과 그렇지 않은 것모두그 시간의? 그리고 앞서 "RRset의 다른 모든 서버는 RTT가 약간 감소했습니다"라고 언급한 부분은 어떻게 되나요? 글쎄, 우리가 원하는 동안선호하다가장 빠른 서버이기 때문에 다른 서버를 영구적으로 삭제하고 싶지 않습니다. 서버 c는 거의 항상 가장 빠른 서버일 수 있지만 처음 RTT를 설정했을 때는 비정상적으로 바빴습니다. 서버가 일시적으로 서비스가 중단되어 RTT가 엄청나게 높아졌을 수도 있지만(쿼리 시도 시간이 초과된 후) 서비스가 다시 시작된 후 다시 요청하기를 원합니다. 매번 다른 서버 값을 하향 조정하면 조만간 우리가 선호하는 서버의 평균 RTT보다 낮아질 것입니다. 그런 일이 발생하면 우리는 그 방향으로 쿼리를 던질 것이고, 시간이 더 좋으면 좋을 것입니다. 그렇지 않으면 RTT를 재설정하고 다시 앞으로 나올 때까지 우선순위 목록의 맨 아래로 돌아갑니다. 대부분의 쿼리는 세트에서 가장 빠른 서버로 이동하지만 조건이 변경된 경우 테이블이 이를 반영하도록 업데이트되고 최상의 서버가 여전히 평균적으로 선택되는지 확인하기 위해 이상값이 주기적으로 시도됩니다.

답변3

13개의 루트 네임서버는 실제로 13개의 서버가 아닙니다. 각 서버는 전 세계 다양한 사이트에 분산된 서버 클러스터이며 다른 서버와 마찬가지로 표준 IP 라우팅을 통해 액세스됩니다.

에 관해서는어느ISP의 DNS 서버가 연결하기로 선택한 루트 이름 서버는 아마도 DNS 확인자의 세부 정보에 따라 달라질 수 있습니다. 어쩌면 완전히 무작위일 수도 있고, 가중치가 있을 수도 있지만 말씀드릴 수는 없습니다.

편집: 당신이 말한 것이라면, ISP는 어떻게 됩니까?찾다13개의 네임서버 중 하나에 해당 네임서버의 공개 목록과 기본적으로 모든 컴퓨터가 갖고 있는 해당 IP 주소가 있습니다. 여기서는 하나를 선택하고 나머지는 인터넷 라우터에 맡기기만 하면 됩니다.

관련 정보