Apakah benar server nama harus menjawab pertanyaan melalui TCP?

23

Saya proses pengaturan pemantauan server DNS dari beberapa host web besar. Tujuan saya adalah membandingkan waktu respons server dns dengan melacak respons mereka terhadap ping.

Dalam prosesnya, saya menemukan bahwa server nama Bluehost tidak menanggapi ping. Saya mencoba untuk mendapatkan informasi lebih lanjut dengan menjalankan Pingdom DNS Check di bluehost.com dan menghasilkan kesalahan berikut:

Server nama ns1.bluehost.com (74.220.195.31) tidak menjawab pertanyaan melalui TCP.

Server nama gagal menjawab pertanyaan yang dikirim melalui TCP. Ini mungkin karena server nama tidak diatur dengan benar atau karena pemfilteran yang salah konfigurasi di firewall. Ini adalah kesalahpahaman yang agak umum bahwa DNS tidak perlu TCP kecuali mereka memberikan transfer zona - mungkin administrator nama server tidak menyadari bahwa TCP biasanya merupakan persyaratan.

Saya ingin tahu yang berikut:

Sejauh mana pernyataan di atas benar?
Apa implikasi server nama yang tidak menjawab pertanyaan melalui TCP?

domain-name-system nameserver

— Taras Mankovski
sumber

47

Teks diagnostik dari Pingdom persis benar. TCP tidak hanya untuk transfer zona.

Implementasi server DNS yang sekarang "diperlukan" (dalam begitu banyak sebagai salah RFC memerlukan sesuatu) untuk mendukung TCP, per RFC 5966 , "DNS Transportasi melalui TCP - Persyaratan Implementasi".

Perhatikan bahwa ini adalah persyaratan pada implementasi perangkat lunak server, itu tidak secara ketat berlaku untuk operasi server apa pun - praktik operasional tidak tercakup.

Yang mengatakan, jika server DNS khusus Anda tidak dikonfigurasi untuk mendukung TCP, atau jika diblokir, maka efek jangka panjang akan menjadi ketidakmampuan untuk mendukung DNSSEC dengan benar. Demikian pula data DNS lainnya yang menyebabkan respons melebihi 512 byte mungkin diblokir.

ob disclaimer: Saya menulis RFC itu.

EDIT RFC 5966 sekarang telah digantikan oleh RFC 7766

— Alnitak
sumber

RE: praktik operasional, orang yang membenci DNSSEC dapat dengan mudah menonaktifkan TCP dan menjatuhkannya di firewall untuk mengukur dengan baik. Tidak mengherankan, ada konsekuensi. Tidak ada jumlah dukungan untuk EDNS0 di dua titik akhir dapat memaksa perangkat di antara mereka untuk tidak ikut campur dalam beberapa cara. (fragmentasi, penandaan salah oleh firewall kuno, dll.) Jika Anda memiliki catatan DNS besar di server auth (TXT kembung), TCP akan diperlukan jika Anda tidak ingin mengecualikan segmen audiens Anda. Demikian juga, menonaktifkannya di server rekursif mengisolasi Anda dari DNS menjawab bahwa cluster email Anda mungkin perlu berurusan dengan spam.

— Andrew B

3

harus mendukung TCP dan UDP - TCP untuk ukuran tanggapan> 512 byte (yang akan mencakup transfer zona) (menurut hal-hal yang saya baca, bagaimanapun. Saya biasanya mengaktifkan TCP dan UDP untuk NS yang saya jalankan ...)

— Mark Regensberg
sumber

-2

Adalah baik untuk mengetahui apa yang dikatakan RFC tentang masalah ini, dan kami sudah memiliki jawaban otoritatif yang bagus tentang hal itu, tetapi untuk tujuan praktis, saya menemukan saran dari Prof. Daniel J. Bernstein, PhD, penulis DJBDNS, cukup menghibur.

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

Kapan permintaan TCP dikirim?

Jika Anda berada dalam salah satu situasi berikut, Anda perlu mengonfigurasi server DNS Anda untuk menjawab pertanyaan TCP:

Anda ingin menerbitkan kumpulan catatan yang lebih besar dari 512 byte. (Ini hampir selalu merupakan kesalahan.)

Anda ingin mengizinkan transfer zona keluar, misalnya ke server pihak ketiga.

Server induk menolak untuk mendelegasikan nama kepada Anda sampai Anda mengatur layanan TCP.

Jika Anda tidak berada dalam situasi itu, Anda tidak perlu menyediakan layanan TCP, dan Anda tidak perlu mengaturnya. DNS-over-TCP jauh lebih lambat daripada DNS-over-UDP dan secara inheren jauh lebih rentan terhadap serangan penolakan layanan. (Ini juga berlaku untuk BIND.)

Perhatikan bahwa ia tidak menyebutkan DNSSEC secara eksplisit; alasannya adalah bahwa, menurut DJB, DNSSEC termasuk dalam kategori "selalu kesalahan". Lihat https://cr.yp.to/djbdns/forgery.html untuk lebih jelasnya. DJB memiliki standar alternatif, yang disebut DNSCurve - http://dnscurve.org/ - yang telah diadopsi secara independen oleh beberapa penyedia (seperti OpenDNS). Yang menarik: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption .

Perhatikan bahwa jika dokumentasi di atas pada pengaturan DJBDNS adalah indikasi dari fitur-fiturnya, tampaknya hanya mendukung AXFR untuk TCP. Karena banyak penyedia masih menggunakan DJBDNS, mereka tidak akan mungkin mendukung DNS melalui TCP tanpa upaya ekstra.

