DNS 이름 확인은 원칙적으로 어떻게 작동합니까?

구성한 네임서버에 사용할 캐시된 결과가 없다고 가정할 때, 귀하의 네임서버는 map.google.com을 확인하기 위해 몇 개의 네임서버를 쿼리해야 합니까? 이러한 모든 이름 서버를 찾으려면 어떤 명령을 사용하시겠습니까? 각 수준 중 하나를 나열하고 해당 수준이 필요한 이유를 설명하십시오.

좋아요, 이것을 분석해 보겠습니다.

"구성한 네임서버에 캐시된 결과가 없다고 가정합니다."-- 먼저, 있다면아니요데이터가 전혀 캐시되지 않으면 문제가 해결되지 않습니다. 확인자의 캐시를 채우려면 .(AKA 루트) 영역에 대한 NS 및 주소(A, AAAA) 레코드가 있어야 합니다. 이것은 영역에 있는 루트 이름 서버입니다 root-servers.net.. 이 영역이나 DNS 서버에는 마법 같은 것이 없습니다. 그러나 이 데이터는 일반적으로 DNS 확인자에 "대역 외"로 제공되어 정확하게 확인자의 캐시를 채웁니다. 이 데이터는 권한 있는 이름 서버에는 필요하지 않지만 이름 서버를 확인하는 데는 필요합니다.

그리고 "결단"이란 무엇입니까? 이 이름에 대한 RRtype이 있습니까? RR A? 아니면 다른 것입니까? 어떤 클래스( CH/Chaosnet, IN/Internet,...)? 정확한 프로세스는 다양하지만 일반적인 아이디어는 동일합니다.

우리가 루트 네임서버를 찾는 방법을 알고 있지만 그 이상은 아니라고 가정할 수 있고 "해결"이란 해당 이름과 관련된 모든 RR의 내용을 얻는 것을 의미한다고 가정할 수 있다면 IN A더 실용적이 됩니다 .

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 A198.41.0.4에 대한 DNS 쿼리를 실행합니다 . "아니요, 그렇게 하지 않겠습니다. 하지만 여기 있는 누군가는 그것이 추천이라는 것을 알고 있을 것입니다."라고 말할 것입니다. 여기 NS에는 문제의 서버에 알려진 가장 가까운 영역에 대한 레코드와 서버에서 사용할 수 있는 모든 글루 레코드가 포함됩니다 . 글루 데이터를 사용할 수 없는 경우 먼저 선택한 NS 레코드에 지정된 호스트를 확인해야 합니다. 따라서 글루 데이터를 사용할 수 있는 경우 IP 주소를 얻기 위해 별도의 이름 확인을 생성해야 합니다. 답변에 대한 답변 이름 서버의 IP 주소입니다. 이 경우 이는 해당 지역의 서버 세트가 되며 com.글루 데이터도 제공합니다.

com.이름 서버 중 하나에 동일한 질문을 하면서 프로세스를 반복합니다 . 그들도 모르지만 Google의 신뢰할 수 있는 이름 서버를 추천할 것입니다. 이 시점에서는 일반적으로 글루 데이터 제공 여부에 관계없이 문제가 발생합니다. 예를 들어 com도메인이 에 이름 서버만 갖는 것을 막을 방법이 없으며 nl이 경우 gTLD 서버에서 글루 데이터를 얻을 가능성이 없습니다. 제공된 글루 데이터도 불완전할 수 있으며, 운이 좋지 않으면 정확하지 않을 수도 있습니다! 당신은해야합니다언제나위에서 언급한 별도의 이름 확인을 생성할 준비를 하십시오.

기본적으로 (정식 답변) 플래그가 설정된 답변을 얻을 때까지 계속 진행합니다 aa. 이 답변은 귀하가 요청하는 것이 무엇인지, 또는 귀하가 요청하는 RR이 존재하지 않음( NXDOMAIN또는 NOERROR응답 데이터 기록이 없음) 을 알려줍니다 . 유사한 응답을 계속 찾으십시오 SERVFAIL. 응답을 받으면 한 걸음 물러서서 다른 서버를 시도하십시오. 모든 이름 서버가 를 반환하면 SERVFAIL이름 확인 프로세스가 실패하고 SERVFAIL클라이언트에 자체적으로 반환됩니다.

각 서버에서 전체 RRname을 요청하는 대신(나쁜 습관으로 간주될 수 있음) 이전에 식별한 레이블을 사용하여 목록을 분할하고 서버에서 제공한 이름 서버와 해당 레이블에 대한 IN NS/ IN ARR 의 루트를 사용하여 추가로 쿼리하는 것입니다. IN AAAA, 이를 사용하여 이름 확인 프로세스를 진행합니다. 이는 실제로는 약간만 다를 뿐이며 동일한 프로세스가 여전히 적용됩니다.

+tracedigBIND의 일부 또는 set debug에서 사용할 수 있는 유틸리티 옵션을 사용하여 전체 프로세스를 시뮬레이션할 수 있습니다 nslookup.

또한 일부 RR 유형(특히 및 기타 몇 가지 유형, 게다가 한동안 합리적으로 잘 작동했지만 더 이상 사용되지 않음)이 다른 RR을 참조할 수 있고 참조할 수 있다는 NS점 을 기억할 가치가 있습니다. 이 경우 생성해야 할 수도 있습니다.MXA6끝나고 나면 더 있어요고객에게 완전하고 유용한 답변을 제공하기 위한 이름 확인 프로세스입니다.

dnstracer이름 확인을 추적하는 명령(적어도 Debian에서는 설치해야 할 수도 있으며 패키지 이름이기도 함)이 있습니다 . (코베라스가 주석에서 지적했듯이) dig.

dnstracer 입니다. -s .루트에서 시작한다는 의미이고, -4IPv4를 사용한다는 의미입니다(v6는 여기서 깨졌습니다...). -o실제로 마지막에 확인된 IP 주소를 표시한다는 의미입니다(출력에서 이 부분을 생략했습니다. 많은 부분이 있습니다).

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

dnstracer가 모든 경로를 추적하므로 출력이 계속됩니다(일부 이름 서버에 오래된 영역이 있는지 확인할 수 있음).

따라서 루트 이름 서버에 대한 쿼리, gtld-servers(.com 영역의 서버)에 대한 쿼리, 마지막으로 Google 이름 서버에 대한 쿼리가 필요하다는 것을 알 수 있습니다.

를 사용하면 dig출력이 더 장황해집니다(따라서 가지치기를 많이 했습니다).

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

dig또한 현재 루트 이름 서버 목록을 가져오기 위해 쿼리를 수행하는 것을 보여줍니다. DNS 서버는 일반적으로 이 작업을 거의 수행하지 않습니다. 따라서 콜드 캐시의 경우에도 이를 계산하는지 잘 모르겠습니다.

wireshark물론, 예를 들어 온라인으로 실제 쿼리를 볼 수도 있습니다 .