실제로, "도메인 (www.mysite.com)을 DNS 서버에 매핑하는 테이블을 보유하고있는 하나의 중앙 레지스트리"보다는 여러 계층의 계층이 있습니다.
- 모든 최상위 도메인에 대한 NS (이름 서버) 레코드 : 중앙 레지스트리 항목의 작은 집합을 포함 (루트 서버)있다 .com, .net, .org, .uk, .us, .au, 등이.
이러한 서버에는 다음 레벨 다운을위한 NS 레코드 만 포함됩니다. 하나의 예를 선택하려면에 대한 네임 서버 .uk도메인은 단지에 대한 항목이 .co.uk, .ac.uk그리고 영국에서 사용되는 다른 두 번째 수준의 영역을.
이러한 서버에는 다음 레벨 다운에 대한 NS 레코드 만 포함되어 있습니다. 예제를 계속하려면에서 NS 레코드를 찾을 수있는 위치를 알려줍니다 google.co.uk. 이러한 서버에서 호스트 이름과 www.google.co.ukIP 주소 사이의 매핑을 마침내 찾을 수 있습니다.
추가 주름으로 각 레이어는 '접착제'레코드를 제공합니다. 각 NS 레코드는 도메인을 호스트 이름 (예 : 서버 중 하나로 NS 레코드 .uk목록)에 매핑 nsa.nic.uk합니다. 다음 단계로 가려면 NS 레코드에 대한 NS 레코드를 찾아야하며, 그 레코드도 nic.uk포함 nsa.nic.uk됩니다. 이제 우리는의 IP를 알아야 nsa.nic.uk하지만, 우리는에 대한 쿼리를해야 nsa.nic.uk한다는 것을 알지만 IP를 알 때까지는 쿼리를 만들 수 없습니다 nsa.nic.uk...
이 당혹를 해결하려면 서버에 대한 .uk에 대한 A 레코드를 추가 nsa.nic.uk에 ADDITIONAL SECTION응답 (짧음에 대한 손질 아래 응답)의 :
jamezpolley@li101-70:~$dig nic.uk ns
; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;nic.uk. IN NS
;; ANSWER SECTION:
nic.uk. 172800 IN NS nsb.nic.uk.
nic.uk. 172800 IN NS nsa.nic.uk.
;; ADDITIONAL SECTION:
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
이러한 추가 글루 레코드가 없으면 네임 서버를 찾을 수 nic.uk.없으므로 호스트 된 도메인을 찾을 수 없습니다.
질문으로 돌아가려면 ...
a) 장점은 무엇입니까? 왜 IP 주소에 직접 매핑하지 않습니까?
우선 각 개별 영역에 대한 편집 내용을 배포 할 수 있습니다. 의 항목을 업데이트하려면 의 네임 서버 www.mydomain.co.uk에서 정보를 편집하면 mydomain.co.uk됩니다. 중앙 .co.uk서버, .uk서버 또는 루트 이름 서버 에 알릴 필요가 없습니다 . 체인에 이르기까지 DNS 항목의 모든 단일 변경에 대해 통지해야하는 계층 구조까지 모든 레벨을 맵핑하는 단일 중앙 레지스트리 만있는 경우에는 트래픽이 절대적으로 발생합니다.
1982 년 이전에는 실제로 이름 확인이 이루어졌습니다. 하나의 중앙 레지스트리에 모든 업데이트에 대한 알림이 전송되었으며 hosts.txt인터넷에있는 모든 컴퓨터의 호스트 이름과 IP 주소가 포함 된 파일을 배포했습니다 . 이 파일의 새 버전은 몇 주마다 게시되었으며 인터넷상의 모든 컴퓨터는 새 복사본을 다운로드해야합니다. 1982 년 이전에는 이것이 문제가 되었기 때문에 DNS는보다 분산 된 시스템을 제공하기 위해 발명되었습니다.
다른 하나의 경우, 이는 단일 실패 지점입니다. 단일 중앙 레지스트리가 다운되면 전체 인터넷이 오프라인 상태가됩니다. 분산 시스템이 있다는 것은 장애가 전체가 아니라 인터넷의 작은 부분에만 영향을 미친다는 것을 의미합니다.
여분의 중복성을 제공하기 위해 실제로 루트 영역에 서비스를 제공하는 별도의 서버 클러스터가 13 개 있습니다. 최상위 도메인 레코드에 대한 변경 사항은 모두 13 개로 푸시해야합니다. 전 세계 어디에서나 모든 호스트 이름으로 ...)
b) 다른 IP 주소를 가리 키도록 DNS 서버를 구성 할 때 변경해야하는 유일한 레코드가 DNS 서버에있는 경우 프로세스가 즉각적이지 않은 이유는 무엇입니까?
DNS는 많은 캐싱을 사용하여 작업 속도를 높이고 NS의 부하를 줄입니다. 캐싱하지 않고, 매번 당신은 방문 google.co.uk컴퓨터가 서버를 조회하기 위해 네트워크에 나가서해야 .uk다음, .co.uk다음 .google.co.uk, 다음 www.google.co.uk. 이러한 답변은 실제로 크게 변경되지 않으므로 매번 조회하면 시간과 네트워크 트래픽이 낭비됩니다. 대신 NS가 레코드를 컴퓨터에 반환 할 때 컴퓨터에 결과를 몇 초 동안 캐시하도록 지시하는 TTL 값이 포함됩니다.
예를 들어 NS 레코드 .uk의 TTL은 172800 초-2 일입니다. Google은 훨씬 보수적입니다. NS 레코드 google.co.uk의 TTL은 4 일입니다. 신속하게 업데이트 할 수있는 서비스는 훨씬 낮은 TTL을 선택할 수 있습니다. 예를 들어 telegraph.co.ukNS 레코드에서 TTL이 600 초에 불과합니다.
영역에 대한 업데이트가 거의 즉각적으로 이루어 지도록하려면 원하는만큼 TTL을 낮추도록 선택할 수 있습니다. 클라이언트가 레코드를 더 자주 새로 고치면 설정이 낮을수록 서버에서 더 많은 트래픽을 볼 수 있습니다. 클라이언트가 서버에 접속하여 쿼리를 수행해야 할 때마다 로컬 캐시에서 응답을 찾는 것보다 속도가 느려지므로 빠른 업데이트와 빠른 서비스 간의 균형을 고려해야합니다.
c) 지연에 대한 유일한 이유가 DNS 캐시 인 경우이를 우회 할 수 있습니까? 실시간으로 어떤 일이 일어나고 있는지 알 수 있습니까?
예. 수동으로 dig또는 유사한 도구를 사용 하여 수동으로 테스트하는 경우 간단합니다 . 어떤 서버에 접속해야하는지 알려주십시오.
캐시 된 응답의 예는 다음과 같습니다.
jamezpolley@host:~$dig telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 319 IN NS ns1-63.akam.net.
telegraph.co.uk. 319 IN NS eur3.akam.net.
telegraph.co.uk. 319 IN NS use2.akam.net.
telegraph.co.uk. 319 IN NS usw2.akam.net.
telegraph.co.uk. 319 IN NS use4.akam.net.
telegraph.co.uk. 319 IN NS use1.akam.net.
telegraph.co.uk. 319 IN NS usc4.akam.net.
telegraph.co.uk. 319 IN NS ns1-224.akam.net.
;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb 2 05:46:02 2012
;; MSG SIZE rcvd: 198
여기에있는 flags 섹션에는 aa플래그 가 포함되어 있지 않으므로이 결과는 신뢰할 수있는 소스가 아닌 캐시에서 나온 것입니다. 실제로 우리는 97.107.133.4Linode의 로컬 DNS 확인자 중 하나 인 에서 온 것을 알 수 있습니다 . 대답이 나와 매우 가까운 캐시에서 제공되었다는 사실은 대답을 얻는 데 0msec가 걸린다는 것을 의미합니다. 그러나 우리가 잠시 후에 볼 수 있듯이, 그 속도에 대해 지불하는 가격은 대답이 거의 5 분이 지났다는 것입니다.
Linode의 리졸버를 우회하고 소스로 바로 이동하려면 해당 NS 중 하나를 선택하고 직접 연락하도록 발굴하십시오.
jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 600 IN NS use2.akam.net.
telegraph.co.uk. 600 IN NS eur3.akam.net.
telegraph.co.uk. 600 IN NS use1.akam.net.
telegraph.co.uk. 600 IN NS ns1-63.akam.net.
telegraph.co.uk. 600 IN NS usc4.akam.net.
telegraph.co.uk. 600 IN NS ns1-224.akam.net.
telegraph.co.uk. 600 IN NS usw2.akam.net.
telegraph.co.uk. 600 IN NS use4.akam.net.
;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb 2 05:48:47 2012
;; MSG SIZE rcvd: 198
이번에는 소스에서 직접 결과가 제공 aa되었음을 알 수 있습니다. 결과는 신뢰할 수있는 소스에서 온 것임을 나타내는 플래그에 유의하십시오 . 이전 예제에서 결과는 로컬 캐시에서 왔으므로 aa플래그가 없습니다. 이 도메인의 신뢰할 수있는 소스가 TTL을 600 초로 설정 한 것을 알 수 있습니다. 로컬 캐시에서 이전에 얻은 결과는 TTL이 319 초에 불과했습니다.이를 확인하기 전에 거의 5 분 동안 (600-319) 초 동안 캐시에 앉아 있었음을 나타냅니다.
여기에서 TTL은 600 초에 불과하지만 일부 ISP는 DNS 확인자가 결과를 더 길게 (경우에 따라 24 시간 이상) 캐시하도록함으로써 트래픽을 더욱 줄이려고 시도합니다. DNS 변경 사항이 모든 곳에서 보이지 않을 것이라고 가정하는 것은 전통적입니다 (우리는 알지 못한다면 이것이 실제로 필요하지만 안전 할 것입니다). 24-48 시간 동안 인터넷.