PS Perhatikan bahwa DJB sebenarnya mempraktekkan apa yang dia khotbahkan. Servernya sendiri, (1), jalankan DNSCurve, (2), tidak menjawab TCP dengan benar. Hanya yang +notcpakan berhasil (yang default):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

, sedangkan a +tcpakan gagal (tampaknya dengan pesan kesalahan yang berbeda, tergantung pada server mana yang dipilih):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

— cnst
sumber

2

Tindakan DJB fanboi Anda semakin memakainya. Komunitas DNS telah memilih DNSSEC, dan banyak literatur tentang DNSCurve sepenuhnya mengonfigurasi persyaratan ortogonal keaslian data dan enkripsi data . IMNSHO, sebagian besar jawaban Anda tidak berkontribusi apa pun untuk pertanyaan ini.

— Alnitak

@Alnitak, desakan Anda bahwa TCP diperlukan untuk DNS tidak menjadikannya persyaratan aktual untuk DNS. Jelas banyak orang berjalan tanpa TCP, dan tidak mengalami masalah APA SAJA dengan ketersediaan situs web mereka sendiri. Namun Anda terus mempromosikan informasi yang salah dan FUD.

— cnst

2

Apakah dokumen itu benar-benar dari tahun 2003? Bagaimana Anda bisa mengklaim dengan wajah lurus bahwa itu masih relevan di tahun 2017?

— Michael Hampton

1

@MichaelHampton, ya, dengan sepenuh hati dan mutlak. Beberapa hal tidak berubah, dan DJB mungkin brengsek, tapi dia cukup pintar. Semua argumen yang dikemukakannya bersifat filosofis, dan tidak berubah seperti teknologi. Sementara itu, (1), mengapa sangat sulit untuk percaya, (2), mengapa menghubungkan ke RFC yang lebih tua dilakukan dengan wajah lurus, dan tanpa Anda menjadi seorang munafik, (3), apa argumen sebenarnya yang Anda miliki selain kencan"? Orang-orang terus mengatakan bahwa caranya memiliki masalah interoperabilitas, namun argumen yang diajukan (misalnya, bouncing mail) dia terbantahkan pada tahun 2003!

— cnst

-5

TCP hanya diperlukan, dan biasanya hanya digunakan ketika dibutuhkan respons yang panjang. Bisa ada dampak negatif. Transfer zona dilakukan melalui TCP karena besar, dan harus dapat diandalkan. Tidak mengizinkan TCP dari server yang tidak dipercaya adalah salah satu cara untuk memastikan bahwa hanya jawaban kecil yang diberikan.

Dengan diperkenalkannya jawaban DNS yang ditandatangani, telah ada persyaratan untuk melonggarkan batas 512 byte ke jawaban UPD. EDNS0 menyediakan mekanisme untuk tanggapan UDP yang lebih lama. Kegagalan untuk mengizinkan DNS melalui TCP kemungkinan besar akan merusak implementasi DNS yang aman.

Sangat mungkin untuk menjalankan server DNS yang hanya memiliki port UDP 53 terbuka ke Internet. Diperlukan akses TCP ke rekan-rekan DNS, tetapi ini adalah sejumlah kecil host.

Ada RFC596 baru yang sekarang membutuhkan TCP untuk implementasi DNS lengkap. Ini ditujukan untuk pelaksana. Dokumen-dokumen secara khusus tidak membahas operator, tetapi memperingatkan bahwa tidak memungkinkan TCP dapat menghasilkan sejumlah skenario kegagalan. Ini merinci berbagai kegagalan yang dapat terjadi jika DNS over TCP tidak didukung.

Telah ada diskusi tentang penggunaan TCP untuk mencegah serangan amplifikasi DNS. TCP memiliki risiko penolakan layanan, tetapi distribusi lebih sulit.

— BillThor
sumber

DNSSEC tidak melonggarkan batas, EDNS0 lakukan, pada tahun 1999 (lihat RFC 2671).

— Alnitak

Tidak, seperti yang dijelaskan oleh Alnitak, TCP diperlukan dalam banyak kasus (kecuali jika Anda benar-benar yakin bahwa Anda tidak akan pernah memiliki balasan> 512 byte, sesuatu yang biasanya tidak Anda ketahui sebelumnya)

— bortzmeyer

Saya telah berhasil menjalankan DNS melalui firewall yang hanya mengizinkan UDP. Kecuali konfigurasi pathalogical, pencarian alamat akan di bawah 512 karakter. Saya telah melihat referensi bahwa jalur DNS dibatasi hingga 256 karakter. Bukti dalam database untuk server surat saya menunjukkan bahwa jalur DNS server jarang melebihi 100 karakter, dan situs yang memiliki beberapa nama yang dikembalikan oleh catatan PTR jarang mengulang lebih dari 256 karakter. Semua tanggapan ini akan berjalan di UDP. Adakah yang punya case wajar yang berjalan di dekat 512 karakter tanpa DNSSEC atau transfer zona.

— BillThor

Kembali DNSSEC, saya tidak memverifikasi RFC untuk ukuran yang diperluas, tetapi satu-satunya referensi yang saya lihat menggunakan ukuran paket yang diperluas pada UDP memiliki ben DSNSEC.

— BillThor

Salah satu penyedia konten besar terhenti beberapa tahun yang lalu ketika mereka menambahkan begitu banyak catatan A untuk salah satu pertanian web mereka yang melebihi 512 byte. Itu menyebabkan masalah interop nyata.

— Alnitak