Một số máy chủ DNS trên thế giới cung cấp địa chỉ IP sai cho tên miền của chúng tôi?

Tên miền của chúng tôi, grahamhancock.com đang bị một số người trên thế giới giải quyết sai, nhưng nó giải quyết chính xác cho hầu hết mọi người.

Khi tôi chạy qua danh sách các nhà cung cấp DNS mở miễn phí, khoảng 90% giải quyết chính xác và cung cấp thông tin phù hợp với tệp vùng của chúng tôi. Tuy nhiên, 10% không và khẳng định địa chỉ IP là địa chỉ được liên kết với một số phiên bản Amazon EC2 mà chúng tôi chưa từng sở hữu hoặc sử dụng trước đây. Dưới đây là một số ví dụ máy chủ DNS cung cấp thông tin sai:

dig www.grahamhancock.com @173.84.127.88
dig www.grahamhancock.com @209.222.18.222

Làm thế nào những máy chủ này có thể có thông tin sai, và làm thế nào chúng ta có thể lấy lại quyền kiểm soát tình hình?

Đây có thể là một cái gì đó độc hại, hoặc cấu hình sai? Chúng tôi là trang web 1 triệu lượt truy cập mỗi tháng, với thứ hạng tìm kiếm tốt, vì vậy chúng tôi có thể là mục tiêu cho thứ gì đó độc hại. Địa chỉ IP sai mà máy chủ bị lỗi đang quay lại với một số người trỏ đến một số trang web làm giàu nhanh trên một ví dụ AWS EC2.

Chúng ta nên làm gì?

domain-name-system

— Duncan Marshall
nguồn

Đó có phải là tên miền thực tế?

— Drind104

Vâng, đó là miền thực sự.

— Duncan Marshall

Một số máy chủ DNS cũng được cấu hình kém, câu hỏi là tại sao khách hàng của bạn không sử dụng DNS ISP của họ? ít nhất bạn có thể yêu cầu một đường dây nóng để sửa nó nếu trên DNS ISP.

— yagmoth555 - GoFundMe Monica

Người dùng của chúng tôi đang sử dụng máy chủ DNS của ISP, nhưng những máy chủ đó sẽ không chấp nhận truy vấn của tôi vì tôi không phải là khách hàng của họ. Các máy chủ DNS ở trên là công khai và vì vậy tôi đã sử dụng chúng để kiểm tra. Nếu chúng được định cấu hình sai, chúng sẽ bị định cấu hình sai theo cùng một cách và đột nhiên bị định cấu hình sai, vì điều này đã không xảy ra ngày hôm qua. Đây là IP của một máy chủ DNS ISP của người dùng của chúng tôi: 177.86.168.11. Những người dùng khác của chúng tôi không đáp ứng hoặc đủ thành thạo để cung cấp cho chúng tôi IP máy chủ DNS của họ.

— Duncan Marshall

Tôi có thể cảm ơn sâu sắc đến người đăng ban đầu vì đã bao gồm tên miền thực sự trong câu hỏi của anh ấy, thay vì làm lại nó không? Như tôi đã có dịp lưu ý trước đây , các câu hỏi DNS là thành viên của lớp đó dễ trả lời nhanh và chính xác hơn khi thực hiện toàn bộ quy tắc và cá nhân tôi nghĩ rằng câu trả lời chất lượng rất cao mà câu hỏi này có được là do nhiều người nhãn cầu có thể nhìn thẳng vào vấn đề.

— MadHatter hỗ trợ Monica

Câu trả lời:

Sau đó là chính xác, bạn có một vấn đề cấu hình máy chủ tên. Đây là phần cuối của đầu ra từ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

Hồ sơ keo của bạn đang trỏ đến một địa chỉ IP 199.168.117.67, trả về phản hồi chính xác. Tuy nhiên, vùng của bạn đang xác định các bản ghi máy chủ tên kết thúc bằngcom.com . Nếu chúng ta +tracelà một trong những máy chủ tên thay thế ...

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

... Chúng tôi kết thúc tại máy chủ tên AWS được lưu trữ của ai đó.

Vấn đề của bạn là một cái gì đó được gọi là không phù hợp hồ sơ keo . Máy chủ tên từ xa ban đầu tìm hiểu về tên miền của bạn thông qua các bản ghi keo, nhưng một khi các máy chủ từ xa đó thực hiện làm mới , cuối cùng chúng sẽ truy vấn các máy chủ tên giả mà bạn đã xác định thêm .comvào cuối.

Đây không phải là vấn đề duy nhất của bạn.Bạn đang liệt kê cùng một địa chỉ IP ba lần trong hồ sơ keo của bạn, điều này cực kỳ dễ bay hơi. Bạn phải luôn có nhiều máy chủ tên, chúng không bao giờ nên chia sẻ mạng con hoặc mạng ngang hàng và chúng không bao giờ được đặt tại cùng một vị trí thực tế. Vì các vấn đề hiện đang tồn tại, bất kỳ vấn đề định tuyến ngắn nào giữa các máy chủ DNS và máy chủ duy nhất của bạn sẽ khiến tên miền của bạn tạm thời không thể truy cập được.

Cập nhật:

Câu hỏi và trả lời này đã được đăng trên trang nhất và đang nhận được rất nhiều bình luận. Thật không may, bao gồm những người chỉ là một chút quá háo hức để trả lời câu trả lời này mà không kiểm tra để xem nếu điểm của họ đã được giải quyết trong các ý kiến mở rộng.

Chi tiết mà hầu hết mọi người dường như đang nhìn là bình luận mà tôi đang trích dẫn ở đây:

