우리의 도메인 인 grahamhancock.com은 전 세계의 소수의 사람들에 의해 잘못 해결되고 있지만 대부분의 사람들에게는 올바르게 해결됩니다.
무료 개방형 DNS 제공 업체 목록을 살펴보면 약 90 %가 올바르게 확인되고 영역 파일과 일치하는 정보를 제공합니다. 그러나 10 %는 IP 주소가 과거에 소유하거나 사용하지 않은 Amazon EC2 인스턴스에 연결된 주소라고 주장하지 않습니다 . 잘못된 정보를 제공하는 DNS 서버의 예는 다음과 같습니다.
dig www.grahamhancock.com @173.84.127.88
dig www.grahamhancock.com @209.222.18.222
이 서버들은 어떻게 잘못된 정보를 가질 수 있으며 어떻게 상황을 통제 할 수 있습니까?
이것이 악의적이거나 구성 오류 일 수 있습니까? Google은 한 달에 100 만 히트 사이트로 검색 순위가 우수하므로 악의적 인 대상이 될 수 있습니다. 잘못된 서버가 일부 사람들에게 반환하는 잘못된 IP 주소는 AWS EC2 인스턴스의 빠른 리치 사이트를 가리 킵니다.
우리는 무엇을해야합니까?
답변
방랑자가 맞습니다. 네임 서버 구성에 문제가 있습니다. 출력의 꼬리 끝은 다음과 같습니다 dig +trace +additional www.grahamhancock.com.
grahamhancock.com. 172800 IN NS ns1.grahamhancock.com.
grahamhancock.com. 172800 IN NS ns2.grahamhancock.com.
grahamhancock.com. 172800 IN NS server.grahamhancock.com.
ns1.grahamhancock.com. 172800 IN A 199.168.117.67
ns2.grahamhancock.com. 172800 IN A 199.168.117.67
server.grahamhancock.com. 172800 IN A 199.168.117.67
;; Received 144 bytes from 192.35.51.30#53(f.gtld-servers.net) in 92 ms
www.grahamhancock.com. 14400 IN CNAME grahamhancock.com.
grahamhancock.com. 14400 IN A 199.168.117.67
grahamhancock.com. 86400 IN NS ns2.grahamhancock.com.com.
grahamhancock.com. 86400 IN NS ns1.grahamhancock.com.com.
;; Received 123 bytes from 199.168.117.67#53(ns2.grahamhancock.com) in 17 ms
글루 레코드가 올바른 응답을 반환하는 IP 주소 199.168.117.67을 가리키고 있습니다. 그러나 귀하의 영역은로 끝나는 네임 서버 레코드를 정의하고 com.com있습니다. 만약 우리 +trace가 그 네임 서버 중 하나 라면 …
com.com. 172800 IN NS ns-180.awsdns-22.com.
com.com. 172800 IN NS ns-895.awsdns-47.net.
com.com. 172800 IN NS ns-1084.awsdns-07.org.
com.com. 172800 IN NS ns-2015.awsdns-59.co.uk.
;; Received 212 bytes from 192.26.92.30#53(c.gtld-servers.net) in 22 ms
ns1.grahamhancock.com.com. 30 IN A 54.201.82.69
com.com. 172800 IN NS ns-1084.awsdns-07.org.
com.com. 172800 IN NS ns-180.awsdns-22.com.
com.com. 172800 IN NS ns-2015.awsdns-59.co.uk.
com.com. 172800 IN NS ns-895.awsdns-47.net.
;; Received 196 bytes from 205.251.195.127#53(ns-895.awsdns-47.net) in 16 ms
… 우리는 누군가의 AWS 호스팅 네임 서버에서 끝납니다.
문제는 글루 레코드 불일치 로 알려져 있습니다. 원격 네임 서버는 처음에 글루 레코드를 통해 도메인에 대해 학습 하지만 일단 원격 서버가 새로 고침 을 수행하면 끝에 추가 .com로 정의한 가짜 네임 서버를 쿼리하게 됩니다.
이것이 유일한 문제는 아닙니다. 접착제 레코드에 동일한 IP 주소를 세 번 나열하는데, 이는 매우 변동 적입니다. 항상 여러 개의 네임 서버가 있어야하고 서브넷이나 업스트림 네트워크 피어를 공유해서는 안되며 동일한 물리적 위치에 위치해서는 안됩니다. 현재로서는 DNS 서버와 단일 서버 간의 간단한 라우팅 문제로 인해 도메인에 일시적으로 연결할 수 없습니다.
최신 정보:
이 Q & A는 첫 페이지에 소개되었으며 많은 의견을 받고 있습니다. 불행하게도, 그것은 단지 사람들이 포함 작은 자신의 포인트가 이미 확장 된 의견에 해결되었습니다 있는지 확인하지 않고이 답변에 댓글을 올리려면 너무 열망을.
대부분의 사람들이 간과하는 세부 사항은 내가 인용하고있는 의견입니다.
- […] 지역 중복 DNS 서버는 짧은 라우팅 중단으로 인해 일시적으로 네임 서버가 캐싱되는 시나리오를 방지합니다. 그러나 네거티브 캐싱 기간이 짧아지면 연결 중단이 발생한 시간을 거의 확실히 초과하게됩니다. […] DNS 지역 중복이 부족하지 않아 산발적으로 발생하지 않고 가용성 문제를 해결하기 어려운 시나리오의 수는 정확히 0입니다.
네임 서버에 대한 부정적인 캐싱에 대한 나의 이해가 잘못되었다고 생각한다면, 그것은 토론을위한 공개 게임이지만, 그 밖에는 “소규모 사이트이고 웹 사이트와 DNS 서버가 다운되었는지 걱정하는 사람이 아닌 다른 사람에게 테이블을 가져와야합니다.” 동시에 ” 당신이 이것을 말하고 있다면 당신은 생각하는 것만 큼 주제를 거의 이해하지 못합니다.
두 번째 업데이트 :
앞으로 단일 DNS 서버 주제가 올 때마다 연결할 수 있는 표준 Q & A 를 작성했습니다 . 잘만되면 이것은 문제를 쉬게한다.
답변
다음 도구를 사용하면 몇 가지 단서가 제공됩니다.
https://www.whatsmydns.net/#NS/grahamhancock.com도메인의 NS 레코드 ns1.grahamhancock.com.com가 추가 .com 을 알 수 있다고보고합니다.
http://mxtoolbox.com/SuperTool.aspx?action=dns%3agrahamhancock.com&run=toolpage 또한 동일한 네임 서버가 권위있는 것으로보고한다고보고합니다.
여기를 보면 http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=grahamhancock.com이름 서버가 열려 있다고보고됩니다.
따라서 네임 서버가 올바르게 설정되지 않은 라인 어딘가에 나타납니다. 제어판 등을 통해 올바르게 표시되는 경우 실제 서버에서 확인할 수 있도록 공급자에게 문의해야합니다.
이러한 링크에는 모범 사례 및이를 처리하는 방법에 대한 전체 보고서도 있습니다.