DNS 레코드가 인터넷으로 전파되지 않는 이유는 무엇입니까?

네트워크에서 도메인의 네임 서버를 운영합니다. 우리는 bind / named를 사용합니다. 도메인 example.com을 호출 할 수 있습니다 . 최근에 알았던 한 가지는 http://network-tools.com 과 같은 웹 사이트로 이동 하여 네임 서버에 정의 된 URL에서 쿼리를 실행하면 변경 사항이 즉시 나타납니다.

예를 들어 url funny.example.com에 대한 DNS 서버에 항목을 추가 한 다음 http://network-tools.com 에서 해당 URL을 조회하면 적절한 외부 정적 IP가 즉시 표시됩니다.

example.com 과 관련된 모든 DNS 요청 이 매번 DNS 서버로 전송되고 있음을 알려줍니다 .

DNS 서버가 매우 짧은 기간 동안 다운 된 주 초에 내 의심이 확인되었습니다. 그리고 그 기간 동안 http://network-tools.com 을 사용 하여 example.com 또는 하위 도메인 을 쿼리 하면 결과가 전혀 없습니다. DNS 서버가 다운되어 연결할 수 없기 때문입니다.

그래서 이것은 내 질문에 나를 데려옵니다. DNS 서버의 변경 사항이 인터넷에서 다른 DNS 서버로 전파되어야한다고 생각했습니다. 이렇게하면 DNS가 일시적으로 다운 되더라도 인터넷의 다른 서버는 example.com이 가리키는 IP 주소를 여전히 알고 있습니다.

이 DNS를 오해하고 있습니까? 당사와 같은 타사 제어 DNS 서버는 DNS 정보를 인터넷상의 다른 서버로 전파 할 수 없습니까?

변경 사항이 적용되지 않는 이유는 어디에서 조사를 시작해야합니까? 방화벽에서 포트 53 트래픽이 DNS 서버로 올바르게 전달되고 있음을 알 수 있습니다.

최신 정보

1. DNS 설정을 즉시 게시하는 것이 불가능하다는 것을 알고 있지만 DNS 서버에서 DNS를 변경 한 다음 http : // network-tools 에서 즉시 확인하면됩니다 . com , 변경 사항이 즉시 표시됩니다.

2. DNS 서버를 끈 다음 http://network-tools.com을 사용하여 URL을 확인하려고 하면 사이트에서 URL을 찾을 수 없습니다. 그러나 DNS 서버를 다시 온라인으로 가져 오면 갑자기 http://network-tools.com 이 URL을 다시 찾을 수 있습니다. 이것은 서버가 DNS 설정을 캐싱하지 않는다는 것을 나타냅니다. 내가 잘못? 또한 TTL 설정은 현재 900 (15 분)으로 설정되어 있으며 DNS 서버는 1 년 이상 실행되었습니다. 따라서 인터넷에있는 DNS 서버와는 달리 아직 캐시 할 기회가 없었습니다. 현재 TTL이 너무 낮아서 서버가 설정을 캐시하지 않는 이유입니까? 그것이 그 이유라면 그 의미가 있습니다.

예, DNS 작동 방식을 이해하고 있지 않습니다. 나는 여기서 약간의 강조점을 사용할 것이지만, 의도 된 것이 없기 때문에 화 내지 마십시오.

DNS 레코드는 전파되지 않습니다. 그들은 캐싱되었습니다.

다음은 무슨 일이 일어나는지에 대한 간단한 설명입니다.

1. 새 DNS 레코드 (A, CNAME 등)를 만듭니다.

2. 원격 사용자 (특히 사용자가 시작한 프로세스 / 응용 프로그램)는 해당 DNS 레코드를 통해 액세스 한 서비스 (예 : funny.example.com에서 실행되는 웹 사이트에 액세스하려고하는 웹 브라우저)에 액세스하려고합니다.

3. 사용자 DNS 클라이언트는 DNS 쿼리를 DNS 서버로 보내면 DNS 서버는 이름 서버 (일반적으로 일련의 재귀 DNS 쿼리를 통해)를 찾아 funny.example.com에 관한 정보를 요청합니다.

