DNS 캐시의 정확성에 문제가있는 dig +trace경우 인터넷 연결 DNS 레코드에 대한 정식 답변을 결정하는 데 권장되는 방법 인 경향이 있습니다. 이것은 또한와 결합 할 때 특히 유용한 것으로 보이며 +additional, 이는 또한 글루 레코드를 보여줍니다.
때때로이 시점에서 약간의 의견 차이가있는 것 같습니다. 어떤 사람들은 중간 이름 서버의 IP 주소를 찾기 위해 로컬 리졸버에 의존하지만 명령 출력은 이것이 루트의 초기 목록을 넘어서고 있다는 표시를 제공하지 않습니다 네임 서버. +trace루트 서버에서 시작하여 추적 하는 경우에는 그렇지 않다고 가정하는 것이 합리적 입니다. (적어도 루트 이름 서버의 올바른 목록이있는 경우)
dig +trace루트 네임 서버를 지나서 로컬 리졸버를 사용 합니까 ?
답변:
이것은 분명히 단계적인 Q & A이지만, 사람들을 자주 혼동하는 경향이 있으며 주제를 다루는 정식 질문을 찾을 수 없습니다.
dig +trace훌륭한 진단 도구이지만 디자인의 한 측면은 널리 이해되지 않습니다. 쿼리 할 모든 서버의 IP는 리졸버 라이브러리에서 얻습니다 . 이것은 쉽게 간과되고 로컬 캐시에 캐시 된 네임 서버에 대한 잘못된 응답 이있을 때 종종 문제가됩니다 .
출력 샘플로 분석하기가 더 쉽습니다. 첫 NS 대표단을지나 모든 것을 생략하겠습니다.
; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com
;; global options: +cmd
. 121459 IN NS d.root-servers.net.
. 121459 IN NS e.root-servers.net.
. 121459 IN NS f.root-servers.net.
. 121459 IN NS g.root-servers.net.
. 121459 IN NS h.root-servers.net.
. 121459 IN NS i.root-servers.net.
. 121459 IN NS j.root-servers.net.
. 121459 IN NS k.root-servers.net.
. 121459 IN NS l.root-servers.net.
. 121459 IN NS m.root-servers.net.
. 121459 IN NS a.root-servers.net.
. 121459 IN NS b.root-servers.net.
. 121459 IN NS c.root-servers.net.
e.root-servers.net. 354907 IN A 192.203.230.10
f.root-servers.net. 100300 IN A 192.5.5.241
f.root-servers.net. 123073 IN AAAA 2001:500:2f::f
g.root-servers.net. 354527 IN A 192.112.36.4
h.root-servers.net. 354295 IN A 128.63.2.53
h.root-servers.net. 108245 IN AAAA 2001:500:1::803f:235
i.root-servers.net. 355208 IN A 192.36.148.17
i.root-servers.net. 542090 IN AAAA 2001:7fe::53
j.root-servers.net. 354526 IN A 192.58.128.30
j.root-servers.net. 488036 IN AAAA 2001:503:c27::2:30
k.root-servers.net. 354968 IN A 193.0.14.129
k.root-servers.net. 431621 IN AAAA 2001:7fd::1
l.root-servers.net. 354295 IN A 199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms
. IN NS(루트 이름 서버)에 대한 초기 쿼리 는 로컬 확인자 (이 경우 Comcast)에 도달합니다. ( 75.75.75.75) 이것은 발견하기 쉽다.serverfault.com. IN A에 대해 실행됩니다 e.root-servers.net.. IP 주소는 192.203.230.10이며 +additional활성화했기 때문에 접착제에서 오는 것처럼 보입니다 .com.TLD 네임 서버에 위임됩니다 .dig하지 않은 e.root-servers.net.것은 접착제에서 IP 주소 를 얻지 못했다 는 것입니다 .백그라운드에서 이것은 실제로 일어난 일입니다.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)
+trace글루를 문의하는 대신 다음 홉 네임 서버의 IP 주소를 얻기 위해 로컬 리졸버를 속이고 문의했습니다. 교활한!
이것은 일반적으로 "충분히 충분"하며 대부분의 사람들에게 문제를 일으키지 않습니다. 불행히도, 가장자리 경우가 있습니다. 어떤 이유로 든 업스트림 DNS 캐시가 네임 서버에 잘못된 답변을 제공하는 경우이 모델은 완전히 분해됩니다.
실제 예 :
위의 경우 +trace도메인 소유자의 자체 네임 서버가 문제의 원인이며 고객에게 서버가 잘못 구성되었다고 잘못 알리는 것이 좋습니다. 그것이 당신이 할 수있는 일 (또는 기꺼이하는 일)인지 아닌지는 또 다른 이야기이지만, 올바른 정보를 갖는 것이 중요합니다.
dig +trace 훌륭한 도구이지만 다른 도구와 마찬가지로 도구의 기능과 수행하지 않는 동작 및 불충분 한 것으로 입증 된 문제를 수동으로 해결하는 방법을 알아야합니다.
편집하다:
또한 별칭 을 가리키는 레코드에 dig +trace대해서는 경고하지 않습니다 . 이는 ISC BIND (및 기타)가 정정을 시도하지 않는 RFC 위반입니다. BIND가 전체 재귀를 수행하는 경우 SERVFAIL을 사용하여 전체 영역을 거부하는 반면 로컬로 구성된 네임 서버에서 가져온 레코드 를 수락하면 기쁠 것입니다.NSCNAME+traceA
접착제가 있으면 문제를 해결하기가 까다로울 수 있습니다. NS 레코드가 새로 고쳐질 때까지 제대로 작동 하고 갑자기 중단됩니다. 레코드가 별칭을 가리킬 때 글루리스 위임은 항상 BIND의 재귀를 중단 NS합니다.
+nssearch수행 한 NS후 리턴 된 각 이름 서버에 대해 로컬 리졸버에 대한 일련의 A/ AAAA조회를 수행합니다. 마찬가지로 캐시에서 이름 서버 레코드를 가짜로 만들 수 있습니다.
루트 네임 서버를 찾는 것을 제외하고 로컬 리졸버를 사용하지 않고 DNS 확인을 추적하는 또 다른 방법은 dnsgraph를 사용하는 것입니다 (전체 공개 :이 글을 썼습니다). 명령 행 도구와 웹 버전이 있으며 http://ip.seveas.net/dnsgraph/ 에서 인스턴스를 찾을 수 있습니다.
실제로 DNS 문제가있는 serverfault.com의 예 :
이 스레드에 대해 매우 늦었지만 dig + trace가 로컬 리졸버에 재귀 쿼리를 사용하는 이유에 대한 질문 부분은 직접 설명되지 않았 으며이 설명은 dig + trace 결과의 정확성과 관련이 있습니다.
루트 영역의 NS 레코드에 대한 초기 재귀 쿼리 후 dig는 다음 조건에서 로컬 리졸버에게 후속 쿼리를 발행 할 수 있습니다.
다음 반복 쿼리에 대해 응답 크기가 512 바이트를 초과하여 조회 응답이 잘립니다.
dig는 추가 섹션에 해당 A 레코드 (접착제)가없는 참조 응답의 AUTHORITY 섹션에서 NS 레코드를 선택합니다.
dig에는 NS 레코드의 도메인 이름 만 있으므로 dig는 로컬 DNS 서버를 쿼리하여 이름을 IP 주소로 확인해야합니다. 이것이 근본 원인입니다 (말장난, 미안).
AndrewB는 선택한 루트 영역 NS 레코드에서 방금 설명한 것과 완전히 일치하지 않는 예를 가지고 있습니다.
. 121459 IN NS e.root-servers.net.
해당 A 레코드가 있습니다.
e.root-servers.net. 354907 IN A 192.203.230.10
그러나 e-root에 해당하는 AAAA 레코드가없고 다른 루트 서버에 대한 AAAA 레코드도 없습니다.
또한 응답의 크기에 유의하십시오.
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms
496 바이트는 잘린 응답의 일반적인 크기입니다 (즉, 다음 글루 레코드는> 16 바이트가되어 응답이 512 바이트를 초과 함). 즉, 루트의 NS 레코드에 대한 쿼리에서 완전한 AUTHORITY 및 완전 추가 (A 및 AAAA 레코드 모두)는 512 바이트를 초과하므로 EDNS0 옵션을 통해 더 큰 쿼리 크기를 지정하지 않는 모든 UDP 기반 쿼리는 위의 추적에서 알 수 있듯이 추가 섹션 어딘가에서 잘린 응답을 얻으십시오 (f, h, i, j 및 k 만 A 및 AAAA 접착제 레코드가 있음).
e.root-servers.net에 대한 AAAA 레코드 부족 및 "NS"에 대한 응답 크기 쿼리는 내가 주장하는 이유로 다음 재귀 쿼리가 수행되었음을 강력히 제안합니다. 아마도 클라이언트 O / S는 IPv6를 지원하며 AAAA 레코드 또는 다른 이유로 선호합니다.
그러나 어쨌든이 스레드를 읽은 후 루트에 대한 초기 쿼리 다음에 재귀 쿼리를 수행하는 dig + trace 현상을 조사했습니다. 해당 접착제 A / AAAA 레코드가없는 NS 레코드를 선택하고 해당 레코드에 대한 재귀 쿼리를 로컬 DNS에 보내는 것은 100 %입니다. 그리고 그 반대가 사실입니다-추천에서 선택한 NS 레코드에 해당 글루 레코드가있을 때 재귀 쿼리를 보지 못했습니다.
+nssearch?