ICANN、プライベートネットワークで使うための公式トップレベルドメイン「.INTERNAL」を提案
インターネット上のIPアドレスやドメイン名などの管理や調整を行っているICANN（Internet Corporation for Assigned Names and Numbers）は、プライベートネットワークやホームネットワークのためのトップレベルドメインとして「.INTERNAL」を予約語として割り当てるという提案を1月24日付で公開しました。 プライベートネットワークには、「192.168.xx.xx」などの専用のIPアドレス空間が公式に割り当てられており、このIPアドレス空間はインターネット上のIPアドレスと衝突しないことが約束されています。 しかし、このIPアドレス空間で管理されているプライベートネットワークのために公式に割り当てられたドメイン名の名前空間は、現時点ではありません。 そのため、プライベートネットワークの運用者がプライベートネットワーク内で何らかのドメイン名を運
WebサーバのDNSへの登録方法が変わるよ – JANOG48 Meeting
場所 OHGAKI(完全リモート) 日時 Day3 2021年7月16日(金) 14:45～15:15(05分) 概要 HTTPSというDNSレコードタイプを定義するdraft-ietf-dnsop-svcb-httpsがもうすぐRFCになります。実利用はすでにはじまっており、WebサーバのDNSへの登録は従来のA/AAAAレコードから今後は新しいHTTPSレコードに移行していくことになるでしょう。本発表ではHTTPSレコードの簡単な紹介と、それにともなう注意点を説明します。 発表者 山口 崇徳(株式会社インターネットイニシアティブ) 資料 公開資料 DNSでHTTP (DNS Summer Day 2021)
DNSpooqの脆弱性詳細と攻撃コード解説 - knqyf263's blog
概要 要約 詳細 背景 前提 インターネット上に公開されたdnsmasq LAN内のマシンが攻撃者の支配下にある LAN内のマシンに攻撃者管理のWebサイトを閲覧させることができる 影響 中間者攻撃 汚染拡大 DDoS/Reverse DDoS CVE-2020-25684: ポートの多重化 CVE-2020-25685: 脆弱なCRC32の利用 CVE-2020-25686: 同一ドメイン名に対する複数クエリ発行 DNSフォワーダにおけるレスポンスの未検証 組み合わせる ドメイン名の登録 ソースIPアドレスの偽装 CRC32の衝突 攻撃の流れ ブラウザからの攻撃 検証端末 攻撃の成功確率 PoC fowarder cache attacker 大量クエリの送信 偽装レスポンスの送信 高速化の話 実行 対策・緩和策 余談 まとめ 概要 先日DNSpooqという脆弱性が公開されました。 ww
DNS ANAMEレコードの提案仕様 - ASnoKaze blog
20181019追記 「Address-specific DNS aliases (ANAME)」として、新しい draft-02が出されました 20180912追記 この提案仕様はexpireしてしまいました。 完璧に代替するものではありませんが、いくつかの方法について議論がされているようです。 IETFでのDNS関連の標準化は普段追ってないので恐縮だが、DNSOP(DNS OPerations)WGで気になったドラフトがあったので読んで見る。 「Address-specific DNS Name Redirection (ANAME)」という提案仕様であり、先日WGドラフトになったようだ。著者は、ISC, PowerDNS, DNSimple の方々でありDNS実装に関わっている人が書いているようだ。 PowerDNSでは、すでにALIASと言う似たような機能が実装中のようですし、Cl
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
CVE-2015-7547 glibc における getaddrinfo の脆弱性について – IIJ Security Diary
この脆弱性は2016年2月17日に対策済みバージョンと共に公開されました。内容としては getaddrinfo の呼び出しにおいてスタックバッファオーバーフローが発生する物です。公開時点で以下の通り、PoC を含めた技術的な詳細が公開されています。本記事では、脆弱性が発生するまでの処理と、回避策について解説したいと思います。 CVE-2015-7547 — glibc getaddrinfo() stack-based buffer overflow Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow 脆弱性に至るまで 今回の脆弱性は getaddrinfo の呼び出しに起因しています。脆弱性のある箇所までの関数呼び出しは以下の様になっています。 getaddri
「glibc」ライブラリに脆弱性、Linuxの大部分に深刻な影響
ほとんどのLinuxアプリケーションに使われているGNU Cライブラリの「glibc」に深刻な脆弱性が見つかり、米GoogleとRed Hatの研究者が開発したパッチが2月16日に公開された。 脆弱性は2008年5月にリリースされたglibc 2.9以降のバージョンに存在する。Googleによると、glibcで「getaddrinfo()」ライブラリ機能が使われた際に、スタックベースのバッファオーバーフローの脆弱性が誘発されることが判明。この機能を使っているソフトウェアは、攻撃者が制御するドメイン名やDNSサーバ、あるいは中間者攻撃を通じて脆弱性を悪用される恐れがあるという。 Googleの研究者は、先にこの問題を発見していたRed Hatの研究者と共同で調査を進め、脆弱性を突くコードの開発に成功したとしている。パッチの公開に合わせて、攻撃には利用できないコンセプト実証コードも公開した。こ
NetworkManager＋dnsmasqで名前解決の耐障害性を向上 | 外道父の匠
クラウド・インスタンスにおけるDNSサーバーの指定は、DHCPサーバーから情報を取得して利用するようになっています。具体的には dhclient が resolv.conf を上書きする感じですが、最近は NetworkManager さんがこの辺の面倒を見てくれるので、まともな構成 ってやつを考えてみました。 ドンピシャで正着に至ったというわけではないですが、ひとつの有効な手段として扱うことはできそうです。 目次 概要 NetworkManagerがない場合 NetworkManagerのデフォルトの挙動 dnsmasqを利用する 任意のDNSサーバーを追加する 起動時の設定として組み込む dnsmasqのForward方式 DNSキャッシュ 耐障害性 理想の挙動 概要 NetworkManager は必ずしも必要なわけではないですが、CentOS7 など新し目のディストリビューションで
ループバックドメイン - オープンソースこねこね
自分用開発メモ。 サブドメインを含めて127.0.0.1として登録されているドメイン。 lvh.me loopback.jp devd.io
ルートサーバのIPアドレス変更 – JPNIC Blog
tech_team 2015年10月2日 インターネットの技術 DNSルートサーバのうちの一つ、 H.ROOT-SERVERS.NET (H-Root)のIPアドレスが2015年12月1日に変更されます。 http://h.root-servers.org/renumber.html ルートサーバのIPアドレスが変更されるため、キャッシュサーバのヒントファイルを更新する必要があります。新しいIPアドレスが記載されたヒントファイルは、上記のアドレスが変更される12月1日頃に更新されます。ヒントファイルは以下のURLで公開されています。 http://www.internic.net/domain/named.root http://www.internic.net/domain/named.cache 2015年11月30日まで使われる現行のIPv4アドレスは、2016年6月1日までの6ヶ月
（緊急）BIND 9.xの脆弱性（DNSサービスの停止）について（2015年7月8日公開）
--------------------------------------------------------------------- ■（緊急）BIND 9.xの脆弱性（DNSサービスの停止）について（2015年7月8日公開） - DNSSEC検証が有効に設定されている場合のみ対象、バージョンアップを強く推奨 - 株式会社日本レジストリサービス（JPRS） 初版作成 2015/07/08（Wed） --------------------------------------------------------------------- ▼概要 BIND 9.xにおける実装上の不具合により、namedに対する外部からのサービ ス不能（DoS）攻撃が可能となる脆弱性が、開発元のISCから発表されました。 本脆弱性により、提供者が意図しないサービスの停止が発生する可能性があ ります。 該当
The story of Basecamp’s disastrous policy
The story of Basecamp’s disastrous policy Basecamp’s CEO published a blog post about policy changes — it may have broken the company On April 26th, Basecamp founder and CEO Jason Fried posted on his blog about some policy changes that would be happening at the company, which makes team collaboration software. One policy stuck out to many on the internet — the company would no longer be allowing it
RHEL6/CentOS6では、single-request-reopen を必須にしたい…
2012-11-02 結論から言えば、とりあえず RHLE6/CentOS6 な人は /etc/resolv.conf に options single-request-reopen を書いておこうという話です(全部小文字ですよ、念のため） なぜか？ RHEL5/CentOS5/Ubuntu 10.04なLinuxとかでは、FQDN の解決をするときに DNSキャッシュサーバに AAAA RR の Queryを投げる AAAA RR の Reply を受ける DNSキャッシュサーバに A RR の Queryを投げる A RR の Reply を受ける という挙動でしたが、RHEL6/CentOS6 では DNSキャッシュサーバに A RR の Queryを投げる DNSキャッシュサーバに AAAA RR の Queryを投げる A RR の Reply を受ける AAAA RR の Re
DNSリバインディングによるルータへの侵入実験
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年03月25日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、DNSリバインディング攻撃によりブロードバンドルーターの設定を外部からの侵入を許すように変更してみたので報告する。 DNSリバインディングに対する関心が高まってきている。本年1月12日には、読売新聞夕刊一面トップで、iモードブラウザ2.0のDNSリバインディングによる不正アクセスが報じられた。3月17日のcomputerworld.jpでは、『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』という翻訳記事が紹介された。実は「最も警戒すべきセキュリティ脅威」というタイ
強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ
本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
DNS でラウンドロビンは当てにならない。 - JULY’s diary
モバイルでもDNSラウンドロビンはちゃんと動作しますか？ PCであれば、だいたいのブラウザが対応していると聞きますが、モバイルはどうなんでしょうか？ A、B、Cというサーバをラウンドロビンで動かした時に、Bが死んだとします。 その場合、PCはBに行かなくなると思いますが、携帯の場合はどうなんでしょうか？ 携帯はキャリアのプロキシ？か何かを通っていそうなので、ちゃんと動くのかが気になります。 また、ラウンドロビンの弱点は何ですか？ 今のところ気づいているのは、単に振り分けるだけだから1台に負荷が集中するかもしれないことくらいしかないです。 上の質問を見て、「あれっ、ラウンドロビンって、ブラウザのようなアプリケーションサイドで対応するものだっけ？ gethostbyname 辺りで勝手にやっていて、アプリ側は渡された IP で繋ぐだけでは？」と思っていたら、それは、もう古い話らしい。 0000
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オレオレTLDには気を付けよう