[ DNS & domain ]

Catatan DNS A dan AAAA dalam konfigurasi layanan email

Periksa titik akhir email IPv4 dan IPv6 secara terpisah dan pahami kapan catatan alamat memengaruhi perutean atau SPF .

Oleh tim peneliti EmailAuth

[Poin-poin penting]

  • Publikasi alamat tidak membuktikan titik akhir SMTP berfungsi.
  • Uji setiap kelompok alamat yang diiklankan dan sumber eksternal aktual.
  • Pengeditan alamat dapat memengaruhi dependensi SPF a atau mx secara eksplisit.
Di halaman ini

Catatan A dan AAAA memetakan nama host ke alamat IPv4 dan IPv6 . Ini adalah dependensi dari layanan email, bukan pernyataan bahwa layanan tersebut siap atau diizinkan untuk dikirim. Menerbitkan alamat dapat memperlihatkan rute yang sebenarnya dicoba oleh klien, jadi verifikasi setiap kelompok dan titik akhir yang diiklankan.

Ikuti nama yang digunakan oleh protokol

Referensi: RFC 5321 §5.1, RFC 7208 §5.3, RFC 7208 §5.4.

Untuk SMTP masuk, selesaikan pertukaran nama host yang dikembalikan oleh MX . Alamat situs web domain penerima bukan merupakan pengganti ketika pertukaran eksplisit tidak dapat digunakan. Jika tidak ada MX , aturan MX implisit SMTP dapat membuat data A atau AAAA milik domain penerima menjadi relevan.

Untuk keluar SPF, memeriksa kebijakan aktual dan identitas yang dievaluasi. Sebuah a mekanisme dapat mengotorisasi alamat yang dikembalikan untuk nama yang ditentukan; sebuah dataran Sebuah rekor tidak mengizinkan apa pun dengan sendirinya. Begitu pula dengan mengubah nama host yang digunakan oleh SPF mx mekanisme dapat mengubah alamat yang dievaluasi sebagai resmi. Catat referensi ini sebelum menganggap pengeditan alamat DNS sebagai perubahan khusus situs web.

Perlakukan tumpukan ganda sebagai dua jalur operasi

Referensi: RFC 1035 §3.4.1, RFC 3596 §2.1, RFC 3596 §2.3.

Sebuah nama host dapat memiliki beberapa catatan A dan beberapa catatan AAAA. Kehadirannya tidak menjamin keterjangkauan, layanan SMTP , sertifikat yang benar, atau kebijakan serupa. Titik akhir IPv4 yang sehat tidak membuktikan bahwa IPv6 berfungsi. Sebaliknya, kegagalan pada satu jalur klien tidak membuktikan setiap pengirim menggunakan jalur tersebut.

Tangkap alamat tujuan yang sebenarnya dicoba, keluarga alamat, hasil koneksi, dan respons SMTP . Jika menyelidiki lalu lintas keluar, ambil alamat sumber yang diamati secara eksternal daripada berasumsi bahwa alamat tersebut cocok dengan alamat yang digunakan di dalam aplikasi. NAT dan kumpulan jalan keluar penyedia dapat membuat nilai-nilai tersebut berbeda.

Mereproduksi kesalahan keluarga alamat

Perlengkapan sintetis: example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com . AAAA 2001:db8::10. Di lab, konfigurasikan titik akhir IPv4 untuk menerima koneksi TCP pada port 25 dan biarkan titik akhir IPv6 tidak dapat dijangkau. Pemeriksaan DNS yang diharapkan berhasil untuk kedua jenis rekaman, sedangkan pengujian koneksi khusus keluarga hanya berhasil untuk IPv4 .

Pertanyaan gali @AUTH mx.example.com . A + tidak ada kutukan dan kemudian perintah yang sama dengan AAAA. Ganti AUTH dengan otoritas yang terisolasi. Catat kedua jawaban tersebut. Gunakan klien SMTP lab Anda yang disetujui untuk menyematkan setiap tujuan secara independen, mencatat hasil koneksi dan protokol. Perlengkapan tersebut menggambarkan mengapa kesuksesan DNS bukanlah kesuksesan layanan; ia tidak membuat klaim tentang waktu mundur pengirim tertentu.

Perlengkapan kedua hanya mengubah alamat A 192.0.2.10 ke 192.0.2.20 sedangkan kebijakan SPF adalah v=spf1 a:mx.example.com -all. Untuk evaluasi SPF IPv4 dengan pencarian yang berhasil, alamat memenuhi syarat untuk cocok dengan a perubahan mekanisme. Eksplisit ip4:192.0.2.10 mekanisme tersebut akan tetap terikat pada jaringan literal tersebut sampai kebijakan itu sendiri berubah.

Jadikan perubahan alamat dapat dibalik

Referensi: RFC 8767 §4.

Inventarisasi semua konsumen nama host, termasuk perutean email, referensi SPF , pemantauan, dan ekspektasi sertifikat. Siapkan titik akhir sebelum mengiklankannya. Pertahankan layanan lama selagi cache yang sesuai masih dapat mengarahkan lalu lintas ke sana, berdasarkan rencana migrasi sebenarnya dan bukan pada masa tunggu universal.

Setelah perubahan, bandingkan jawaban otoritatif dengan observasi rekursif dan bukti tingkat pesan. Titik akhir IPv6 yang gagal harus diperbaiki atau dihapus melalui perubahan yang disetujui, bukan disembunyikan dengan melemahkan kebijakan autentikasi yang tidak terkait. Tutup pekerjaan hanya jika alamat yang dituju dan jalur operasi sesuai dengan desain layanan yang terdokumentasi.

