지금 저는 Linux sysadmin에 대한 온라인 강좌를 듣고 있는데 일반적으로 이해하지 못하는 질문을 받았습니다. 나는 네임 서버를 검색하는 방법을 알고 있습니다. 최소한 dig 명령을 사용하여 추가 섹션 명령에서 주소를 찾는 것입니다. 그러나 다음 질문을 받았을 때 약간 당황했습니다.
구성된 네임서버에 캐시된 결과가 없다고 가정할 때,maps.google.com을 확인하려면 네임서버에 몇 개의 네임서버를 쿼리해야 합니까? 이러한 모든 네임서버를 찾으려면 어떤 명령을 사용하시겠습니까? 각 수준에서 하나를 나열하고 이 수준이 필요한 이유를 설명하십시오.
나는 대답을 원하지 않고, 내가 정확히 무엇을 하라는 요청을 받고 있는지 알고 싶습니다.
답변1
구성된 네임서버에 캐시된 결과가 없다고 가정할 때,maps.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클라이언트로 돌아가십시오.)
각 서버에서 전체 RR 이름을 요청하는 것(나쁜 습관으로 간주될 수 있음)에 대한 대안은 이전에 결정한 분할된 레이블 목록을 사용하고 서버가 제공한 이름 서버에 IN NS및 IN A/ IN AAAARR의 루트쪽으로 더 멀리 요청하는 것입니다. 해당 레이블에 대해 이를 사용하여 이름 확인 프로세스를 진행합니다. 실제로는 약간만 다를 뿐이며 동일한 프로세스가 여전히 적용됩니다.
BIND 또는 의 일부로 제공되는 유틸리티 +trace에 대한 옵션을 사용하여 이 전체 프로세스를 시뮬레이션할 수 있습니다 .digset debugnslookup
NS또한 일부 RR 유형(특히 , MX기타 몇 가지 유형, A6한동안 합리적으로 잘 사용되었지만 더 이상 사용되지 않음)이 다른 RR을 참조할 수 있고 수행한다는 점을 기억할 가치가 있습니다 . 그런 경우에는 스폰해야 할 수도 있습니다.또 다른고객에게 완전하고 유용한 답변을 제공하기 위한 이름 확인 프로세스.
답변2
dnstracer이름 확인을 추적하는 명령(적어도 Debian에서는 설치해야 할 수도 있으며 패키지 이름이기도 함)이 있습니다 . (Koveras가 주석에서 지적했듯이) 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.