[...] Các máy chủ DNS dự phòng địa lý ngăn chặn các tình huống trong đó gián đoạn định tuyến ngắn dẫn đến bộ đệm ẩn tiêu cực tạm thời của máy chủ tên. Tuy nhiên, ngắn gọn thời gian lưu trữ âm kết thúc, nó gần như chắc chắn sẽ vượt quá thời gian bị gián đoạn kết nối. [...] Số lượng kịch bản thiếu dự phòng địa lý DNS sẽ không tạo ra sự rời rạc và khó khắc phục sự cố về tính khả dụng hoàn toàn bằng không.

Nếu bạn nghĩ rằng sự hiểu biết của tôi về bộ nhớ đệm tiêu cực của máy chủ tên là sai, thì đó là trò chơi mở để thảo luận, nhưng bên ngoài đó bạn cần phải mang một cái gì đó đến bàn khác ngoài "đó là một trang web nhỏ và ai quan tâm nếu cả trang web và máy chủ DNS bị hỏng cùng một lúc". Nếu bạn đang nói điều này, bạn không hiểu chủ đề gần như bạn nghĩ bạn làm.

Cập nhật lần thứ hai:

Tôi đã tiếp tục và viết một câu hỏi và trả lời kinh điển mà chúng ta có thể liên kết đến bất cứ khi nào chủ đề máy chủ DNS duy nhất xuất hiện trong tương lai. Hy vọng điều này đặt vấn đề để nghỉ ngơi.

— Andrew B
nguồn

Nó không quan trọng những gì bạn nhìn thấy trong bảng điều khiển, đây là thực tế của nó. dig @199.168.117.67 grahamhancock.com NSlàm cho điều này rõ ràng rõ ràng - dữ liệu đó đến từ máy chủ của bạn. Đối với điều này là một "vấn đề tài chính", tôi sẽ nói thẳng ở đây: nếu bạn không chạy các máy chủ DNS dư thừa, bạn hoàn toàn không có doanh nghiệp nào vận hành DNS của riêng bạn. Bạn sẽ có thời gian chết. Trừ khi bạn rất thân với chủ sở hữu, bạn sẽ chịu trách nhiệm cho thời gian chết đó và cho phép cấu hình này được thực hiện.

— Andrew B

Tôi nghe thấy bạn, nhưng nó nằm ngoài tầm tay của tôi. Dù sao, nhờ sự giúp đỡ.

— Duncan Marshall

@Bodo đủ công bằng. Điều đó nói rằng, bạn vẫn đang nhìn vào thực tế rằng các máy chủ DNS dự phòng địa lý ngăn chặn các tình huống trong đó gián đoạn định tuyến ngắn dẫn đến bộ đệm ẩn tiêu cực tạm thời của máy chủ tên. Tuy nhiên, ngắn gọn thời gian lưu trữ âm kết thúc, nó gần như chắc chắn sẽ vượt quá thời gian bị gián đoạn kết nối. (hoặc nói một cách đơn giản hơn vì tôi không thể trả lời điều này: "blah blah blah DNS blah, số lượng kịch bản thiếu dự phòng địa lý DNS sẽ không tạo ra sự cố lẻ tẻ và khó khắc phục sự cố về tính khả dụng là chính xác" .)

— Andrew B

Bạn có thể nhận được lưu trữ DNS với giá 1 đô la với các máy chủ NS dự phòng. Đó không phải là một sự lựa chọn tài chính. Đừng là cao bồi.

— JamesRyan

Có rất nhiều nhà cung cấp DNS thứ cấp miễn phí phù hợp với các khu vực tải thấp. Hoặc như @JamesRyan đã nói ở trên, người ta có thể trả một khoản tiền (rất nhỏ) cho một dịch vụ được quản lý chuyên nghiệp với một số loại SLA. Cả hai đều là lựa chọn thay thế khả thi cho các trang web lưu lượng truy cập thấp.

— CVn

Sử dụng các công cụ sau đây cho một vài manh mối

https://www.whatsmydns.net/#NS/grahamhancock.combáo cáo rằng NS ghi lại trên điểm miền để ns1.grahamhancock.com.comthông báo thêm .com

http://mxtoolbox.com/SuperTool.aspx?action=dns%3agrahamhancock.com&run=toolpage cũng báo cáo rằng cùng một máy chủ tên đang báo cáo là có thẩm quyền.

Nếu bạn xem ở đây, http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=grahamhancock.comnó cũng báo cáo rằng máy chủ tên của bạn đang mở.

Vì vậy, nó sẽ xuất hiện ở đâu đó dọc theo dòng máy chủ tên không được đặt chính xác. Nếu chúng xuất hiện chính xác với bạn thông qua bảng điều khiển, v.v., bạn sẽ cần nói chuyện với nhà cung cấp để họ có thể kiểm tra chúng trên các máy chủ thực tế.

Những liên kết này cũng có một báo cáo đầy đủ về thực tiễn tốt nhất và cách đối phó với chúng

— Dri104
nguồn

Và các ký sinh trùng ^ H ^ H ^ H ^ H ^ H ^ H ^ H ^ H ^ Hpeople tại com.comđã cấu hình DNS ký tự đại diện để tận dụng loại lỗi này. Nếu bản ghi NS của bạn trỏ đến bất cứ thứ gì.com.com, họ sẽ trả lời bất kỳ truy vấn nào họ nhận được theo cách hướng lưu lượng truy cập đến họ. Hãy thử dig @anything.com.com anyotherthing.comvà kiểm tra thẩm quyền và các phần bổ sung của câu trả lời!