はじめに 本記事は、QiitaのDNS Advent Calendar 2024に参加させて頂いております。 今回の記事では、DNSのトラブルシュートや運用周り等でも利用できるような、Web上で公開されているツール中心に、個人的に良く使っている・使っていたツールを備忘録も込めて残しておきたいと思います。有料プラン等が存在する物もありますが、無料でも使えるものを掲載しています。また、具体的な使い方というよりは、ツールの簡単なおススメ用途を交えて紹介する程度になります。 私自身はセキュリティ専門業ではないですが、Shodanやcensysなども業務で使ってた事があるのですが、セキュリティ関連の方々も紹介するサイトを組み合わせて使える(というか恐らく既知)ものもあるかもしれません。 なお、ツールの利用にあたっては、基本的に自分の管理しているドメインの調査などでのみでの利用が推奨されます。 今回の
mxcheckは、Kali Linux 2024.3 リリース時に追加されたツールです。 mxcheckとは mxcheckはコマンドラインツールです。mxcheckはすべてのMXエントリを照会し、さらに DNS情報を収集します。その後、ポートスキャンを開始し、サーバーフラグを読み取り、ホスト名をPTRエントリ、StartTLS、および証明書の有効性と比較します。また、VRFYコマンドをサポートすることで、サーバーが情報を漏らしていないかどうかもチェックします。 機能 mxcheck は電子メール サーバーの情報スキャナーであり、次の項目をチェックします。 ・DNSレコード A、MX、PTR、SPF、MTA-SS、DKIM、DMARC ・AS番号とAS国 ・StartTLSのサポートと証明書 ・オープンポート 25, 465, 587 ・サービスがブラックリストに掲載されているか ・サーバ
ソフトウェア開発における「パーフェクトな意思決定」/Perfect Decision-Making in Software Development
Gmailが「メール送信者のガイドライン」を改訂し、なりすましメールへの対策を強化する旨を発表しています。今までは原則、なりすましメール対策の有無にかかわらず、メールはいちおうは届いていました。しかし今後は、なりすましとみなされたメールは届かなくなる方向に向かいつつあります。 なりすましメールとみなされないようにするために、メール送信者には、「メール送信ドメイン認証」への対応が求められます。メール送信ドメイン認証の技術には、主に以下の3つがあります。 SPF: Sender Policy Framework (RFC 7208) DKIM: DomainKeys Identified Mail (RFC 6376) DMARC: Domain-based Message Authentication, Reporting, and Conformance (RFC 7489) SPFは従来
メールシステム担当の人はもちろん、インフラ担当の人もDNSの設定とかで既に知ってはると思いますが、 10月にGoogleが発表した2024年2月から始まるGmailとYahoo!(米国)におけるスパム対策強化のあれです。 海外では数年前から"No Auth, No Entry"って「代表なくして課税なし」みたいな感じで言われているアレです。 識者の方々がいろんなところで記事にしてはりますので、他のところであんまり書かれていない気がするとこだけ記します。 まずは公式情報 Google Googleについては以下の二ヶ所を読んで理解して実践しておけば大丈夫そうです、たぶん。 パラメーターのhl=enをhl=jaに変えると日本語版になりますが、更新されるのが遅いので最初に英語版を見ておくのが良いです。 Email Sender Guidelines(81126) Email Sender Gui
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※この投稿について 前半でIPレピュテーションとは何か？という説明をしていますので、未読の方は一読することをお勧めします。 メールというインターネットの闇とIPレピュテーション（だけど重要）(前編) https://qiita.com/nfujita55a/items/5848fcfbbe6cbf7d98c3 この後半では、IPレピュテーションをよくしてメールを滞りなく送りたいときの光要素と闇要素を、光→闇の順に書いています。 メールを円滑に送るためIPレピュテーションを高めたい、何ができるの（光要素） まずは、IPレピュテーションを含
ドメインを取得後にそれを使ったメールアドレスで送信できるようになったが、受信先でそのメールが迷惑フォルダへ分類されることがある。 会社では Google Domain でドメインを取得後、Google Workspace を利用してメールを送信できるようになった。DNS の管理は Cloud DNS を利用していて、その設定は Terraform を用いて管理している。 当初の設定はシンプルなものであった。 DNS ゾーンを設定 設定したゾーンに対して MX レコードを設定 resource "google_dns_managed_zone" "example_com_domain" { name = "example-com" dns_name = "example.com." } # https://support.google.com/a/answer/9222085 resourc
完全に私事なんですが、先日、某所からGoogle Cloud DNSにDNSサーバを移しました。 何も考えずにコピペしてたんですが、ある日、SPFレコードが無効になっている事に気付き… SPFレコードが無効に？ 私が書いていたのはこんなレコードv=spf1 include:_spf.google.com ~allだったはずでしたが、何故か"v=spf1" "include:_spf.google.com" "~all"という感じになっていました。 原因はコレ、スペースを含む場合はダブルクォートで囲む必要があるのですが、Google Cloud DNSの場合、なんともお節介な位置に勝手にダブルクォートを入れられていました… ちなみに、Google Cloud DNSだと"v=spf1 include:_spf.google.com ~all"が正解です。 というわけで、未然に防ぐために DN
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