4. 귀하의 네임 서버가 답변으로 답변합니다

5. 그런 다음 사용자 DNS 서버는이 정보를 사용자 (특히 사용자 DNS 클라이언트 확인자)에게 보내면 정보를 프로세스 \ 응용 프로그램에 반환합니다. 이 정보는 DNS 클라이언트 리졸버에게이 정보가 DNS 캐시 (메모리)에 얼마나 오래 보관 될 수 있는지와 정보가 최신의 정확한 것으로 간주 될 수있는 시간을 알려주는 TTL (Time To Live)이라는 정보와 함께 제공됩니다.

6. 그런 다음 사용자의 DNS 클라이언트 확인자는 TTL이 만료되면이 정보를 플러시합니다. 문제의 DNS 레코드에 대한 새로운 요청에는 새로운 DNS 조회가 필요하며 위의 과정이 반복됩니다.

그래서 길고 짧은 것은 이것입니다 :

DNS 레코드가 전파되지 않습니다. 다른 DNS 서버에는 DNS 레코드 또는 영역의 사본이 없습니다. DNS 클라이언트 또는 서버는 DNS 레코드 또는 영역에 대한 정보 (DNS 레코드 및 영역의 DNS 쿼리를 기반으로)를 DNS 캐시에 캐시 할 수 있습니다. 이 정보는 일시적으로 캐시되며 TTL이 만료되면 DNS 캐시에서 제거됩니다.

이름 서버가 다운되면 캐시에 DNS 레코드가있는 DNS 클라이언트 만 TTL이 만료 될 때까지 해당 DNS 레코드를 확인할 수 있습니다. 또한 TTL이 만료되면 (새 DNS lokkup이 필요함) 해당 DNS 클라이언트는 더 이상 DNS 레코드를 확인할 수 없습니다.

실제 도메인 이름을 말하면 실제 설정과 관련하여 질문에 답변하고 결함을 지적 할 수 있습니다.

DNS 문제를 빠르게 진단하기 위해 http://dns.squish.net/ 을 신뢰하는 경향이 있습니다. 변경을 한 후 문제가 어디에 있는지 확실하게 알 수 있습니다. 기본적으로 상류 대표단이 정확하고 2-3 명의 네임 서버가 모두 같은 대답을하고 누군가가 새로운 기록을 보지 못하는 경우, 로컬 네트워크가 변경 사항을 볼 때까지 기다려야합니다. 해당 검사기가 서버 중 하나가 다른 서버와 동일한 응답을 제공하지 않는다고 알리면 해당 문제를 해결해야합니다.

DNS 변경 사항을 즉시 게시 할 수있는 방법은 없습니다. 즉각 변경 사항을 즉시 게시 할 수는 있지만 각 레코드의 TTL 설정에 따라 나머지 지역은 뒤쳐 질 수 있습니다. 예를 들어 86400 초의 TTL 레코드를 설정 한 경우 ( 언젠가) 변경하면 다른 사람들은 레코드가 만료 될 때까지 로컬 캐시가 묻지 않기 때문에 하루 종일 오래된 레코드를 볼 수 있습니다.

주요 DNS 변경 전에 TTL을 600 (10 분)으로 줄여서 인터넷 캐시가 오래된 레코드를 오랫동안 보관하지 않도록 권장합니다. 그러나 일부 캐시는이를 무시하거나 1 일 또는 1 주일로 가정합니다.

으스스한 질문에 대한 으스스한 답변, 그래도 유용한 것이 있기를 바랍니다.

예. "DNS 변경 사항이 인터넷을 통해 전파 되려면 24-48 시간이 걸릴 수 있습니다."는 더 정확합니다. "DNS 변경 사항은 지난 86400 초 내에이 레코드를 쿼리 한 모든 DNS 서버에서 캐시 될 수 있습니다."

서버가 오프라인 상태 일 때 DNS 중복성을 보장하려면 dyndns.com과 같은 DNS 서비스 백업을 확인하거나 자체 보조 NS를 만들어야합니다.

