저는 지금 Linux 시스템 관리자 온라인 강좌를 수강하고 있는데 누군가 제가 평소에는 이해하지 못하는 질문을 했습니다. 나는 네임서버를 검색하는 방법을 알고 있습니다. 내가 맞다면 최소한 dig 명령을 사용하여 추가 부분 명령에서 주소를 찾습니다. 그러나 다음 질문을 받으면 약간 당황합니다.
구성한 네임서버에 사용할 캐시된 결과가 없다고 가정할 때, 귀하의 네임서버는 map.google.com을 확인하기 위해 몇 개의 네임서버를 쿼리해야 합니까? 이러한 모든 이름 서버를 찾으려면 어떤 명령을 사용하시겠습니까? 각 수준 중 하나를 나열하고 해당 수준이 필요한 이유를 설명하십시오.
나는 대답을 원하지 않고 단지 내가 무엇을 하라는 요청을 받고 있는지 알고 싶을 뿐입니다.
답변1
구성한 네임서버에 사용할 캐시된 결과가 없다고 가정할 때, 귀하의 네임서버는 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끝나고 나면 더 있어요고객에게 완전하고 유용한 답변을 제공하기 위한 이름 확인 프로세스입니다.
답변2
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물론, 예를 들어 온라인으로 실제 쿼리를 볼 수도 있습니다 .