変化するDNSとサーバー証明書の関係～「ランチのおともにDNS」より【Internet Week 2017】
広く知ってほしいDNSのこと ―とあるセキュリティ屋から見たDNS受難の10年間―
広く知ってほしいDNSのこと ―とあるセキュリティ屋から見たDNS受難の10年間―1. ssmjp20171031 広く知ってほしいDNSのこと ～とあるセキュリティ屋から見たDNS受難の10年間～ 2017年10月31日 NRIセキュアテクノロジーズ株式会社 日本DNSオペレーターズグループ Internet Week 2017 プログラム委員会 中島 智広 2. Copyright（C） NRI SecureTechnologies, Ltd. All rights reserved. 1 本日のゴール 参加者全員が以下のキーワードの区別が付くようになる ▪ スタブリゾルバ、フルリゾルバ、ネームサーバ ▪ レジストラ、レジストリ 「DNSの脅威」を正しく知り、正しく怖がる 「DNSの浸透問題」が都市伝説であることを知る 技術者としてDNSを正しく理解し、備えるモチベーションを得
外形監視におけるフルリゾルバーのキャッシュ保持期間
こんにちは、滝澤です。 みなさん、提供しているサービスの外形監視を行っていますか。 DNSレコードの変更ミスやドメイン名の失効などを起因とする障害に早く気づけるようになっていますか。 ということで、今回は外形監視におけるフルリゾルバー（キャッシュDNSサーバー）のキャッシュ保持期間について考えてみます。 外形監視とフルリゾルバーについて 外形監視とは何かを一言でまとめると、「システムの外部から、システムが提供していサービスが正常に動作しているかを監視する」ことです。 このとき、「ユーザーと同じような方法でアクセスする」ことが重要となります。 アプリケーションのサービスへのアクセス方法 ウェブブラウザーのようなユーザー側のアプリケーションがサービスに接続するときには、次の図のようにサービスのドメイン名の名前解決を行い、取得したIPアドレスに対して接続を行います。 このとき、名前の解決は次のよ
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
AWS NLB についてあれこれ - 水深1024m
AWS ELB (ALB, CLB) には日頃からだいぶお世話になっているわけですが、新しい Network Load Balancer (NLB) がリリースされましたね。 新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング | Amazon Web Services ブログ 雑に言えば CLB TCP モードの次世代版というとこですかね。 ざっくりドキュメントを読みつつ、いくつか気になる点があったのでまとめます。 ドキュメントに記載されていない内容は私が検証した内容です。何か間違いがあればお気軽にご指摘ください。 パケットはどのように流れるのか 一応図にしておきます。なんというか懐かしい (とか言ったら怒られそうな) 流れですね。 ALB や CLB (HTTP, TCP 両方) ではロードバランサがそれぞれの通信を終端していわゆるプロキシの
Mac用ターミナルアプリ「iTerm 2」の機能により、パスワードを含む表示されたテキストがDNSサーバーに送られてしまう問題が確認される。
Mac用多機能ターミナルアプリ「iTerm 2」の”DNS Look”機能により、パスワードを含む表示されたテキストがプレーンテキストのままDNSサーバーに送られてしまう問題が確認され、開発者のGeorge Nachmanさんが最新の「iTerm 2 v3.1.1」へアップグレードする様に求めています。詳細は以下から。 オランダPowerDNS.COM BVのエンジニアPeter van Dijkさんによると、Mac用の多機能ターミナルエミュレータアプリ「iTerm 2」に、ユーザーが入力したパスワードなどがプレーンテキストの状態で誤ってDNSサーバーへ送られてしまう不具合が含まれているとして、至急iTerm 2のオプションを無効にする様に求めています(確認されたのはiTerm 2 v3.0.15およびmacOS 10.12.6)。 Detailed steps to reproduce
ドメイン管理の仕組み「DNS」が運用変更 総務省が注意喚起
「DNS」で暗号鍵の一部が更改されるのを受け、総務省がネットサービスプロバイダーや企業のシステム管理者などに注意喚起。 総務省はこのほど、ホスト名・ドメイン名をIPアドレスに変換する仕組み「DNS」（Domain Name System）で、暗号鍵の一部が2017年7月～18年3月にかけて更改されるのを受け、ネットサービスプロバイダーなどに対応措置を講じるよう求めた。9月19日までに対応しなければ、ユーザーがWebサイトの閲覧やメール送信をできなくなる恐れがある。 DNSは、「www.soumu.go.jp」などのホスト名（ドメイン名）を、IPアドレスに変換する「検索」の仕組み。総務省によれば、この検索結果が第三者に改ざんされないよう、電子署名を付加した「DNSSEC」（DNS Security Extensions）という仕組みで運用するのが一般的という。このほど、この電子署名の正当性を
総務省｜報道資料｜DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性
この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN（Internet Corporation for Assigned Names and Numbers）が、DNS（ドメインネームシステム）において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵（ルートゾーンKSK）の更改を実施します。 総務省では、ICANNからの依頼を受けて、内閣サイバーセキュリティセンターの協力の下、国内関係者への周知を実施しております。 この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN（Internet Corporation for Assigned Names and Numbers）が、DNS（ドメインネームシステム）において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵（ルートゾーンKSK）の更改を実施します。 これに伴い
なぜIPv6とIPv4の名前解決は別々に行なわれるのか？:Geekなぺーじ
www.example.comなどの「名前」に対応するIPアドレスをDNSサーバに問い合わせるとき、IPv4とIPv6に関する名前解決を単一の問い合わせで行うことはできません。そのため、DNSサーバに対して、IPv4に関する問い合わせと、IPv6に関する問い合わせを、別々に2度行う必要があります。 これは、DNSサーバに対しての問い合わせが単一のレコードに対してしか行えないためです。 Aレコード（IPv4アドレス）の問い合わせと、AAAAレコード（IPv6アドレス）の問い合わせは、それぞれ別々のレコードに対する問い合わせなので、両方を同時には行えないのです。 ただし、「IPv4とIPv6に関するDNSサーバへの問い合わせは別々に行わなければならない」というのは、事実上の話であって、「仕様上そうなっている」と言い切れるのかどうかは微妙かも知れません。 DNSに関するRFCは、悪名高いRFC
ざっくり詳解 - NAT64とDNS64:Geekなぺーじ
2016年6月から、iOSアプリの審査基準としてIPv4に依存するコードの禁止が追加され、IPv6対応がiOSアプリの義務なったことからも、IPv6に関する知識が必須となったエンジニアも多いのではないかと思います(Appleの発表)。 Appleのサイトでは、IPv4アドレス在庫枯渇の発生とともに、ユーザに対してIPv6のみによるインターネット接続性を提供するNAT64(「なっとろくよん」です。ろくじゅうよんではないです。)とDNS64という技術が、エンタープライズ網や携帯電話網で採用されることが増えているとあります。 Apple Developer: Supporting IPv6 DNS64/NAT64 Networks iOSアプリ開発者は、このNAT64とDNS64環境でもアプリが正しく動作することを求められています。 Appleのサイトでは、NAT64とDNS64はOS X 10
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 サーバ(フルレゾルバ)を提供し
TCPだけでDNSサーバにqueryできるようになってた:Geekなぺーじ
DNSメッセージといえばUDPの53番というイメージの方々も非常に多いと思いますが、1987年に発行されたRFC 1035の時点でDNSメッセージのトランスポートとして利用できるのはUDPとTCPであると記述されています。 しかし、これまでDNSにとってはUDPが基本でした(ゾーン転送を除く)。「RFC 1123: Requirements for Internet Hosts」には、以下のようにあります。 DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries. Specifically, a DNS resolver or server that is sending a non-zone-transfer
みんな大好き、dig コマンドの使い方(dnsを調べるあれこれ - それマグで！
みんな dig ってますか？ http でファイルが開けない時、真っ先に見るべきは iptable でも、ifconfig でもなくて dig です。 まず、dig を確認するよね。 dig の使い方 dig は名前解決を試みるコマンドです。 名前解決とは何か、、DNSの仕組みについては触れません。コマンドを使っていけばわかると思うし。 dig で 名前解決する dig t.co ドメインから、IPアドレスを探す。 dig で逆引きする。 dig -x 8.8.8.8 逆引きすると、IPアドレスからそのIPの持ち主がだいたい分かることが多い MXレコードを指定する dig yahoo.co.jp mx ns レコードを探す dig yahoo.co.jp ns txt レコードを探す dig yahoo.co.jp txt 表示をシンプルにする 結果だけ欲しい時に使う、プログラムと組わせて
DNSのクエリログ、調べるときがきました | セキュリティ対策のラック
DNSのクエリログの調査ができるようになっていますか？調べるときがきました。 先日私が「あなたの組織はDNSのクエリログを記録していますか？」という記事を書きました。その後、DNSのクエリログを設定されたでしょうか。私が聞いている範囲ではまだまだほとんどの組織で記録されるような体制になっていないようです。 あなたの組織はDNSのクエリログを記録していますか？ | ラック公式ブログ | 株式会社ラック 遠隔操作ウイルスの制御にDNSプロトコルを使用する事案への注意喚起 | セキュリティ情報 | 株式会社ラック 「そーいえば、設定したけど、そのままだったな」という方も多くいらっしゃるでしょう。私も「とりあえず今はログを取っておいてください。いずれ、調べるときがきますから」と言っていました。その「調べるとき」がきました。 PaloAlto社とFireEye社がDNSを使用する攻撃キャンペーンにつ
512バイトを超える DNSパケット | harasou.github.io
glibc の脆弱性 CVE-2015-7547 でも話題になった 512バイトを超える DNS パケットについてのメモ。 DNS では、TCP が使われたり、512 バイト超えるデータが扱われることは知っていたが、詳しい仕組みなど知らなかったので、備忘録のためにまとめておく。 そもそもなぜ 512 バイト？ 調べてみると、 インターネットで使われている IP(IPv4)の仕様では 一度に受信可能なデータグラム(ヘッダーを含むパケッ ト)として、 576 バイトを保証しなければならないと定められています。この値は、64バイトのヘッダーと 512バイトの データブロックを格納可能な大きさとして選択されたものです refs: https://jprs.jp/related-info/guide/008.pdf とのこと。 インターネットで使われている IP の仕様では、かならず「1パケットで
遠隔操作ウイルスの制御にDNSプロトコルを使用する事案への注意喚起 | セキュリティ対策のラック
経緯と概要 当社が運営する緊急対応サービス「サイバー119」は、昨年の後半より複数の大手企業様より遠隔操作ウイルスに関連する対応要請を受け、調査を行ってまいりました。 これらの事案で発見された遠隔操作ウイルスを調査したところ、攻撃者がインターネット側から企業内ネットワークで動作する遠隔操作ウイルスを操る際に、DNSプロトコルを使用するDNSトンネリングとも言われる手口を利用していることが確認されました。 これまでの代表的な遠隔操作ウイルスにおいては、Web閲覧で用いられるHTTP（S）プロトコルを使用し、Webサーバを模した指令サーバを使用しています。しかしながら今回はDNSサーバを模した指令サーバを構築していることが確認されました。 図1：Web閲覧におけるDNSの動き DNSプロトコルはインターネットにおいて、ドメイン名（FQDN）からIPアドレスなどの情報を得るためにDNSサーバとの
はじめてさわる人のためのDNS（ドメインネームシステム）入門 - Suikolog
ご注意（2019年10月17日追記） この記事に紹介されているDNS「DOZENS」ですが、2019年10月末日をもってサービスを終了します。「ムームードメイン」や「お名前.com」「Google Domains」といったサービスの中で使えるDNSや、AWSの「Amazon Route 53」といったサービスのご利用をご検討ください。 基本的にレコードの設定方法はここで紹介されているものとほぼ共通していますので、設定の参考になさってください。 あなたはDNS（ドメインネームシステム）の設定をさわったことはありますか？ 私のようなウェブデザイナーであっても、制作するサイトをホスティングするサーバやサイトの独自ドメインを用意・手配するとなると、その設定は避けては通れないところです。今回は「黒い画面なんてムリムリ」「サーバ周りのことはできるだけ触りたくない」そんなあなたに、DNS設定の入り口に立
[新機能]Amazon Route 53 Traffic Flowで複雑なルーティングポリシーを可視化する | DevelopersIO
ども、大瀧です。 本日、AWSのマネージドDNSサービスRoute 53にTraffic Flowという機能が追加されました。 早速試してみたのでレポートします。 Route 53 Traffic Flowとは Route 53には、純粋なDNSレコードにルーティングポリシーというRoute 53独自の設定を付与することができます。 ルーティングポリシーについてはAWS再入門のRoute 53の回で説明があると思うので、ここでは割愛します。ルーティングポリシーを適用すると、↓のスクリーンショットのように1つのDNS名に対して複数のレコードが定義されます。 さらに複数のルーティングポリシーを組み合わせることもできるのですが、だんだんと同じDNS名を持つレコードが増えてきて、依存関係や評価ルールを見るのが辛くなってきます。それを解決するのが今回のTraffic Flowです。Traffic F
![[新機能]Amazon Route 53 Traffic Flowで複雑なルーティングポリシーを可視化する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/c5287a23631f9589f74e1c272658f6053d2bd763/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_Route_53.png)
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PDF]第4回 PPTPを使用したリモートアクセスVPNの仕組み![[PDF]第4回 PPTPを使用したリモートアクセスVPNの仕組み](https://cdn-ak-scissors.b.st-hatena.com/image/square/745dbedd5d4da3a92973ece57a841d4ca8af1646/height=288;version=1;width=512/https%3A%2F%2Fperfectdomain.com%2Fstatic%2Fimg%2Fupload%2Fseo-acquisition.png)