인터넷상의 모든 DNS 서버는 "제 3 자 제어"입니다 (루트 DNS 서버가 인터넷에 "독점적"인 것으로 생각할 수 있지만 자신의 개인 루트를 넣을 수있는 기술적 이유는 없습니다).

DNS 서버는 각 답변에 제안 된 "TTL (Time to Live)"을 제공합니다. 원격 리졸버 (클라이언트 재귀 해상도를 수행하는 다른 DNS 서버는 클라이언트 확인자 라이브러리 등)이되어 가정 자신의 캐시를 폐기하기 전에 TTL까지에 대한 답을 캐시 할 수 있습니다.

기존 레코드에 대한 변경 사항이 실제 쿼리에 반영되지 않는 경우 TTL 값이 너무 높아 기존 응답이 해결 프로그램에서 오래 될 때까지 기다리지 않을 가능성이 높습니다. 인터넷을 캐시합니다.

서버 오류의 일부 배경 : DNS "전파"라고하는 이유는 무엇입니까?

인터넷에있는 누군가 (또는 일부 컴퓨터)가 컴퓨터 중 하나에 연결하기를 원하면 로컬 네임 서버에 관심있는 호스트 이름과 일치하는 IP 주소를 요청합니다.

따라서 누군가에게 "이봐, 멋진 웹 사이트 http://www.example.com "을 살펴보면 다른 사람의 컴퓨터가 로컬 이름 서버에 "hey, www.example.com의 IP 주소는 무엇입니까?"라고 묻습니다.

로컬 네임 서버가 이전에 해당 질문에 대한 답을 찾지 않았다고 가정하면 루트 네임 서버에 ".com"에 대한 조회를 처리하는 서버를 찾도록 요청합니다. 해당 답변을 받으면 서버에서 "example.com"에 대한 조회를 처리하는 서버를 요청합니다. 해당 답변을 받으면 해당 서버에 "www.example.com"의 IP 주소를 요청합니다.

example.com의 서버가 www.example.com의 IP 주소로 응답하면 요청하는 네임 서버에이 질문에 대한 답변을 기억해야하는 시간에 대한 힌트도 제공합니다. 이 힌트를 "TTL"또는 "Time to Live"라고하며 몇 초 단위로 측정됩니다. 서버가 TTL에주의를 기울일 것이라는 보장은 없습니다. 일부 네임 서버는 조회에 대한 응답을 기억하지 않도록 구성 될 수 있으며 초당 여러 번 요청하더라도 프로세스를 항상 반복합니다. 다른 네임 서버는 네트워크 트래픽을 최소화하기 위해 짧은 시간 동안 만 데이터를 보관하도록 제안한 경우에도 응답을 오랫동안 유지하도록 구성 될 수 있습니다. TTL은 요구 사항이나 보증이 아닌 제안 일뿐입니다.

DNS 레코드가 인터넷으로 전파되지 않는 이유에 대한 귀하의 질문에 대한 문자 적 ​​대답은 그들이하지 않아야하기 때문에 그렇게하지 않는 것입니다.

또한 DNS 정보를 연구하거나 디버깅하도록 설계된 사이트를 사용하여 자신의 DNS 정보를보고있는 경우 TTL 제안에 관계없이 사이트가 데이터를 오랫동안 또는 전혀 캐시하지 않을 가능성이 있습니다. 이 사이트의 목표는 아마도 5 초 또는 50 초 또는 500 초 전이 아닌 DNS 시스템에서 지금 말하는 내용에 대한 정보를 제공하는 것입니다. 그렇기 때문에 변경 사항이 즉시 반영되고 네임 서버 연결을 끊 자마자 서비스 작동이 중지되는 이유가 있습니다.

당신의 근본적인 질문은 "DNS 서버가 재부팅되거나 하드 디스크가 죽어도 인터넷상의 다른 사람들이 여전히 내 웹 페이지를 볼 수 있도록 어떻게 설정할 수 있습니까?"

