구성된 네임 서버에 캐시 된 결과가 없다고 가정하면 maps.google.com을 해결하기 위해 네임 서버에서 몇 개의 네임 서버를 쿼리해야합니까? 이 네임 서버를 모두 찾으려면 어떤 명령을 사용 하시겠습니까? 각 레벨에서 하나씩 나열하고이 레벨이 필요한 이유를 설명하십시오.
자, 이것을 골라 봅시다.
"구성된 네임 서버에 캐시 된 결과가 없다고 가정" -먼저 캐시 된 데이터 가 없으면 아무것도 해결할 수 없습니다. 리졸버 캐시를 프라이밍하려면 .
(AKA 루트) 영역에 대한 NS 및 주소 (A, AAAA) 레코드가 있어야합니다 . 그것은 영역에있는 루트 이름 서버 root-servers.net.
입니다. 해당 영역이나 해당 DNS 서버에는 마법이 없습니다. 그러나이 데이터는 종종 리졸버의 캐시를 프라이밍하기 위해 DNS 리졸버에 "대역 외"로 제공됩니다. 신뢰할 수있는 이름 서버에는이 데이터가 필요하지 않지만 이름 서버 확인에 필요합니다.
또한 무엇을 "해결"합니까? 그 이름의 RRtype이 있습니까? A
RR? 또는 다른 것? 어떤 클래스 ( CH
/ Chaosnet, IN
/ Internet, ...)? 정확한 과정은 다르지만 일반적인 생각은 동일합니다.
루트 이름 서버를 찾는 방법을 알고 있지만 더 이상 아무것도 없다고 가정 할 수 있고 "해결"이란 IN A
이름과 관련된 모든 RR 의 내용을 얻는 것을 의미 하므로 훨씬 더 실용적입니다.
DNS 이름을 확인하려면 기본적으로 이름을 레이블로 나누고 오른쪽에서 왼쪽으로 작업하십시오. .
마지막을 잊지 마십시오 . 당신은 정말로 maps.google.com.
보다는 오히려 해결하고있을 것 maps.google.com
입니다. 따라서 해결해야 할 필요가 있습니다 (우리는 이것을 알고 있지만 DNS 확인자 구현은 아마 그렇지 않습니다).
.
com.
google.com.
maps.google.com.
의 콘텐츠를 요청할 위치를 파악하는 것으로 시작하십시오 .
. 쉽습니다. 루트 이름 서버 이름 및 IP 주소와 같은 정보가 이미 있습니다 . 그래서 우리는 루트 네임 서버를 가지고 있습니다. a.root-servers.net
이름 확인을 계속 하기 위해 198.41.0.4 ( , 2001 : 503 : ba3e :: 2 : 30)를 사용하기로 결정했다고 가정 해 보겠습니다 . 실제로, 리졸버가 수행하는 첫 번째 작업 중 하나는 제공된 루트 서버 데이터를 사용하여 루트 영역 서버 중 하나에 루트 영역에 대한 정확한 이름 서버 목록을 요청하여 다음 중 하나가 이름과 IP 주소는 유효하고 연결 가능하며, 분석이 시작될 때 루트 영역에 대한 전체 데이터 세트를 갖습니다.
maps.google.com. IN A
198.41.0.4에 대한 DNS 쿼리 를 시작하십시오. "아니요,하지 않겠지 만 여기에 아는 사람이 있습니다"라는 응답으로 알려줄 것입니다. 그것은 추천입니다. 여기에는 NS
해당 서버가 알고있는 가장 가까운 영역에 대한 레코드와 서버가 사용할 수있는 글루 레코드가 포함됩니다. 글루 데이터를 사용할 수없는 경우 먼저 선택한 NS 레코드에 이름이 지정된 호스트를 확인해야하므로 IP 주소를 얻기 위해 별도의 이름 확인을 생성합니다. 글루 데이터를 사용할 수있는 경우 답변에 "가까운"네임 서버의 IP 주소를 갖게됩니다. 이 경우 해당 com.
영역에 대한 서버 집합이 되고 글루 데이터도 제공됩니다.
com.
이름 서버 중 하나에 같은 질문을 하면서 프로세스를 반복하십시오 . 그들은 모르지만 Google의 권위있는 네임 서버를 추천합니다. 일반적인 경우이 시점에서 글루 데이터가 제공되는지 여부에 관계없이 적발되거나 누락됩니다. 예를 들어 gTLD 서버에서 글루 데이터를 사용할 수없는 경우와 같이 com
도메인에 이름 서버 만있는 것을 막을 수있는 것은 없습니다 nl
. 제공된 접착제 데이터가 불완전하거나 실제로 운이 좋지 않으면 잘못 될 수도 있습니다! 위에서 언급 한 별도의 이름 확인을 생성 하기 위해 항상 준비해야합니다.
기본적으로 aa
(정식 답변) 플래그가 설정된 답변 을 얻을 때까지 계속 진행 합니다. 이 답변은 귀하가 요청하는 내용 또는 요청한 RR이 존재하지 않음을 나타냅니다 ( NXDOMAIN
또는 NOERROR
응답 데이터 레코드가 없음). 같은 응답을 계속 찾아 SERVFAIL
보십시오 (한 단계를 취소하고 하나의 서버가 있으면 다른 서버를 사용해보십시오. 모든 명명 된 서버가을 반환 SERVFAIL
하면 이름 확인 프로세스에 실패 SERVFAIL
하고 클라이언트에게 자신을 반환 하십시오).
각 서버에서 전체 RR 이름을 요청하는 대안 (나쁜 습관으로 간주 될 수 있음)은 이전에 결정한 레이블의 분할 목록을 사용하는 것입니다. 서버가 제공 한 이름 서버에 / IN NS
및 RR 의 루트를 향해 추가로 요청하십시오. 해당 레이블을 사용하여 이름 확인 프로세스를 진행시킵니다. 실제로는 약간 차이가 있으며 동일한 프로세스가 여전히 적용됩니다.IN A
IN AAAA
당신은 사용하여이 전체 프로세스를 시뮬레이션 할 수 있습니다 +trace
받는 옵션이 dig
BIND의 일환으로, 또는 온다 유틸리티 set debug
에를 nslookup
.
또한 일부 RR 유형 (특히 NS
, MX
일부 다른 유형도 A6
한동안 합리적으로 잘 사용되었지만 더 이상 사용되지 않음)은 다른 RR을 참조 할 수 있으며 참조 할 수 있음을 기억할 가치가 있습니다. 이 경우 고객 에게 완전하고 유용한 답변을 제공하기 위해 또 다른 이름 확인 프로세스를 생성해야 할 수도 있습니다 .
dig +trace
하고 있었지만 레벨의 의미가 확실하지 않습니다. 서버 결함에 대한 질문 일 수 있습니다.