JVM (Java 仮想マシン) には DNS の名前解決の結果をキャッシュする挙動が備わっている。キャッシュするだけならいいのだけれど、このキャッシュでは DNS の TTL を無視してキャッシュするため、名前解決の結果が変わっても JVM からの接続先が切り替わるまでに(TTL から想定される時間以上に)時間がかかる、あるいは全く切り替わらないということがある。この挙動やその制御について調べたので、その話をする。 (以下の話題では Oracle JDK および OpenJDK を対象にして論じるので、それ以外の JVM 実装でどうなってるかは調べていない。適用できる箇所もあればそうでない箇所もありそう) 背景・解説 これらのデフォルト値は名前解決成功時は セキュリティーマネージャーがインストールされている場合のデフォルト値は -1 (ずっと) で、セキュリティーマネージャーがインストー
こんにちは。サービスグループの武田です。 インターネットを利用する上で必要不可欠なしくみとしてDNS(Domain Name System)があります。DNSはホスト名からIPアドレスを調べる名前解決のしくみですね。それではこのDNSというサーバは実際にどのように名前解決を行っているのでしょうか? 今回はコマンドを使って、簡単に挙動を確認してみましょう。 なおこの記事では、DNSサーバが階層構造となってドメイン管理をしていることの説明はしません。 問い合わせには2種類ある DNSサーバは実際にレコードを保持して管理する DNSコンテンツサーバ と、コンテンツは保持せず問い合わせの解決と結果をキャッシュする DNSキャッシュサーバ があります。一般的にクライアント(DNS用語では スタブリゾルバ と呼ぶ)はDNSキャッシュサーバに対して問い合わせを行います。 さてDNSキャッシュサーバはコン
Googleによるドメイン登録事業(レジストラ)サービス「Google Domains」(グーグル・ドメイン)が日本でもようやく解禁となったので、さっそく当ブログのドメイン「buzzyvox.com」をお名前.comから移管してみました。 Google Domainsに於けるドメインの維持費用(更新料)は年あたり1,400円とお名前.comに比べ少しばかり割高ですが、ネームサーバの性能や信頼性はかなり高いようなので、お名前.comに不満があるのなら使わない手はありません。 この先、お名前.comからGoogle Domainsに乗換えを図る方が増えると思われるので移管手続きの流れを簡単に説明しておくことにします。 お名前.comからGoogle Domainsへのドメイン移管手順まずは自分のGoogleアカウントにログインした状態でGoogle Domainsにアクセスし、右上の「MANA
本記事に関連した講演が、本日13:45~開催されるIIJ Technical WEEK 2016で行われます。(該当のセッションは16:45~予定の「DNSにまつわるセキュリティのあれこれ」です)ストリーミング中継も行いますので、是非ご覧ください。 このごろ DNS ってこうげきをうけることがおおいんだって。 DNS は「どめいんなまえしすてむ」のことで、ドメインのなまえをきくと IP アドレスをおしえてくれたりするしくみだよ。わるいひとたちが DNS をいじめてつかえないようにしちゃうと、インターネットであそべなくなっちゃう。 だったら、それにまけないつよい DNS をつくればいいよね。 どんな攻撃が来るのか ……すいません、読みにくいですね。漢字使います。なお、漢字で書いたところで中身は「ぼくのかんがえたさいきょう」に違いありません。 DNS に対する攻撃は大きくわけると、2つ。DoS
更新履歴 思ったより参照量が多くてビビる。 情報源として使用されてるケースも見かけたため、更新履歴入れました。(多分今日だけでしょう) 2016-10-29 11:50 ns-a4.io が正しく次の権威サーバーを返してくれるの確認しました。障害復旧でいいんじゃないでしょうか。Android で dig 叩くツールあった。 03:08 http://dnsviz.net/d/io/WBOUpA/responses/ 直った? 2016-10-28 19:21 JST @rocca0504 さんの記事追記。 19:10 JST NXDOMAIN ステータスを勝手に返すのが問題の本質だったので追記。 18:10 JST dig の +norecurse (+norec) について追記しました。(@fumiyas さんご指摘ありがとうございます。) 見た目悪くなりますが、必要な箇所には記載がある
■はじめに まず、「DNSアンプ攻撃」が分からない方はこちらをご覧下さい。そしてDNS「オープンリゾルバ/Open Resolvers」についてはこちらのリンクに纏めて説明しています。 「DNSアンプ攻撃」と「オープンリゾルバ」の関係は↓ Open Resolvers pose a significant threat to the global network infrastructure by answering recursive queries for hosts outside of its domain. They are utilized in DNS Amplification attacks リファレンス: Open Resolver Project openresolverproject.org 大体4月中旬から少しずつ日本国内に悪用された「DNSアンプ攻撃」のIPレポ
【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 サーバ(フルレゾルバ)を提供し
追記(2016-07-13 16:40) Changelog に書いてあるとおり(BUG/MEDIUM: dns: unbreak DNS resolver after header fix)、 動的名前解決ができないバグが修正されました。 HAProxy 1.6.6 で動的名前解決できないバグが修正されていました(Changelog にも書いていますが一応検証しました)— tkuchiki (@tkuchiki) 2016年7月13日 詳細は省きますが、本記事と同様の検証を行い、動的名前解決ができることを確認しました。 追記(2016-06-24 12:34) HAProxy 1.6.5 は、DNS の動的名前解決が動作しないようです。 ご注意ください。 HAProxy 1.6.5 で動的名前解決できない問題については 1.6.4 で困っていなければそれを使って、1.6.5 がよければ
こんにちは、インフラストラクチャー部の沼沢です。 AWS の DNS フェイルオーバーの設定についての記事はたくさん出回っていますが、今回は Sorry ページに特化した設定をご紹介します。 以前、社内で AWS 上にシステム構築していた際に、例えば「急激なアクセス増で AutoScaling が間に合わないなどでユーザのリクエストに対して正常に応答できない状態に陥ってしまった時に “画面が真っ白な状態が続くこと” だけは避けたい」という要望を受け、最終手段的な位置付けで構築した Sorry ページ表示の仕組みについてご紹介させていただきます。 特段目新しい技術や情報ではありませんが、AWS にてサーバレスで高可用性な Sorry ページを構築する方法の参考になればと思います。 DNSフェイルオーバーとは?そもそも、DNS フェイルオーバーとはなんなのかを軽くご説明させていただきます。 ※
●まえがき 暇つぶしにつくりました 最小限の実装(パラメータ直打)となっています 需要はないと思いますが載せておきます ●実装及びテスト環境 Linux Mint 17.2 Rafaela 64-bit ruby 2.2.1p85 (rvmで入れました) net-dns ver.0.8.0 (モジュールです gem install net-dnsで入れました) ●実際に使った様子 このブログのURLを名前解決した結果です キャッシュサーバにキャッシュがあるため、すぐ応答がきています 見方がわからない人は、DNS クライアントを作ってみよう (2)を見てみるといいかも ●ソースコード require 'socket' require 'rubygems' require 'net/dns' require 'benchmark' srcip = "127.0.0.1" #自身のIPアドレス
ども、大瀧です。 AWSとオンプレミスのハイブリッド構成は、エンタープライズのAWS活用では定番となりつつあります。そんなAWSハイブリッド構成の設計でよく課題に挙がるのが、DNSです。このブログエントリーでは、使えるDNSサービスの種類とその特性をまとめ、いくつかの構成パターンを解説、比較してみます。 AWSハイブリッド構成とは AWSハイブリッド構成は、AWSでプライベートネットワークを構成するAmazon VPCとオンプレミスのネットワークを相互接続し、両方のサーバーリソースを組み合わせて利用するものです。VPCとオンプレミスとの接続は、プライベート接続として専用線 *1かインターネットVPN *2を利用します。 AWSハイブリッド構成で利用するDNSサービス DNSサーバーには権威サーバーとキャッシュサーバーの2種類がありますので、それぞれで利用できるサービス毎に並べてみました。[
受ける この情報は下記から CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo https://isc.sans.edu/forums/diary/CVE20157547+Critical+Vulnerability+in+glibc+getaddrinfo/20737/ getaddrinfo() を使ってる場合に、影響を受ける可能性があります。 すでに PoC は公開されていています。 https://github.com/fjserna/CVE-2015-7547 ここに公開されている CVE-2015-7547-proc.py とかを root 権限付きで実行すると、この手の buffer overflow を引き起こすパケットを返してくる DNSキャッシュサーバもどきになってくれます。 これをローカルで動かした状態
2016年2月17日に公開されたGNU Cライブラリの複数の脆弱性の内、CVE-2015-7547*1は任意のコードが実行可能であるとしてGoogleが報告しています。ここではこれら脆弱性に関連する情報をまとめます。 脆弱性情報 Vulnerability Note VU#457759 glibc vulnerable to stack buffer overflow in DNS resolver JVNVU#97236594: glibc にバッファオーバーフローの脆弱性 CVE CVE-2015-7547 CVE-2015-8776 CVE-2015-8778 CVE-2015-8779 影響 DoS/RCE DoS DoS DoS 重要度 High Low Low Low ステータス PoC公開 PoC公開 PoC公開 PoC公開 対策 修正版へ更新 修正版へ更新 修正版へ更新 修
ども、大瀧です。 本日午前中にCVE-2015-7547に関する情報が公開されました。 AWS環境での対応方法をまとめておきます。 AWSからのアナウンス : CVE-2015-7547 Advisory AWSのマネージドサービスは影響無し RDSやS3など、AWSのマネージドサービスは影響ありません。 EC2はAWS DNSを参照する場合は影響無し 今回の脆弱性はDNS関連とのことですが、Amazon VPCで提供されるDNSキャッシュサーバー(AWS DNS)を参照するEC2インスタンスも影響ありません。 AWS DNS以外のDNSサーバーを向いているEC2では、glibcパッケージをアップデートすることで対応が必要です。Amazon Linuxの場合は、以下のyumコマンドでアップデートしましょう。 sudo yum update glibc ただし、Amazon Linuxのバー
glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547LinuxSecurityiptablesfirewalldglibc はじめに glibcでヤバメな脆弱性キター! 「glibc」ライブラリに脆弱性、Linuxの大部分に深刻な影響 - ITmedia エンタープライズ Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo - SANS Internet Storm Center Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc ge
クラウド・インスタンスにおけるDNSサーバーの指定は、DHCPサーバーから情報を取得して利用するようになっています。具体的には dhclient が resolv.conf を上書きする感じですが、最近は NetworkManager さんがこの辺の面倒を見てくれるので、まともな構成 ってやつを考えてみました。 ドンピシャで正着に至ったというわけではないですが、ひとつの有効な手段として扱うことはできそうです。 目次 概要 NetworkManagerがない場合 NetworkManagerのデフォルトの挙動 dnsmasqを利用する 任意のDNSサーバーを追加する 起動時の設定として組み込む dnsmasqのForward方式 DNSキャッシュ 耐障害性 理想の挙動 概要 NetworkManager は必ずしも必要なわけではないですが、CentOS7 など新し目のディストリビューションで
おはこんばんにちは。ナツヨです。 いつか、脆弱性対応についての記事を書こうと思っていたら、BINDさんがまた 脆弱性を発表してくれました。(CVE-2015-8704,CVE-2015-8705) 前回の発表から1ヶ月も立っていないのに、流石BINDさんだなぁと思いました。(遠い目) 今日は、BINDに焦点をあてて、脆弱性対応とはどういうことが必要なのかまとめていこうと思います。すでに日常的に脆弱性対応されている方というよりは、「なんかしらんけどDNSサーバの管理者になっていた。とりあえずBINDというソフトウェアで動いていることは知っている」という方向けだと思います。 1.BINDの脆弱性の発表をキャッチする BINDの脆弱性について、世の中で一番早く発信するのはBINDのサポートを行っているISC本家(BIND | Internet Systems Consortium)だと思います。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く