Usahakan ruang lingkup bukti tetap eksplisit

Untuk skenario dua kelompok, pertahankan keberhasilan IPv4 dan kegagalan IPv6 yang diharapkan sesuai usulan pengamatan laboratorium hingga diuji. Contoh perubahan alamat SPF mengasumsikan pencarian berhasil dan kebijakan yang dinyatakan; itu tidak menetapkan otorisasi saat ini untuk pengirim sebenarnya.

[ Membawa pergi ]

Publikasi alamat tidak membuktikan titik akhir SMTP berfungsi. Uji setiap kelompok alamat yang diiklankan dan sumber eksternal aktual. Pengeditan alamat dapat memengaruhi dependensi SPF a atau mx secara eksplisit.

[ Berdasarkan peran ]

Apa artinya ini bagi Anda

Pilih peran Anda untuk langkah praktis selanjutnya.

Admin TI / Surat

Uji setiap alamat yang diiklankan

Resolusi DNS yang berhasil dan titik akhir SMTP operasional adalah pengamatan yang berbeda.

Langkah selanjutnya

  1. Kueri A dan AAAA secara independen.
  2. Uji setiap titik akhir SMTP yang diiklankan.
  3. Ketergantungan SPF inventaris sebelum pengeditan alamat.

CISO / Detik

Tinjau izin alamat tidak langsung

Perubahan pada nama host bersama dapat mengubah perilaku SPF ketika kebijakan mereferensikan nama tersebut.

Langkah selanjutnya

  1. Tinjau paparan IPv6 yang belum teruji.
  2. Verifikasi identitas jalan keluar yang diamati secara eksternal.
  3. Pisahkan temuan pengangkutan dan autentikasi.

Pendiri / Non-teknis

Miliki kedua keluarga jaringan

Periklanan IPv6 menciptakan ketergantungan operasi bersamaan dengan layanan IPv4 yang sudah dikenal.

Langkah selanjutnya

  1. Danai kedua jalur jaringan yang diiklankan.
  2. Tetapkan kepemilikan untuk nama host bersama.
  3. Memerlukan bukti penerimaan migrasi.

[ FAQ ]

Pertanyaan yang sering diajukan

Apa yang dimaksud dengan toko A?

Alamat IPv4 .

RFC 1035 §3.4.1

Apa yang disimpan AAAA?

Alamat IPv6 .

RFC 3596 §2.1

Apakah AAAA membuktikan SMTP IPv6 berfungsi?

Tidak. Menguji keterjangkauan dan perilaku SMTP secara mandiri.

Bisakah beberapa alamat dikembalikan?

Ya. Periksa setiap alamat yang diiklankan, bukan hanya alamat pertama.

RFC 3596 §2.3

Apakah editan A mengubah SPF ?

Hal ini dapat terjadi ketika kebijakan SPF yang dievaluasi merujuk pada nama tersebut melalui mekanisme yang bergantung pada alamat.

RFC 7208 §5.3 RFC 7208 §5.4

Haruskah saya memeriksa apex A untuk surat masuk?

Mulailah dengan target MX ketika ada MX eksplisit; puncaknya mungkin penting dalam fallback MX implisit.

RFC 5321 §5.1

Apakah IP server pribadi merupakan IP pengirim?

Belum tentu. Catat alamat sumber publik yang diamati pada jalur keluar sebenarnya.

Apakah koneksi membuktikan pengiriman kotak masuk?

Tidak. Koneksi, penerimaan SMTP , dan penempatan kotak surat akhir merupakan pengamatan terpisah.

RFC 5321 §4.2.5

[ Sumber ]

Sumber

  1. RFC 7208

    Bagian §5.3 · §5.4

  2. RFC 1035

    Bagian §3.4.1

  3. RFC 5321

    Bagian §4.2.5 · §5.1

  4. RFC 8767

    Bagian §4

  5. RFC 3596

    Bagian §2.1 · §2.3

  6. Referensi penggalian ISC BIND

    Bagian Sintaks, -x pencarian terbalik, opsi kueri norecurse

[ Glosarium ]

Glosarium

rekor AAAA
Catatan DNS yang menyimpan satu alamat IPv6 .

RFC 3596 §2.1

SPF yang bergantung pada alamat
Mekanisme SPF seperti a dan mx menggunakan data alamat DNS selama evaluasi, bukan kebijakan IP literal tetap saja.

RFC 7208 §5.3 RFC 7208 §5.4

Asal perusahaan

Mengapa lembaga keuangan dan pemerintah terkemuka menghentikan dasbor keamanan email mereka.

Platform autentikasi email tradisional menjual dasbor kepada Anda dan meminta teknisi Anda melakukan pekerjaannya. Di lingkungan berisiko tinggi, pengawasan manual berarti penegakan yang tertunda, penyimpangan konfigurasi, dan domain bayangan yang tidak dipantau.

EmailAuth adalah platform asal email agen. Agen kami menegakkan p=reject, jaga agar pengirim pihak ketiga tetap selaras dan pindahkan domain Anda ke kapasitas penuh RFC 9989 kepatuhan, standar DMARC baru, dengan kemampuan audit yang dapat dilakukan secara langsung oleh manusia.

Pemerintah Perusahaan besar Lembaga keuangan tingkat 1

SaaS · Penyewaan khusus · On-prem dengan celah udara · Enkripsi BYOK

Basis Pengetahuan