DNSでHTTPS ※ただしDNS over HTTPSではない執筆者：IIJ ネットワーク本部 アプリケーションサービス部 DNS技術課 山口 崇徳 2023年11月、HTTPSレコードがRFC9460として標準化されました。 HTTP/3を支える技術のひとつで、WebサーバのDNSへの登録方法も変わります。 CNAME + MX + α の機能も備えています。 DNS / Web / ファイアウォール運用者はぜひご覧ください。
HTTPSレコードがRFCになりました | IIJ Engineers Blog
RFC9460が出ました 昨年、このエンジニアブログでHTTPSレコードについてとりあげました。これを書いたときはHTTPSレコードはまだインターネットドラフトだったのですが、2023年11月、ついにRFC9460として標準化されました。 RFCにはなったけど日本語の詳しい記事はまだ少ないし需要あるかなーと思って改めて解説を書きはじめたんですが、だらだらとクソ長くなって書いた本人が読んでも眠くて退屈な内容になってしまいました。ので、書いたものはばっさり捨てました。 そういえばいまから3年前、DNS Summer Day 2021で発表したプレゼン資料がありました。これをRFCになった現在の内容にあわせてアップデートしたほうがてっとりばやいしわかりやすそうです。 ということで、加筆修正した資料を置いておきます。DNS屋さんはとりあえず全部読んでおいてください。Web屋さんは前半だけ理解してお
ドメインコントローラーからDNSサーバーを分離（できなかった） - Qiita
こんにちは。先月からSEとなったdessinです。 実務でADの話がたくさん出てくるので勉強した内容を書きます。 背景 ADについてはこちらの連載が大変参考になりました。ID管理がワーキンググループからドメイン管理に発展したという経緯が書かれており、こういった歴史も書かれた記事は私のような素養のない者には助かります。 しかし、この記事に書かれた内容の、「ドメインコントローラーを構築すると、DNSサーバーにSRVレコードとAレコードが自動的に作成されます。」というのがよくわかりませんでした。ドメインコントローラーにそんなことできるのかと。 DNSサーバーは以前に構築したことがあるし、同じネットワーク内にドメインコントローラーを作れば、自動的にレコードが登録されるところが見られるかと思い、Azureに実装しました。 概要 AD検証用のリソースグループ、Vnet作成 DNSサーバーの構築（手前味
280blockerの暗号化DNSの詳細 | 280blocker
最近公開した暗号化DNSサーバ(DoH)の運営や技術的な話です。 暗号化DNSサーバーはiOSの280blockerアプリ利用者だけに公開しています。最新版アプリの高度な設定から利用が可能でsafari以外の広告もブロックできます。サービスを利用するだけなら特に知らなくても良い話です。 DNSサーバ DNSサーバーは端末から問い合わせのあったサイトのドメイン名をipアドレスへ変換して応答する作業をしています。端末はその情報を利用して、閲覧したいサイトのIPアドレス宛にデータを要求します。 DNSサーバーがドメインの問い合わせに対してそのサーバーは存在しない（NXDOMAIN)という応答にすると、端末はデータが要求できなくなり、そのドメインとの通信をブロックできます。これがDNSサーバを利用した広告ブロックです。 ちなみにDNSサーバへの問い合わせの中で、広告系ドメインの問い合わせの割合はざ
【検証】Windows DNS サーバの脆弱性（CVE-2020-1350 通称"SIGRed"）
2020年7月14日(日本時間)、Microsoft社よりWindows DNSサーバにリモートでコード実行が可能な脆弱性が公開されました[1]。これは不正なDNSレスポンスをWindows DNSサーバが適切に処理できないことにより影響を受けるものです。 本脆弱性はCheckPoint社のリサーチャーによって発見され、"SIGRed"と命名されました[2]。共通脆弱性評価システム(CVSS)においても最高となるスコア10と評価され、今後の攻撃コード公開状況によっては、「ワーム化可能」とされる脆弱性です。 本記事では、本脆弱性の検証結果やその悪用を試みる通信の痕跡の確認方法について解説します。 本脆弱性の概要 本脆弱性は、DNSにおけるリクエストや処理の認証に使われるSIGレコード(電子署名が定義されているリソースレコード)に対するクエリの応答に、巨大なサイズのメッセージを付与することでタ
IIJのDNS暗号化への取り組み | IIJ Engineers Blog
はじめに ネットワーククラウド本部の其田です。今回はIIJのDNS暗号化への取り組みを紹介します。 この記事で紹介するのは、本日プレスリリースした「IIJ、接続サービスで提供するDNSのセキュリティを強化」の中の、DNSキャッシュサーバとお客様の間の通信(DoT/DoH)に該当します。 取り組みのきっかけ IIJでのDNS暗号化の取り組みは2018年からスタートしています。 当時本命とされたDNS over TLS(DoT)は2016年にRFC化されているので、ちょっと遅いスタートだったかもしれません。DoTやDoH(DNS over HTTPS)が対象とする、フルリゾルバ(DNSキャッシュサーバ)～スタブリゾルバ(パソコンやスマホの中に組み込まれているDNS問い合わせ機能)の間の通信は、ISPの契約者がISPが用意したDNSキャッシュサーバを使う限りはインターネットを通過せず、特定のIS
無料で安全なDNSサービスの一覧 | ハルパス
DNSとは？ DNS（Domain Name System）とは、IPアドレスとドメイン名の相互変換を行なう、インターネットを利用する上で欠かせないシステムです。 ネット上のすべてのコンピューターには「IPアドレス」という番号が割り当てられており、データの送受信はこのIPアドレスを指定して行っています。 しかし、IPアドレス（例：192.0.2.0）は数字の羅列となり人間には覚えにくいため、ドメイン（例：blog.halpas.com）が開発されました。 ですが、データの送受信はドメインではできないので、バックグラウンド（パソコンの内部）でドメインをIPアドレスに変換して通信を行なっています。 DNSサーバの変更方法は上の記事か、こちらを参考にしてください。 追記：「パブリックDNSのよくある疑問とその回答」を投稿しました。 Google Public DNS Google Public
総務省｜報道資料｜DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性
この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN（Internet Corporation for Assigned Names and Numbers）が、DNS（ドメインネームシステム）において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵（ルートゾーンKSK）の更改を実施します。 総務省では、ICANNからの依頼を受けて、内閣サイバーセキュリティセンターの協力の下、国内関係者への周知を実施しております。 この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN（Internet Corporation for Assigned Names and Numbers）が、DNS（ドメインネームシステム）において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵（ルートゾーンKSK）の更改を実施します。 これに伴い
セカンダリDNSサーバーの設定
自前でセカンダリDNSサーバーを構築する際の設定例をご紹介します。 まずプライマリDNSサーバーの設定。 /etc/named.confでセカンダリを用意したいドメインのゾーン設定を修正します。 zone "example.jp" in { type master; file "example.jp"; //ゾーン設定ファイルを指定 allow-transfer { 0.0.0.0; }; //セカンダリDNSサーバーのIPアドレス }; allow-trasferでセカンダリDNSサーバーからのゾーン転送を許可する。※セキュリティ上必須 次にセカンダリDNSサーバーの設定をします。 /etc/named.conf zone "example.jp" in { type slave; //セカンダリなのでタイプをスレーブに指定 file "slaves/example.jp"; //ゾーン
DNSサーバーをオープンリゾルバーにしない
今年に入って、DNSの再帰的な問い合わせを使ったDDos攻撃が報告されているようです。 DNSキャッシュサーバーとして運用している場合でも、制限を設けて適切に設定をしておかないと、 DDos攻撃の踏み台にされてしまいます。 詳しくはこちらのサイトを参考にしてください。 http://www.jpcert.or.jp/pr/2013/pr130002.html 管理しているサーバーがオープンリゾルバーになっていないかどうかを確認するサイトが開設されています。 http://www.openresolver.jp/ OSやBINDのバージョンによっても異なりますが、設定例をご紹介します。 まず、オープンリゾルバーになっていないかを確認します。 前述したオープンリゾルバー確認サイトも確認できますが、ここではコマンドラインで確認します。 $ wget -qO - http://www.openre
（緊急）BIND 9.10.xの脆弱性（DNSサービスの停止）について（2014年6月12日公開）
--------------------------------------------------------------------- ■（緊急）BIND 9.10.xの脆弱性（DNSサービスの停止）について（2014年6月12日公開） - キャッシュ／権威DNSサーバーの双方が対象、バージョンアップを強く推奨 - 株式会社日本レジストリサービス（JPRS） 初版作成 2014/06/12（Thu） --------------------------------------------------------------------- ▼概要 BIND 9.10.xにおける実装上の不具合により、namedに対する外部からのサー ビス不能（DoS）攻撃が可能となる脆弱性が、開発元のISCから発表されまし た。本脆弱性により、提供者が意図しないサービスの停止が発生する可能性 があります。
（緊急）BIND 9.10.0の脆弱性（DNSサービスの停止）について（2014年5月9日公開）
--------------------------------------------------------------------- ■（緊急）BIND 9.10.0の脆弱性（DNSサービスの停止）について（2014年5月9日公開） - BIND 9.10.0のキャッシュDNSサーバーが対象、バージョンアップを強く推奨 - 株式会社日本レジストリサービス（JPRS） 初版作成 2014/05/09（Fri） --------------------------------------------------------------------- ▼概要 BIND 9.10.0における実装上の不具合により、namedに対する外部からのサー ビス不能（DoS）攻撃が可能となる脆弱性が、開発元のISCから発表されまし た。本脆弱性により、提供者が意図しないサービスの停止が発生する可能性 が
DNSキャッシュポイズニングの基本と重要な対策:Geekなぺーじ
2014年4月15日に公開されたJPRSの緊急注意喚起に続き、中京大学の鈴木常彦教授によるDNSキャッシュポイズニングに関する技術情報が公開されました。 今回公開された技術情報に書かれている内容には、DNSの本質につながるさまざまな要素が関係しており一回で書ききれるものではなく、また、書いている側（私）も、それぞれの要素技術について勉強しながら理解しつつ進めていかないと混乱してしまうということが良くわかったため、これから数回に分けて徐々に書いて行くことにしました。 ということで、今回はまず、そもそもDNSキャッシュポイズニングとは何かということと、JPRSの注意喚起に書かれているUDPソースポート番号のランダム化（ソースポートランダマイゼーション）の概要、そしてなぜそれが重要なのかという点について解説します。 DNSキャッシュポイズニングとは インターネットで通信を行うとき、各機器同士は通
強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ
本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
