Apa perbedaan antara `dig` dan` host` saat menanyakan server nama tertentu?

Saya menggunakan perintah ini untuk memverifikasi apakah saya telah mengatur semuanya dengan benar dengan penyedia DNS:

host hostname.example.com ns1.example-nameserver.com

Sejauh yang saya tahu, ini meminta ns1.example-nameserver.comuntuk mencari hostname.example.comdan melaporkan jawabannya. Saya mendapat tanggapan dari tuan rumah, jadi saya pikir saya salah. Namun, tanpa menentukan nama-server mereka (sehingga memungkinkan nama-server saya ISP untuk mencarinya) saya mendapat respon yang benar ( hostnameadalah CNAMEjika itu penting). Saya tidak dapat memahami ini jadi saya mencari-cari dan menemukan digperintah:

dig @ns1.example-nameserver.com hostname.example.com

Sejauh yang saya tahu ini melakukan hal yang sama dengan hostperintah - meminta server nama tertentu untuk mencari host. Karena itu saya menyimpulkan bahwa mereka harus melakukannya secara berbeda, dan bahwa caching server nama harus menggunakan metode yang sama dig.

Kesimpulan saya benar atau salah, jika itu benar:

Apa perbedaan antara kedua metode pencarian ini?

Jika salah:

Apa kesalahpahaman saya tentang DNS dan hostdan digperintah yang membuat saya sampai pada kesimpulan ini?

Contoh output:

$ host cardiff.tzmchapters.org ns1.livedns.co.uk
Using domain server:
Name: ns1.livedns.co.uk
Address: 213.171.192.250#53
Aliases: 

Host cardiff.tzmchapters.org not found: 3(NXDOMAIN)

$ dig @ns1.livedns.co.uk cardiff.tzmchapters.org

; <<>> DiG 9.8.3-P1 <<>> @ns1.livedns.co.uk cardiff.tzmchapters.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23620
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;cardiff.tzmchapters.org.   IN  A

;; ANSWER SECTION:
cardiff.tzmchapters.org. 3600   IN  CNAME   ghs.google.com.

;; AUTHORITY SECTION:
google.com.     3600    IN  SOA ns1.livedns.co.uk. admin.google.com. 1354213742 10800 3600 604800 3600

;; Query time: 27 msec
;; SERVER: 213.171.192.250#53(213.171.192.250)
;; WHEN: Mon Apr 22 23:47:05 2013
;; MSG SIZE  rcvd: 128

— jhabbott
sumber

kedua perintah harus bekerja dengan cara yang sama dalam hal ini. Bisakah Anda menunjukkan hasil lengkap dari setiap perintah?

— Renan

Perhatikan bagaimana keduanya digdan hostmelaporkan NXDOMAIN. Dengan digAnda dapat melihatnya di header (baris 5 non-kosong dari output) dan dengan hostitu lebih jelas. NXDOMAINberarti domain tidak ada. Namun a CNAMEdikembalikan di bagian jawaban! Saya percaya itu adalah bug di server DNS!

— Celada

Jadi dalam hal ini, apakah digdan hostkeduanya mengirim paket permintaan yang sama persis, mendapatkan paket respon yang sama persis (selain dari cap waktu), tetapi menafsirkannya secara berbeda? Apakah hostbail out segera setelah dilihatnya NXDOMAIN?

— jhabbott

FWIW Saya memiliki masalah sebaliknya pada subdomain tertentu. Menggunakan host pada subdomain spesifik ini memberikan catatan yang diharapkan yang menunjukkan bahwa subdomain khusus ini memutuskan untuk menjadi hostname kanonik yang diharapkan. Namun, ketika menggunakan menggali di subdomain khusus ini - saya menerima respons bahwa catatan itu tidak ada. Selain itu menavigasi ke subdomain ini dengan browser tidak berfungsi. Saya sudah mencoba beberapa kali, memeriksa kesalahan pengejaan, dll. Perintahnya jelas TIDAK bekerja dengan cara yang sama.

— user12345

Jawaban:

host,, digdan nslookupsemua memiliki sebagian besar fungsi yang sama. Dalam hal ini Anda bertanya tentang (menanyakan pertanyaan DNS tertentu ke server nama tertentu), digdan host(dan memang nslookup) berperilaku sama persis.

Untuk pemecahan masalah DNS, diglebih disukai karena format outputnya lebih "mentah": dalam outputnya langsung menampilkan konten semua 4 bidang dalam respons DNS: pertanyaan, jawaban, otoritas, dan bagian tambahan (ditambah bendera di header) , dan juga memiliki lebih banyak opsi. host, di sisi lain, memiliki format output yang lebih ramah pengguna.

Jika Anda tidak membutuhkan opsi yang dimiliki salah satu perintah dan yang lainnya tidak, atau informasi yang dihasilkan salah satu dari mereka dan yang lainnya tidak, maka itu menjadi masalah preferensi.

— Celada
sumber

Jika mereka melakukan hal yang sama di sisi jaringan (permintaan aktual) bagaimana saya bisa mendapatkan host tidak ditemukan saat menggunakan hosttetapi jawaban yang benar ketika menggunakan dig? Bahkan jika server dikonfigurasi menggunakan pengaturan tertentu (baik karena pilihan atau kecelakaan) untuk menyebabkan ini, itu harus dapat membedakan permintaan.

— jhabbott

Nggak! Dua perintah yang Anda berikan dalam pertanyaan Anda setara dan mereka harus menghasilkan jawaban yang sama! Apakah Anda yakin itu digmemberi Anda jawaban aktual dan bukan catatan di bagian tambahan atau otoritas? Seperti yang disarankan Renan , mungkin membantu untuk menunjukkan hasilnya.

— Celada

Ok, saya sudah menambahkan beberapa contoh output. Saya mendapatkan hasil yang sama di rumah dan di tempat kerja. Ketika saya tidak menentukan server nama untuk digunakan dan ISP saya menangani permintaan, hostberfungsi dengan baik. Silakan coba sendiri dan beri tahu saya hasilnya.

— jhabbott

Hanya meninjau ini - ISP akhirnya mengatakan kepada saya bahwa server mereka dikonfigurasikan untuk tidak menanggapi permintaan klien langsung, hanya ke server nama lain yang meminta transfer informasi - apakah digpermintaan dengan cara yang berbeda, seperti yang dilakukan nameserver?

— jhabbott

dig dapat melakukan kedua pertanyaan reguler (semua tipe kecuali AXFR) dan transfer zona (tipe AXFR) tetapi operator DNS biasanya membatasi transfer zona ke budak resmi sehingga Anda kemungkinan besar ingin menggunakan pertanyaan reguler

— Celada

Jika Anda menggunakan nama host non-FQDN, hasilnya bisa berbeda karena hostakan menggunakan domain pencarian di resolv.conf, sedangkan digtidak secara default.

Anda harus menggunakan +searchopsi jika Anda ingin digmenggunakan resolv.conf(atau menambahkannya ~/.digrc).

Sebagai contoh:

$ host foo
foo.myfqdn.com has address 10.1.2.3

$ dig +short foo
# (no result)

$ dig +short +search foo
10.1.2.3

— wisbucky
sumber