이 질문에 대한 답은 도메인에 여러 네임 서버를 설정하고 서로 다른 컴퓨터에서 실행하는 것입니다. 이상적으로는 실제 컴퓨터뿐만 아니라 다른 도시, 주 또는 국가 또는 대륙에서도 네트워크 연결이 다른 것이 좋습니다. 이러한 네임 서버의 대부분은 "슬레이브"로 설정됩니다. 즉, "마스터"네임 서버에서 정보를 찾은 다음 해당 정보를 요청하는 사람에게 해당 정보를 반복합니다.

따라서 도메인 이름 등록 기관이있는 WHOIS 데이터에서 도메인에 대해 네 개의 네임 서버를 구성 할 수 있습니다.

ns1.example.com ns2.example.com ns1.otherguy.com ns2.otherguy.com

여기서 ns1.example.com은 현재 DNS 서버입니다. ns2.example.com은 회사 / 조직의 다른 컴퓨터 일 수 있습니다. 이상적으로는 ns1.example.com과 동일한 서브넷과 동일한 서버 랙 (또는 동일한 직원 데스크)에 있지 않아야합니다.

ns1.example.com은 "마스터"서버로 간주되며 DNS를 변경하려는 경우 해당 시스템에서 변경을 수행합니다.

ns2.example.com은 ns1.example.com에 설정 한 모든 데이터를 복사하는 "슬레이브"서버로 구성되지만 외부 세계는 마스터 / 슬레이브 구별 인 ns2.example에 신경 쓰지 않습니다. .com은 ns1.example.com과 같이 "공식"으로 간주됩니다.

ns1.otherguy.com과 ns2.otherguy.com은 다른 곳에 설치되어있는 컴퓨터입니다. 다른 조직의 친구 / 동료와 함께 서로 이름 서버를 운영하도록 준비하거나 dyndns.com으로 설정했을 수도 있습니다. 또는 everydns.net 또는 기타 무료 또는 상업용 DNS 제공 업체. 그러나 당신은 그 기계를 슬레이브로 구성하여 ns1.example.com (귀하의 "마스터")에서 example.com의 DNS 정보를 가져 와서 해당 DNS 정보를 그것을 요구하는 인터넷.

도메인 등록 기관에서 도메인에 대한 새로운 NS 레코드를 게시하면 (약간 즉각적이어야 함) 인터넷에있는 누군가가 "example.com"을 처리하는 도메인 이름 서버를 물으면 4 개의 답변을받습니다.

ns1.example.com, ns2.example.com, ns1.otherguy.com, ns2.otherguy.com

다른 사람의 네임 서버가 어떻게 설정되어 있는지에 따라,이 4 명을 목록으로 취급하고 "www.example.com"에 도달하는 방법을 한 번에 하나씩 요청할 수도 있습니다. 또는 4 명 모두에게 동일한 질문을 할 수도 있습니다. 동시에, 어떤 기계가 먼저 응답하는지에 대한 답을 얻으십시오. 어느 쪽이든, 하드 디스크가 죽었거나 재부팅을하기로 결정했거나 ns1.example.com이 다운 된 경우 다른 3 대의 컴퓨터가 대신 질문에 대답 할 수 있으며 웹 사이트는 계속 표시됩니다.

이 문제를 해결하는 가장 쉬운 방법은 도메인의 DNS를 처리 할 DNS 서비스 제공 업체에 가입하는 것입니다.이 가격은 월간 무료에서 수천 (아마도 수십 또는 수십만)에 달합니다. 원하는 서비스 수준. 연간 $ 30 정도의 합리적인 서비스를받을 수 있습니다. 무료 서비스는 끔찍하지 않기 때문에 꽤 좋은 벅 벅 비율을 가지지 만 돈을 벌기 위해 웹 사이트에 의존한다면 1 년 동안의 DNS 가격으로 30 달러를 지불 할 수 있어야합니다 .

그런 다음 DNS 서비스 제공 업체의 지침에 따라 도메인 이름 등록 기관에서 NS 레코드를 변경하면 모든 준비가 완료됩니다.

다른 DNS 서버에 의해 수행 된 캐싱은 레코드에 할당 된 TTL에 따라 다릅니다. 귀하의 경우 TTL이 매우 낮거나 높을 수 있습니다. DNS 구성에 대한 자세한 정보를 제공해 주시겠습니까?