Beberapa server DNS di dunia memberikan alamat IP yang salah untuk domain kami?

Domain kami, grahamhancock.com sedang salah diselesaikan oleh beberapa orang di seluruh dunia, tetapi itu diselesaikan dengan benar untuk kebanyakan orang.

Ketika saya menjalankan daftar penyedia DNS terbuka gratis, sekitar 90% menyelesaikan dengan benar dan memberikan informasi yang konsisten dengan file zona kami. 10%, bagaimanapun, tidak, dan mengklaim alamat IP sebagai salah satu yang terhubung ke beberapa contoh Amazon EC2 yang belum pernah kita miliki atau gunakan sebelumnya. Berikut adalah beberapa contoh server DNS yang memberikan informasi yang salah:

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

Bagaimana server-server ini memiliki informasi yang salah, dan bagaimana kita dapat kembali mengendalikan situasi?

Mungkinkah ini sesuatu yang berbahaya, atau kesalahan konfigurasi? Kami adalah situs 1 juta klik per bulan, dengan peringkat pencarian yang baik, jadi kami mungkin target untuk sesuatu yang berbahaya. Alamat IP yang salah bahwa server yang salah kembali ke beberapa orang menunjuk ke beberapa situs kaya-cepat pada instance AWS EC2.

Apa yang harus kita lakukan?

domain-name-system

— Duncan Marshall
sumber

Apakah itu nama domain yang sebenarnya?

— Drifter104

Ya, itu domain asli.

— Duncan Marshall

Beberapa server DNS juga dikonfigurasi dengan buruk, pertanyaannya adalah mengapa pelanggan Anda tidak menggunakan DNS ISP mereka? sebagai minimal Anda dapat meminta hotline untuk memperbaikinya jika pada ISP DNS.

— yagmoth555 - GoFundMe Monica

Pengguna kami menggunakan server DNS ISP mereka, tetapi server itu tidak akan menerima pertanyaan saya karena saya bukan pelanggan mereka. Server DNS di atas bersifat publik, jadi saya menggunakannya untuk menguji. Jika mereka salah konfigurasi, mereka salah konfigurasi dengan cara yang sama, dan tiba-tiba menjadi salah konfigurasi, karena ini tidak terjadi kemarin. Berikut adalah IP dari satu server DNS ISP pengguna kami: 177.86.168.11. Pengguna kami yang lain tidak cukup responsif atau cukup mahir untuk memberi kami IP server DNS mereka.

— Duncan Marshall

Bolehkah saya menyampaikan terima kasih yang sebesar-besarnya kepada poster asli karena memasukkan nama domain yang sebenarnya dalam pertanyaannya, alih-alih menyuntingnya? Seperti yang telah saya perhatikan sebelumnya , pertanyaan DNS adalah anggota kelas itu yang lebih mudah dijawab dengan cepat dan kanonik ketika penutupan penuh dilakukan, dan saya pribadi berpendapat bahwa kualitas jawaban yang sangat tinggi dari pertanyaan ini sebagian disebabkan oleh banyak bola mata bisa melihat langsung pada masalahnya.

— MadHatter mendukung Monica

Jawaban:

Drifter sudah benar, Anda memiliki masalah konfigurasi server nama. Inilah ujung dari output dari 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

Catatan lem Anda menunjuk ke alamat IP 199.168.117.67, yang mengembalikan respons yang benar. Namun zona Anda mendefinisikan catatan server nama yang berakhiran com.com. Jika kita +tracesalah satu dari server nama itu ...

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

... kita berakhir di nameserver yang dihosting AWS seseorang.

Masalah Anda adalah sesuatu yang dikenal sebagai ketidakcocokan rekaman lem . Server nama jarak jauh awalnya belajar tentang domain Anda melalui catatan lem, tetapi begitu server jarak jauh melakukan penyegaran, mereka akhirnya menanyakan server nama palsu yang telah Anda tentukan dengan tambahan .comdi bagian akhir.

Ini bukan satu-satunya masalah Anda. Anda mencantumkan alamat IP yang sama tiga kali dalam catatan lem Anda, yang sangat fluktuatif. Anda harus selalu memiliki beberapa nameserver, mereka tidak boleh berbagi subnet atau rekan jaringan hulu, dan mereka tidak boleh berada di lokasi fisik yang sama. Saat ini masalahnya, masalah perutean singkat antara server DNS dan server tunggal Anda akan menyebabkan domain Anda untuk sementara tidak dapat dijangkau.

Memperbarui:

T&J ini telah ditampilkan di halaman depan dan mendapat banyak komentar. Sayangnya, itu termasuk orang-orang yang sedikit terlalu bersemangat untuk menjawab jawaban ini tanpa memeriksa untuk melihat apakah poin mereka telah dibahas dalam komentar yang diperluas.

