サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは本日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。
------------------------------------------------------------------------ ■DNSの健全な運用のために ~Lame Delegation編~ 2003/05/20(Tue) ------------------------------------------------------------------------ ▼はじめに DNSは、インターネットの基盤を支える大規模な分散データベースです。 DNSが全体として正しく動作することは、それぞれのゾーンが正しく運用され ているかどうかにかかっています。 DNSの設定が正しくないと、そのゾーンの情報を正しく参照することができな いだけでなく、トラフィックの増大など、他のネットワークに悪影響を及ぼす ことがあります。DNSのオペレータはこのことを十分に認識し、正しいDNS
Internet Initiative Japan Inc. © DNS Demystified DNS 2004/07/23 JANOG14 @ koji@iij.ad.jp haru@iij.ad.jp Copyright © 2004, Internet Initiative Japan Inc. 2 Internet Initiative Japan Inc. DNS … ^^; Authoritative JPNIC JPRS DNSQCTF (caching server) authoritative sever Copyright © 2004, Internet Initiative Japan Inc. 3 Internet Initiative Japan Inc. (authoritative server) ( LAN DNS RFC1918 ) Copyright
方法Aの場合、例えば www.newdomain.com の名前解決の流れは以下のようになります。 1 .com のネームサーバ(a.gtld-servers.net など) に、newdomain.com の NS を尋ねて、 ns.example.co.jp という名前を取得 2 .jpのネームサーバ(a.dns.jpなど)に、example.co.jp のNSを尋ねて、ns.example.co.jp のIPアドレスを取得 3 ns.example.co.jp に、www.newdomain.com のIPアドレスを尋ねて、IPアドレスを取得 方法Bの場合、 1 .com にnewsdomain.com のNSについて .com のネームサーバに問い合わせると、ns.newdomain.com という名前と共に、ns.newdomain.com のIPアドレスも一緒に返ってくる 2
モバイルでもDNSラウンドロビンはちゃんと動作しますか? PCであれば、だいたいのブラウザが対応していると聞きますが、モバイルはどうなんでしょうか? A、B、Cというサーバをラウンドロビンで動かした時に、Bが死んだとします。 その場合、PCはBに行かなくなると思いますが、携帯の場合はどうなんでしょうか? 携帯はキャリアのプロキシ?か何かを通っていそうなので、ちゃんと動くのかが気になります。 また、ラウンドロビンの弱点は何ですか? 今のところ気づいているのは、単に振り分けるだけだから1台に負荷が集中するかもしれないことくらいしかないです。 上の質問を見て、「あれっ、ラウンドロビンって、ブラウザのようなアプリケーションサイドで対応するものだっけ? gethostbyname 辺りで勝手にやっていて、アプリ側は渡された IP で繋ぐだけでは?」と思っていたら、それは、もう古い話らしい。 0000
いわゆるインターネットで、あるドメイン名のDNSサーバを別のサーバに変更(移行)する際の注意事項やら手順やら。 ※DNSについては、様々理解すべきことがあります。 ぜひこちらもご覧ください→ DNSについて。 前提など [note] 例として下記を前提として書きます。 対象のドメイン名 example.com 現在のDNSサーバ ホスト名(IPアドレス) ns01.example.com(aaa.aaa.aaa.aaa) ns02.example.com(bbb.bbb.bbb.bbb) 変更後のDNSサーバ ホスト名(IPアドレス) ns11.example.com(xxx.xxx.xxx.xxx) ns12.example.com(yyy.yyy.yyy.yyy) [/note] [note] この記事で言う「DNSサーバ」はいわゆる「権威サーバ」です。 「ネームサーバ」と同義として下
dig コマンドをたたくのはいいが内容が読めない・・・。ということで dig コマンドの内容を理解してみる。 digコマンドとは? digコマンドとは、domain information groperの略で、直訳すると「ドメイン情報の手探りツール」といった意味になります。ネームサーバに対して問い合わせを行い、その応答結果を表示するコマンドで、BINDとともに提供されています。 引用元 => @IT:DNS Tips:digコマンドとは ところで、BINDはなんでしょうか。 BINDとは? BIND(バインド、Berkeley Internet Name Domain、以前の呼名はBerkeley Internet Name Daemon)はインターネットでもっとも利用されているDNSサーバである。 引用元=>BIND - Wikipedia DNSサーバとのこと。 digコマンドの使い方
事業共創プログラム OPEN HUB for Smart World 未来をひらく「コンセプトと社会実装」の実験場 OPEN HUB for Smart Worldは、社会課題を解決し、わたしたちが豊かで幸せになる未来を実現するための新たなコンセプトを創り、社会実装を目指す事業共創の場です
岡山大学 山井成良 2011年4月 1. はじめに 2. 典型的な誤りと正しい書き方 2.1 SPFレコードが複数行存在する 2.2 機構(メカニズム)の記述に誤りがある 2.3 参照方法に誤りがある 2.4 必要な空白文字がない 2.5 その他の間違い 3. チェック方法 1. はじめに 迷惑メールは、現在のところ、送信元アドレスが詐称された状態で送られるものが大多数を占めます。これにより、迷惑メールの送信源追跡を困難にしたり、フィッシング詐欺に利用されたりします。そこで、送信元アドレスの詐称を防止する送信ドメイン認証技術が開発されました。 現在までに実用化されている送信ドメイン認証技術はいくつか存在しますが、そのうち最も普及しているものがSPF(Sender Policy Framework)です。平成22年6月時点におけるjpドメインでの普及率はドメイン数ベースで約40パーセントであ
DNSサーバを運営する場合は、スレーブ・サーバ(セカンダリ・サーバ)で冗長化する必要がある。その際に検討すべきはマスター-スレーブ間のゾーン転送とそのセキュリティである。(編集局) 規模の大小を問わず、ゾーンサーバは複数台で運用する必要があります。冗長化や負荷分散などさまざまな理由が挙げられますが、何よりドメインを取得してDNSサーバを運用するのであれば、サービスの品質を低下させないという自覚を持つ必要があります。 今回はスレーブ・サーバの運用と、そこで使用されるゾーン転送およびそのセキュリティについて見ていきます。 コラム スレーブ・サーバとセカンダリ・サーバ 本稿では、「マスター・サーバ」のゾーンデータを取得してDNS問い合わせに応答するサーバを「スレーブ・サーバ」と呼んでいます。 資料によっては、同様の意味で「プライマリ・サーバ」「セカンダリ・サーバ」が用いられる場合があり、その際「
DNSサーバで、あるドメインのサブドメインを定義/利用する場合、その方法には大きく分けて2つの方法がある。1つは既存のDNSのゾーン定義の中に、サブドメインのレコードも同時にすべて定義してしまう方法である。1つのDNSサーバで集中的にDNSサービスを提供、管理する場合に向いている。 もう1つの方法は、サブドメインに対するゾーンの定義を親のドメインとは分離して、独立した別のゾーンとして管理する方法である。ゾーンが異なれば、別のDNSサーバ上で分離して管理可能になり、部署ごとや地域ごとに異なるDNSサーバ管理者を任命して、その管理を依頼できるようになる。このような方法を「委任(delegation)」という(同一DNSサーバ上で複数のゾーンを管理することも可能)。 ここでは、イントラネット用途における、以上2つのサブドメインの作成方法について解説する。前者の、委任を利用しない方法についてはTI
named.confを調整する(CentOS5) BINDのnamed.confは不要といえるほど多数の設定が施せます。 ここでは割と使うかもしれない設定情報を例にします。 ・DNSフォワーディングの設定 ・自分が管理しているゾーンにだけ応答する(インターネットドメインは解決しない) ・ログファイルの出力 ・ACLでクライアント要求を制限する ・MXレコード DNSフォワーディングの設定デフォルトでは、知らないドメインはルートヒントへ問い合わせに行きます。つまり自力で遠いサーバへ接続しに行きます。 しかし毎回インターネットの解決にルートヒントを使うのも、イマイチです。 通常はフォワーダに一番近い上位DNSを指定し、名前の解決を上位DNSに任せます。 forwardersを指定すると、自分がmaster以外のゾーンは常に自分をセカンダリと認識し、上位DNSへ問い合わせます。 組織のDNSは集
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く