“HTTPSレコード”って知ってる？今知るべき4つの注意点 | IIJ Engineers Blog
[注] この記事はすぐに陳腐化するはずの内容について扱っています。何年か経ってからこの記事を参照する場合、2022年3月に書かれた内容であることを留意の上お読みください。 はじめに IIJ DNSプラットフォームサービスにて、先日大きなアップデートと小さなアップデートがありました。大きなアップデートというのは、これまでのマネージドDNSサービスに加えてもうひとつ、IIJ DNSトラフィックマネージメントサービスという新たなサービスが追加されたこと。サーバの死活監視結果に応じて動的にDNSの応答を変えることができます。小さなアップデートは、従来のマネージドDNSサービスへの機能追加。HTTPSレコードに対応しました。 サービスの宣伝という意味では大きなアップデートの方を紹介した方がいいんでしょうけれど、ヘソ曲がりなのでここでは小さなアップデート、HTTPSレコードの方に焦点をあてます。 そも
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)通信上で行うプ
再定義できない世界になりつつあるネットの新秩序 - 雑種路線でいこう
個人でEV SSL証明書が欲しい話 - Speaker Deckを読んで驚いたんだけど、いつの間にかFirefoxにはEVSSL証明書のルート認証局がハードコーディングされて、それを書き換えるにはブラウザをビルドし直す必要があるらしい。（というかリビルドしても追加した証明書でアドレスバーが緑色にならなかったみたい。何が足りないのかな？）ルート証明書そのものは後から足せるのだが敢えてハードコードした理由は想像できる。ルート証明書なんて後から侵入者なりマルウェアが簡単に足すことができるし、現にそういった攻撃はこれまで行われてきたからだ。 ついでにFirefoxが近々DHCPで降ってくるDNSを信用するのを止めて、DNS over HTTPSでCloudflareに問い合わせるという。これもまたDNS履歴を監視する国だとか、日本も含めてWeb検閲のためにDNSをいじってる国があって、そういった影
JANOG19 “これでいいのかTTL短いDNS TTLのリスクを考える”
これでいいのかTTL 短いDNS TTLのリスクを考える 2007年1月26日 民田雅人 株式会社日本レジストリサービス JANOG 19@沖縄県那覇市 2007-01-26 これでいいのかTTL Copyright©2007 Japan Registry Services Co., Ltd. 2 DNSプロトコルのおさらい(1/2) • 問合せと応答の単純な往復 – この名前のIPアドレスは? ⇒ IPアドレスはXXXXだよ • トランスポートは主にUDP – 条件によってTCPになることもある • 問合せパケット クエリ名+ID+etc... • 応答パケット クエリ名+ID+回答+etc... ID: 識別のための16bitの値 2007-01-26 これでいいのかTTL Copyright©2007 Japan Registry Services Co., Ltd. 3 DNSプロ
インターネットを支える「運用でカバー」の憂鬱
「今ではインターネットを『ITインフラ』の1つと呼でしまう人がいますけど、昔のインターネットは『たまに落ちるのは当たり前』くらいの信頼性しかなかったんです。電気や水道みたいな、いわゆる社会インフラとは成り立ちが違います。ITインフラと呼ばれるほど堅固なものなんでしょうかね？」 数年前、インターネット上で使われるプロトコルのセキュリティに関する取材をした際に、ある技術者から聞いた言葉である。 もともとインターネットは、ネットワーク側の機能はなるべく少なく絞って、高度な処理は端末側に任せるのが基本設計だ。最低限の仕様さえ踏まえていれば、どんな端末でもつなげるオープン性が身上といえる。 プロトコルの仕様自体がセキュリティ上の弱点になる こうした“ゆるふわ”仕様のおかげで、インターネット上には様々なサービスが発展することになった。そして今では「ITインフラ」などと呼ばれることもあるわけだが、昔の“
fluentd + InfluxDB + GrafanaでDNS通信の監視 - Qiita
背景 管理ネットワーク（自分の場合は自宅）でDNSがどのように使われているか、また問い合わせなどが正常に実施できているかの監視のための構成を作成しました。これによって以下の様なグラフを見ることができます。 クライアント毎の問い合わせ数推移 クエリの応答時間内訳（100ms未満、1000ms未満、1000ms以上） レコードタイプの内訳（Aレコード、MXレコード、など） 構成 Devourer（自作ツール）でネットワークパケットをすいとり、Fluentdに転送、そこからinfluxDBにデータを入れてGrafanaで可視化します。 設定方法 InfluxDBのセットアップ 基本はInfluxDBで解説されている手順通りですが、例えばUbuntu 64bitの場合は以下のとおりインストール＆起動します。 wget http://s3.amazonaws.com/influxdb/influxd
Fast, free and uncensored. - DNS.WATCH
Optimized for maximum speed - you will not feel any delays when browsing the web. Free We believe that everyone should have access to an uncensored resolver free of charge.
オープンリゾルバー確認サイト
JPCERT/CCでは、オープンリゾルバー(外部の不特定のIPアドレスからの再帰的な問い合わせを許可しているDNSサーバー)となっているDNSサーバーが日本国内に多く存在していることを確認しています。 オープンリゾルバーは国内外に多数存在し、大規模なDDoS攻撃の踏み台として悪用されているとの報告があります。 また、DNSサーバーとして運用しているホストだけではなく、ブロードバンドルーターなどのネットワーク機器が意図せずオープンリゾルバーになっている事例があることを確認しています。 本確認サイトでは、お使いのPCに設定されているDNSサーバーと、本確認サイトへの接続元となっているブロードバンドルーターなどのネットワーク機器がオープンリゾルバーとなっていないかを確認することが可能です。 本サイトの詳細についてはこちらをご参照ください。 ただいま処理中です。しばらくお待ちください。 ※判定処理
第3回 軽いUDPを使いネットワーク的な“近さ”を判断
第2回で紹介したIP Anycastでは、パケットの送り先を決める仕組み（経路制御）を応用する。宛先IPアドレスに至る複数の経路がある際に、「ネットワーク的に近いかどうか」など、様々な要素を勘案して最適な経路を選ぶのだ。 広域ネットワークにおけるIP Anycastでは、経路の選択にBGPを利用する。BGPは大規模なネットワーク同士のやり取りで使うルーティングプロトコルで、ASという単位で経路制御を実施する。プロバイダーなどの大規模ネットワークが、インターネット上で一意のAS番号を割り当てられているのだ。AS間では各種のパラメータを交換し、「受け取ったパケットを、次にどのAS番号のネットワークに送り出したらよいか」をまとめた経路表を作成する。自らが持つ経路情報を隣接ASに伝播する際は、自分のAS番号を追加して伝える（図1上の（1）～（3））。すると宛先のIPアドレスごとに、経由するAS番号
インターネット 歴史の一幕：3系列のDNS - JPNIC
WIDEプロジェクト/ソニー株式会社 尾上 淳 2012年6月のWorld IPv6 Launchに合わせて、「閉域網」と「インターネット」の混在に起因する、DNSのAAAAフィルタリングが話題になっています。これで思い起こされるのは、日本のインターネットの初期、1989年から1995年まで運用されていた「3系列のDNS」といわれる設定です。 日本のネットワークがインターネットにつながり始めた1989年、DNSをどう設定すべきか数人で頭を悩ませていました。そもそもそれまでは、国内ではネームサーバは使われておらず、組織内のホストはhostsファイルをコピーしたり、NIS(NetworkInformation Service)を使うのが一般的でした。そしてメールはモデムによるダイアルアップ接続で、UUCP(Unix to Unix CopyProtocol)を用いたバケツリレー方式で転送してい
7月9日までに必ずチェックを！ DNS Changer マルウェア感染確認に関する注意喚起
※本ページはアフィリエイトプログラムによる収益を得ています JPCERT/CCでDNS Changer マルウェアの感染を確認できるwebサイトが公開されている。 DNS Changerは、感染したPCのDNS設定を書き換えてしまうマルウェア。感染するとwebの検索結果を改ざんされたり、悪意あるソフトウェアをインストールされたりしてしまう。 現在、感染したPCをコントロールするためのDNSサーバはFBIによって差し押さえられ、以後は正常なDNSサーバーに置き換えられて運用中。このため感染していても実害はないが、JPCERT/CCによると、このDNSサーバが7月9日で運用終了予定とのこと。以降、DNS Changerに感染しているPCは、webサイトの閲覧やメールの送信ができなくなる可能性があるとして、感染確認の注意が促されている。 確認方法は、DNS Changer マルウエア感染確認サイ
Google Public DNSのIPv6対応 - cNotes: Current Status Notes
Google Public DNSがIPv6に対応したそうです。 https://groups.google.com/group/public-dns-announce/browse_thread/thread/c8283ef40db72f78?hl=en&pli=1 これですね。 2001:4860:4860::8888 2001:4860:4860::8844 そしてすでに使えます。 % host -t AAAA ipv6.google.com 2001:4860:4860::8888 Using domain server: Name: 2001:4860:4860::8888 Address: 2001:4860:4860::8888#53 Aliases: ipv6.google.com is an alias for ipv6.l.google.com. ipv6.l.goog
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Basics_of_DNS_that_application_engineers_should_know - Speaker Deck
DNS再入門ー初心者からベテランまで、基礎から見直して見よう。 #oscnagoya #osc_tss_ontap
DNS Summer Day 2016
Google Public DNS
DNSキャッシュサーバ チューニングの勘所
DNSMON
キャッシュDNSサーバーには lo を
DNStudy #03 #dnstudy
