예를 들어 google.com의 DNS 조회를 추적하면 dig는 루트 서버에 대한 요청만 표시한 다음 최상위 도메인을 건너뛰고 곧바로 2차 도메인 서버로 이동합니다. 즉, a.root-servers.net에서 ns1.google.com으로 이동합니다. 이 사진에서 볼 수 있듯이 그 사이에 있어야 했던 [ah].gtld-servers.net TLD 서버는 어떻습니까? 왜 결과에 표시되지 않나요? 다른 호스트 이름에서도 같은 일이 발생합니다. 예를 들어 gaia.cs.umass.edu입니다. 그림 루트 서버에서 ns[1-3].umass.edu로 이동합니다. a.edu-servers.net과 같은 모든 .edu TLD 서버는 어디에 있습니까?
답변1
이러한 결과는 네트워크에 뭔가 이상한 일이 벌어지고 있다고 의심하는 것보다 네트워크에 dig뭔가 이상한 일이 벌어지고 있는 것은 아닌지 의심하게 만듭니다.
어떤 형태로든 투명한 "프록시"가 진행되고 있나요? 즉, 199.7.91.13(예제 중 하나에서 볼 수 있듯이 루트 서버 중 하나) 에 대한 쿼리가 실제로 해당 주소로 전송되었거나 다른 곳(일부 로컬 반복자)으로 리디렉션됩니까?
한 가지 가설은 모든 DNS 트래픽이 반복기로 전송되어 전체 출력에 표시된다는 것입니다(신뢰할 수 있는 응답을 얻지 못할 것입니다... 즉, aa플래그가 없습니다).
추적 아이디어를 계속하려면 다음을 실행할 수 있습니다.
dig +trace +all example.com
그러면 각 단계에 대한 전체 출력이 제공됩니다. 응답의 세부 사항을 살펴보세요. 루트 서버의 응답( SERVER: ...각 응답 하단에 표시됨)이 실제로 신뢰할 수 있는 응답입니까?
이와 같은 쿼리는 이상한 일이 발생하는 경우 노출하는 데 도움이 될 수도 있습니다. 실제 '199.7.91.13'의 응답과 비교해 보세요. (단일 서버가 아니기 때문에 응답이 반드시 일관적일 필요는 없지만 무엇을 기대해야 할지 알 수 있다는 점에 유의하세요.) 알려진 양호한 인터넷 연결에서 관찰됩니다.
dig @199.7.91.13 version.bind CH TXT +norec
(소프트웨어 + 버전 문자열로 응답할 수 있음)
dig @199.7.91.13 hostname.bind CH TXT +norec
(호스트 이름으로 응답할 수도 있음)
dig @199.7.91.13 id.server CH TXT +norec
(서버 식별자로 응답할 수 있음)