Copyright © 2011 株式会社日本レジストリサービス 1 DNS浸透の都市伝説を斬る ~ランチのおともにDNS~ 2011年11月30日 Internet Week 2011 ランチセミナー 株式会社日本レジストリサービス(JPRS) 森下泰宏(オレンジ)・民田雅人(みんみん) Copyright © 2011 株式会社日本レジストリサービス 2 本日の内容 • 浸透問題とは何か • サーバーの引っ越しと浸透問題 – 浸透問題が起こらない(正しい)引っ越し方法 – 浸透問題が起こりうる引っ越し方法 • 浸透問題の正体 • まとめとおすすめ Copyright © 2011 株式会社日本レジストリサービス 3 巷のつぶやき Copyright © 2011 株式会社日本レジストリサービス 4 ISPのWebサイトにも… (顧客向けFAQや技術解説から抜粋) • DNSの書き換えを
徳丸 浩 @ockeghem http://t.co/tIIZRBEJのレンタルDNSサーバーではNSレコードは変更できない(http://t.co/OitfUqKkなど固定)ので、NSレコードのTTLが5分というのは本当に意味ない、と思います 2012-03-08 10:09:34 犬さん @inu3_ @ockeghem NSレコードは、自NSと上位NSの両方に設定があります。双方でTTLが異なる事はよくある事で、例えばhttp://t.co/NOUK8ng0は、*.gtld-servers.net. に聞くと2日、http://t.co/jSRIzSjz.に聞くと1日です。 2012-03-08 10:30:21
DNS リソースレコードを管理していると、「DNS には浸透期間があるため、DNS の設定変更後は24時間〜72時間お待ちいただく必要があります」などと書かれた DNS 事業者の注意書きを見かけることがあります。 ホスティング業者によって「浸透」等が不適切に使われている例 - www.e-ontap.com DNS浸透言ってるところと言っていないところ【レンタルサーバ編】 - ohesotori.hateblo.jp このような記述が蔓延っているために、DNS 利用者の間で「DNS では設定が浸透するまで待たなければならない」という誤解が広まっています。 また、DNS リソースレコードの地理的な伝播状況を可視化するための DNS Propagation Checker なるツールがいくつか存在しています。 https://www.whatsmydns.net/ https://www.ns
グルーレコードについて改めて考える ~ランチのおともにDNS~ 2023年11月21日 Internet Week 2023 ランチタイムセミナー 株式会社日本レジストリサービス(JPRS) 森下 泰宏・礒浪 直生 Copyright © 2023 株式会社日本レジストリサービス 1 今年も現地で、ランチのおともにDNS! • 今年のInternet Weekは、オンラインWeekとカンファレンス Weekの2本立てで開催されています • 今年のランチタイムセミナーはカンファレンスWeekのプログラ ムの一つとして、現地開催となりました! • ご参加のみなさまに、ランチをご提供しております! Copyright © 2023 株式会社日本レジストリサービス 2 講師自己紹介 • 森下 泰宏(もりした やすひろ) – 所属:JPRS 技術広報担当・技術研修センター – 主な業務内容:技術広報
米Googleは6月15日(現地時間)、ドメイン登録サービス「Google Domains」を売却すると発表した。事業はCMS(コンテンツマネジメントシステム)を手掛ける米Squarespaceが購入する。これにより、数百万の顧客が管理する約1000万のドメインがGoogleの手を離れるという。 2社間の取引は2023年の第3四半期(10~12月)に完了する予定。ユーザーは当面の間、Google Domainsからドメインを管理できるが、数カ月の移行期間の後はSquarespaceのアカウントの利用が必要になる。GoogleはSquarespaceへの移行について「可能な限りシームレスな移行を実現する」としている。 Squarespaceは取引完了後、1年間はサービスの価格を維持する方針。Googleは売却に伴う対応について説明するサポートページも公開している。 関連記事 Google検索
アプリ開発などで、本番用ドメインを使用したまま開発環境へアクセスしたいケースがある。 今回は、bindのRPZという機能を使い特定のレコードの応答を偽装してみる。 RPZについて JPNICの「RPZとは」より引用。 RPZ (Response Policy Zones)とは、フィッシングサイトやマルウェア配布サイトといった、 特定のノードへの接続防止などを目的とした、DNSによるフィルタリング機能の一つです。 元々はフィルタリング機能であり、近年では児童ポルノ対策のブロッキング方式として採用されているケースもある。 今回はこの機能を利用する。 用意するもの ざっくり以下の3つを用意。 DNSサーバ named.conf rpzゾーンファイル なお、DNSサーバについては、「検証用にDockerでbindを動かす」をベースに利用するため割愛。 named.conf named.confの例
RPZ (Response Policy Zones)とは、フィッシングサイトやマルウェア配布サイトといった、 特定のノードへの接続防止などを目的とした、DNSによるフィルタリング機能の一つです。 特定のWebサイトへの接続を防ぐには、さまざまな方法があります。 そのうちDNSを用いた防御策の一つとして、特定のドメイン名に関するDNSの問い合わせに対して、 本来の応答ではなく別の応答を返すといった方法があります。 その実装方法としては、対象となるドメイン名のゾーンを個別に持ち、 そのゾーン情報の中に変更したいレコードを記述するというやり方が、 従来は知られてきました。 しかし、新しくドメイン名を追加・削除するたびにリゾルバの設定変更が必要であったり、 リゾルバを複数運用している場合サーバそれぞれに設定する必要があったりするなど、 手順が複雑になりがちだという問題があります。 この問題を解決
今日は先日実施した以下の勉強会でkmrrさんが発表したmDNSの動作について調べてみました。 ・第9回 初心者のためのセキュリティ勉強会(オンライン開催) なお、記事にする上で、kmrrさんの了解は頂いていますので、ご安心下さい。 また、内容については個人的な見解であり、悪用を促したりする内容ではありません。 mDNSについて まずはmDNS(マルチキャストDNS)についてです。 コンピュータネットワークにおいて、マルチキャストDNS(mDNS) はローカルネームサーバーの存在しない小さなネットワーク内でホスト名からIPアドレスを解決するプロトコルである。Zeroconfサービスであり、基本的にユニキャストのDomain Name System (DNS) と同じプログラミングインターフェース、パケットフォーマット、意味論をもつ。Stuart Cheshire(英語版)はmDNSをスタンド
対象OS:Windows 2000 Professional/Windows 2000 Server/Windows XP Home Edition/Windows XP Professional/Windows Server 2003 解説 DNSサーバを使って名前を検索する場合、ホスト名とドメイン名を組み合わせたFQDN名を使って行われる。例えばコンピュータのホスト名が「www」で、ドメイン名が「d-advantage.jp」であるとすると、FQDN名は「www.d-advantage.jp」となる。 もしユーザーがドメイン名を省略して、ホスト名だけで通信相手を指定しようとすると、DNSのリゾルバ(アプリケーションから渡されたコンピュータを、DNSサーバに渡して、名前解決を依頼する機能)は、ドメイン名の部分を補い、必ずFQDN名に変換してから、DNSサーバへと渡すことになっている。DN
Copyright © 2013 1 DNS 2013 7 19 DNS Summer Days 2013 JPRS @OrangeMorishita DNS Copyright © 2013 2 • : – 1965 9 21 47 – – : • 7 – Copyright © 2013 3 • – Copyright © 2013 4 1 • DNS • RFC 2181 DNS Summer Days 2012 DNS Copyright © 2013 5 2 • RFC 1034/1035 • DNS Summer Days 2012 DNS Copyright © 2013 6 • DNS 1. 2. referral 3. DNS 4. Copyright © 2013 7 • DNS • DNS – • – dig • DNS Copyright © 2013 8 • di
IPアドレスの返却とは IPアドレスの返却には、以下の2種類があります。 割り当て済みIPアドレスのIP指定事業者プールへの返却 割り振りブロックの、IP指定事業者からJPNICへの返却 割り当て済みIPアドレスのIP指定事業者プールへの返却が完了した後、 再度割り当てを行うことができます。 割り振りの返却と割り当ての返却 割り振りアドレスの返却は指定事業者管理下のアドレス空間をJPNICに返却することを指します。 従って、このアドレス空間は当該指定事業者の管理下空間ではなくなります。 一方、割り当てアドレスの返却はネットワークへ割り当てたアドレスを指定事業者の管理下アドレスプールに返却することを指します。 その空間は引き続き指定事業者管理下の空間であり、 また別のネットワークにそのアドレスを割り当てることも可能です。 申請前にご確認ください 申請を行うにあたって注意が必要な点をご紹介して
あるゾーンの親ゾーンの委任情報(NSリソースレコード)が適切に設定されておらず、lame delegationになっていることを利用し、管理権限を持たない第三者がそのゾーン(ドメイン名)の乗っ取りを図る攻撃手法です。 外部のDNSサービスやホスティングサービスなどを利用する場合、そのサービスを利用するための委任情報を、親ゾーンに登録・設定します。例えば、example.jpの管理者がns-99.example.netで運営されるDNSサービスを利用する場合、jpゾーンに以下の委任情報を登録・設定します。 その後、example.jpの運用終了により当該サービスを解約すると、ns-99.example.netに設定されたexample.jpゾーンは削除されますが、親ゾーンに登録・設定された委任情報は削除されず、そのまま残ります。この委任情報を削除しなかった場合、example.jpゾーンはl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く