使用していないドメインを勝手に名乗ってメールを送信されるのを防ぐためのDNS設定まとめ
メールを送る際、「送信元」欄にはどんな内容でも記入することが可能なため、簡単に他人になりすますことができます。誰かが自分の所有しているドメインになりすましてメールを送った時、受信者にそのメールが「なりすましメール」であることを伝えるためのDNS設定についてエンジニアのヴィヴェク・ガイト氏が解説しています。 DNS settings to avoid email spoofing and phishing for unused domain - nixCraft https://www.cyberciti.biz/security/dns-settings-to-avoid-email-spoofing-and-phishing-for-unused-domain/ ガイト氏の解説は「メールを使用していないドメイン」を対象に、「そのドメインがメールを送信しないこと」および「もしそのドメインか
DNSド素人がdigコマンドとRoute 53を使って、DNSについてあれこれ学んでみた | DevelopersIO
試しに、digコマンドを利用して、yahoo.co.jpに名前解決してみましょう。 $ dig yahoo.co.jp ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.56.amzn1 <<>> yahoo.co.jp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57517 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;yahoo.co.jp. IN A ;; ANSWER SECTION: yahoo.co.jp. 60 IN A 182.22.59.229 yahoo.co.jp.
モダンなDNSの構成：IIJ DNSプラットフォームサービスのスゴいところ(第1回) | IIJ Engineers Blog
はじめに 先日、「IIJ DNSプラットフォームサービス」という新たな権威DNSサービスをリリースしました。プレスリリースはこちら。 そしたら、どーまえさんから「新サービスでやってるスゴいことについて記事書いてよ、それも主なものだけかいつまんで紹介するんじゃなくて細かいところまで全部！」とリクエストされました。「え、まじで全部書くんすか？！むっちゃ多いっすよ──。」 IIJのDNSサービスはかなり頑張ってるつもりですが、うちだけじゃなく、同業他社さんや、あるいは自前でDNSサーバを構築運用している企業さんにも頑張ってもらいたいんですよね。営業の立場からすると「ぜんぶIIJに任せてくれや」となるんでしょうけれど、売り文句にマルチプロバイダとあるように、IIJ単独じゃなくて複数のDNS事業者で同じゾーンを持つことで耐障害性を高めよう、ということも今回のサービスのポイントなのです。 IIJのサー
ドロップキャッチを悪用したTwitterのっとりについてまとめてみた - piyolog
2019年8月10日、DIANNAプロジェクトは同社が運営する公式Twitterアカウントが不正ログインされたと発表しました。不正アクセスの詳細については発表されていませんが、SNS上の投稿等からドロップキャッチを悪用しアカウント奪取が行われた可能性があります。ここでは関連する情報をまとめます。 被害の状況 diannaproject.jp 応援して下さっている皆様へ いつも応援ありがとうございます。 のっとり、なりすましの件は警察、IT弁護士に相談致しました。 それでも親として不安は強く東京遠征後の活動について今娘と話し合いの最中です。 答えが出るまではSNSをお休みさせて頂きます。 ゆうか母 pic.twitter.com/AF4usYFTD9— ゆうか (@DP_YUUKAA) August 9, 2019 DIANNAプロジェクトからの公式発表によれば次の被害を受けたとみられる。
DNSフラグメント攻撃の権威サーバ側の対策について
dnsfragattack_authserver.md DNSフラグメント攻撃に対する権威サーバ側の緩和策について TL;DR 緩和策が有効となる権威サーバとLinuxカーネルの組み合わせ RHEL/CentOSでも緩和策を有効にしたい 背景 DNSフラグメント攻撃についてはこちらを参照されたい。 IP fragmentation attack on DNS ここで、権威サーバからの応答を強制的かつ攻撃者の任意の位置でフラグメントさせるために、攻撃者が偽のICMPv4 type 3 code 4 (destination Unreachable, fragmentation needed and DF set、以下簡単に ICMPv4 Packet TooBig) を権威サーバに投げつけることが攻撃成立の一つの要素となっている 。厳密にはそうでないケースもあるが、現時点で知られている限りほ
インターノット崩壊論者の独り言 - 手と手が離れて... - GMOペパボに統合されたドメインが乗っ取り可能だった件
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させて頂いております。 GMOペパボのハンドメイドマーケット minne に統合された tetote が使用していたドメイン名 tetote-market.jp が長らく乗っ取り可能な状態にありましたがようやく対策されました。 Domain Information: [ドメイン情報] [Domain Name] TETOTE-MARKET.JP [登録者名] OCアイランド株式会社 [Registrant] OC Island Inc. [Name Server] uns01.lolipop.jp [Name Server] uns02.lolipop.jp [Signing Key] [登録年月日] 2011/03/30 [有効期限] 2020/03/31
DNS over HTTPSの必要性について - Qiita
なぜ今までのDNSでは問題があるのか インターネット上の通信の多くは、ブラウザを利用したウェブによるものです。 セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。 しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。 それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは 今までDNSサーバ（フルリゾルバ）の（主に）UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ
DNSで浸透って言っちゃだめなの？ - tmtms のメモ
別に言ってもいいよ。 以下想定問答。 「浸透が何を意味しているのかわからない」 ホント？ 「浸透いうな」って言われてるってことは、逆に言うとそれなりに広く使われてるってことでしょ。 個人的には「DNSの設定を変更した後、徐々に新しい情報を見ることができるクライアントが増えていく」ことだと思ってるんだけど、これとは異なる意味で使われてたりするの？ 「"浸透に数週間かかる" なんて言うのはへぼい業者の言い訳」 それは同感だけど、「浸透」という単語の問題じゃないよね。 「浸透」という単語を使わなくてもその業者はへぼいままで、数週間かかるのは変わらない。 数週間じゃなくて、「浸透には5分くらいかかります」だったらOK? 「設定ミスってるくせに浸透に時間がかかるなんて言い訳するな」ならわかるけど、「浸透という単語を使うな」はおかしいと思う。「浸透」を使わないことで何か解決するの？ 「浸透なんて用語は
GitHub - StackExchange/dnscontrol: Infrastructure as code for DNS!
DNSControl is a system for maintaining DNS zones. It has two parts: a domain specific language (DSL) for describing DNS zones plus software that processes the DSL and pushes the resulting zones to DNS providers such as Route53, Cloudflare, and Gandi. It can send the same DNS records to multiple providers. It even generates the most beautiful BIND zone files ever. It runs anywhere Go runs (Linux, m
DNSが使えなくなるトラブル、9月19日に発生する恐れ
DNS（Domain Name System）は、インターネットの名前解決を担う重要なシステムだ。ところが、2017年9月19日にDNSのトラブルが発生する恐れが浮上している。そのキーになるのが「DNSSEC」（DNS SECurity extensions）という技術だ。 DNSSECは、DNSの安全性を高める技術である。電子署名を利用してDNSから送られているデータの信頼性を検証することで、送信元の偽装を見抜く。日本での普及率は1割程度だが、8割以上普及している国もある。 DNSSECは公開鍵暗号方式を利用する。ドメインの管理単位であるゾーンに署名するゾーン署名鍵の「ZSK」（Zone Signing Key）と、ZSKに署名する鍵署名鍵である「KSK」（Key Signing Key）の2種類の鍵を使う。DNSの委任の仕組みを利用し、ルートサーバー（ルートゾーン）を頂点として、上位の
メールを受け取らないドメイン名に
example.comゾーンには次の内容で登録されているものとします。 example.com. 86400 IN A 192.0.2.80 送信側メールサーバは次のような順番で処理を行います。 宛先メールアドレス"foo@example.com"のドメイン名"example.com"に対するMXレコードを問い合わせる。 "example.com"に対する回答として0個のMXレコードを受け取る。（MXレコードが登録されていないため。なお、"example.com"そのものは存在するため、回答のステータスとしては"NOERROR"である。） "example.com"に対するAレコードを問い合わせる。（MXレコードが存在しないときには、Aレコードにフォールバックするため） "example.com"に対する回答としてIPアドレス"192.0.2.80"を値とするAレコードを受け取る。 IPア
Google Public DNS over HTTPS を試す | IIJ Engineers Blog
【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
遠隔操作ウイルスの制御にDNSプロトコルを使用する事案への注意喚起 | セキュリティ対策のラック
経緯と概要 当社が運営する緊急対応サービス「サイバー119」は、昨年の後半より複数の大手企業様より遠隔操作ウイルスに関連する対応要請を受け、調査を行ってまいりました。 これらの事案で発見された遠隔操作ウイルスを調査したところ、攻撃者がインターネット側から企業内ネットワークで動作する遠隔操作ウイルスを操る際に、DNSプロトコルを使用するDNSトンネリングとも言われる手口を利用していることが確認されました。 これまでの代表的な遠隔操作ウイルスにおいては、Web閲覧で用いられるHTTP（S）プロトコルを使用し、Webサーバを模した指令サーバを使用しています。しかしながら今回はDNSサーバを模した指令サーバを構築していることが確認されました。 図1：Web閲覧におけるDNSの動き DNSプロトコルはインターネットにおいて、ドメイン名（FQDN）からIPアドレスなどの情報を得るためにDNSサーバとの
h.root-servers.net（H-Root）のIPアドレス変更に伴う設定変更について
--------------------------------------------------------------------- ■h.root-servers.net（H-Root）のIPアドレス変更に伴う設定変更について 株式会社日本レジストリサービス（JPRS） 初版作成 2015/12/02（Wed） --------------------------------------------------------------------- ▼概要 2015年12月1日（協定世界時）、ルートサーバーの一つである h.root-servers.net（H-Root）のIPv4/IPv6アドレスが変更されました。 旧IPv4アドレス: 128.63.2.53 新IPv4アドレス: 198.97.190.53 旧IPv6アドレス: 2001:500:1::803f:235 新IP
インターノット崩壊論者の独り言 - 日本のドメイン名ガバナンスが変わる? - 平成27年4月3日国会提出 電気通信事業法等の一部を改正する法律案
最近の日記 2018-11-04 1. Unbound を安全にしよう 2018-10-31 1. これを NSEC/NSEC3 Replacement Attack と呼ぶのはどうだろう? 2018-08-27 1. DNS 温泉 5 無事終了 2018-04-08 1. 8.8.8.8 に加え 1.1.1.1 を用いたアクセスも拒否させて頂きます。 2017-12-13 1. 子供たちに知っておいて欲しい話がある。 2017-09-18 1. DNS 温泉 4 無事終了 2017-08-07 1. DNSSEC に関する一連の注意喚起で混乱中の皆様へ 2017-07-31 1. こういう DNSSEC 推進おかしくないですか? 2017-03-11 1. とりあえず学ぶべき IPv6 関連 RFC をリストアップしてみた 2016-12-21 1. EXFORMATION 2016-0
CloudFlareのCNAME FlatteningをGitHub Pagesで使ってみた - hnwの日記
(03/04 08:15 追記)今回のDNS設定変更でGitHub Pagesで提供しているCDNが使えるようになったことを追記しました。 今回はDNS方面の話題です。僕ははてなダイアリー以外にhttp://hnw.jp/という古めかしいサイトも管理しています。サイトの実体はGitHub Pagesで、これまでAWSのRoute 53でカスタムドメインの設定をしていました。 ところで、このサイトが2月の頭から1ヶ月ほど見えなくなっていました。原因は僕がGitHubからのメールを読み飛ばしており、DNS設定の変更を怠っていたためです。これに懲りて、今後DNS設定を二度といじらなくて済むようRoute 53からCloudFlareに引っ越してみました。その顛末を紹介します。 GitHub Pagesのカスタムドメイン設定 GitHub Pagesを普段使っていない人も多いと思いますので、まずは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.e-ontap.com/blog/?date=20210907
DNS通信を暗号化する「DNS over HTTPS」とその課題 | Bizコンパス -ITによるビジネス課題解決事例満載！
我々が、DNSの浸透を 待つ間に起きている真実
UnboundとNSDの紹介 BIND9との比較編