Detail yang tampaknya diabaikan sebagian besar orang adalah komentar yang saya kutip di sini:

[...] server DNS geo-redundan mencegah skenario di mana gangguan perutean singkat menghasilkan caching negatif sementara nameserver. Betapapun singkatnya periode caching negatif, hampir pasti akan melebihi jumlah waktu yang ada gangguan konektivitas. [...] jumlah skenario di mana kurangnya geo-redundansi DNS tidak akan membuat sporadis dan sulit untuk memecahkan masalah ketersediaan adalah nol.

Jika Anda pikir pemahaman saya tentang caching negatif nameserver salah, itu permainan terbuka untuk diskusi, tetapi di luar itu Anda perlu membawa sesuatu ke meja selain "itu adalah situs kecil dan siapa yang peduli jika situs web dan server DNS turun pada waktu bersamaan". Jika Anda mengatakan ini, Anda tidak memahami topik hampir sama baiknya dengan Anda.

Pembaruan Kedua:

Saya pergi ke depan dan menulis Tanya Jawab kanonik yang dapat kami tautkan kapan pun topik server DNS tunggal muncul di masa mendatang. Semoga ini bisa menyelesaikan masalah.

— Andrew B
sumber

Tidak masalah apa yang Anda lihat di panel kontrol, inilah kenyataannya. dig @199.168.117.67 grahamhancock.com NSmemperjelas ini secara eksplisit - bahwa data berasal dari server Anda. Adapun ini menjadi "masalah keuangan", saya akan menjadi tumpul di sini: jika Anda tidak akan menjalankan server DNS yang berlebihan, Anda sama sekali tidak punya bisnis yang mengoperasikan DNS Anda sendiri. Anda akan mengalami downtime. Kecuali jika Anda sangat dekat dengan pemilik, Anda akan bertanggung jawab atas waktu henti itu dan memungkinkan konfigurasi ini diterapkan.

— Andrew B

Aku mendengarmu, tapi itu keluar dari tanganku. Bagaimanapun, terima kasih atas bantuannya.

— Duncan Marshall

@ Bromo Cukup adil. Yang mengatakan, Anda masih mengabaikan fakta bahwa server DNS geo-redundan mencegah skenario di mana gangguan routing singkat menghasilkan caching negatif sementara nameserver. Betapapun singkatnya periode caching negatif, hampir pasti akan melebihi jumlah waktu yang ada gangguan konektivitas. (atau untuk membuatnya lebih sederhana karena saya tidak dapat terus membalas ini: "bla bla bla DNS bla, jumlah skenario di mana kurangnya geo-redundansi DNS tidak akan membuat sporadis dan sulit untuk memecahkan masalah ketersediaan sama dengan nol" .)

— Andrew B

Anda bisa mendapatkan hosting DNS sebesar $ 1 dengan server NS yang berlebihan. Itu bukan pilihan finansial. Jangan menjadi koboi.

— JamesRyan

Ada banyak penyedia DNS sekunder gratis yang memadai untuk zona beban rendah. Atau seperti kata @JamesRyan di atas satu dapat membayar jumlah (sangat kecil) uang untuk layanan yang dikelola secara profesional dengan beberapa jenis SLA. Keduanya merupakan alternatif yang layak untuk situs dengan lalu lintas rendah.

— CVn

Menggunakan alat-alat berikut memberi beberapa petunjuk

https://www.whatsmydns.net/#NS/grahamhancock.commelaporkan bahwa NS mencatat pada titik domain untuk ns1.grahamhancock.com.commemperhatikan .com tambahan

http://mxtoolbox.com/SuperTool.aspx?action=dns%3agrahamhancock.com&run=toolpage juga melaporkan bahwa server nama yang sama melaporkan sebagai otoritatif.

Jika Anda melihat di sini, http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=grahamhancock.comitu juga melaporkan bahwa server nama Anda terbuka.

Jadi itu akan muncul di suatu tempat di sepanjang baris nameserver tidak diatur dengan benar. Jika mereka muncul dengan benar kepada Anda melalui panel kontrol dll, Anda harus berbicara dengan penyedia sehingga mereka dapat memeriksanya di server yang sebenarnya.

Tautan tersebut juga memiliki laporan lengkap tentang praktik terbaik dan cara menanganinya

— Drifter104
sumber

Dan parasit ^ H ^ H ^ H ^ H ^ H ^ H ^ H ^ H ^ Orang di com.comtelah mengkonfigurasi wildcard DNS untuk mengambil keuntungan dari kesalahan semacam ini. Jika catatan NS Anda menunjuk ke something.com.com mereka akan menjawab pertanyaan apa pun yang mereka dapatkan dengan cara yang mengarahkan lalu lintas ke mereka. Coba dig @anything.com.com anyotherthing.comdan periksa otoritas dan bagian tambahan dari balasan!