サーバー統合の一環としてUNIX上のBINDで動作していたDNS(ドメイン・ネーム・システム)サーバーをWindows 2000 Serverに移行し,Windows 2000 Serverの標準機能を使ったプライマリDNSサーバーを構築しようとしています。現状のネットワーク・ポリシーを踏襲するため,各ゾーンの管理は,GUI(グラフィカル・ユーザー・インターフェース)管理コンソールを用いずに,リモート・マシンからNTLM認証のtelnetでログオンして標準プライマリとして構築したゾーンのゾーン・ファイルを直接修正する方法を考えました。 UNIXのBINDの場合はゾーン・ファイルの内容を修正後,ファイルのバージョンを示すシリアル番号を1以上増加させた上で,BINDのプロセスにHUPシグナルを送信してファイルの再読み込みを指示すると,ゾーン・ファイルの内容が反映されます。Windows 200
2020年7月14日(日本時間)、Microsoft社よりWindows DNSサーバにリモートでコード実行が可能な脆弱性が公開されました[1]。これは不正なDNSレスポンスをWindows DNSサーバが適切に処理できないことにより影響を受けるものです。 本脆弱性はCheckPoint社のリサーチャーによって発見され、"SIGRed"と命名されました[2]。共通脆弱性評価システム(CVSS)においても最高となるスコア10と評価され、今後の攻撃コード公開状況によっては、「ワーム化可能」とされる脆弱性です。 本記事では、本脆弱性の検証結果やその悪用を試みる通信の痕跡の確認方法について解説します。 本脆弱性の概要 本脆弱性は、DNSにおけるリクエストや処理の認証に使われるSIGレコード(電子署名が定義されているリソースレコード)に対するクエリの応答に、巨大なサイズのメッセージを付与することでタ
Microsoft Security Response Centerより「Windows DNS サーバの脆弱性情報 CVE-2020-1350 に関する注意喚起」が発行されました。 msrc-blog.microsoft.com 当該脆弱性については、報告元であるCheck Pointより、SIGRedと命名されています。 research.checkpoint.com CVSSにて基本スコア10.0となっている当該脆弱性について、海外のブログやWebニュースでも広く取り上げられていたので、本記事でもまとめてみます。 目次 影響を受ける製品とその影響 脆弱性の対応策 まとめ 影響を受ける製品とその影響 当該脆弱性CVE-2020-1350はMicrosoft製のDNSサーバにおける実装に起因するため、すべてのバージョンのWindows Server(Windows Server2003~
皆様、こんばんは。 今回の投稿は、世界最大の検索サイトを運営する「Google」が提供する「Google Public DNS」というDNSサーバーに関する投稿となります。 それでは今回の投稿にまいりましょう。 【スポンサーリンク】 はじめに さて改めまして今回の投稿は、世界最大の検索サイトを運営する「Google」が提供する「Google Public DNS」というDNSサーバーに関する投稿になります。 当記事を参照される皆様が、お使いのパソコンでインターネットを利用する場合は、必ずDNSサーバーを使用します。 そもそもDNSサーバーとは、「ドメインネームシステム」の略称であり、皆様がお使いのパソコンでインターネットを利用する際に、インターネット上のWebサイトのドメインをIPアドレスに変換するという役割を担うサーバーになります。 そして今回の記事テーマである「Google Publi
DNS登録をコマンドプロンプトで実施しよう WindowsSeverでDNSサーバーにDNSを登録するとき、 レコードを1つ2つ追加するくらいならDNSマネージャーを使ってもよい。 けれど登録するレコードの件数が10や20、100を超えたらいちいちGUIで追加していくのは手間すぎる。 というわけで、DNSをコマンドプロンプトで一括登録してしまおう。 追加 少し解説しよう。 ゾーン名とはそのドメインが管理する範囲のことで、 多くは.comとか.jpとかであらわされる。 ホスト名とIPアドレスは言わずもがな。 で、一番厄介(覚えづらい)のが「A」の部分。 これはレコードタイプと呼ばれていて、DNSレコードの形式をあらわしている。 ちょっとわかりづらいので、コマンド全体から理解していきたい。 この追加コマンド全体を日本語に置き換えると、以下のようになる。 「[ゾーン名]で管理される[ホスト名]と
DNSのサブドメインを利用すると、地域や部署ごとにDNS名前空間を分離し、独立して運用することができる。DNSサーバでサブドメインを定義するには、委任を利用する方法としない方法の2とおりがある。委任を利用しない場合は、1つのゾーンの中に親ドメインとサブドメインの両方の情報を登録する。 DNSサーバでサブドメインを定義/利用する2種類の方法 DNS名前空間は階層的に構築されており、組織やネットワークの構造などに合わせて名前空間が設計され、利用されている。例えば、インターネットでは、トップレベルの.comや.net、.jpなどのドメインの下に会社名や組織名を付けたサブドメインを定義しているし、組織内では、ルートとなるドメインの下に、地域や部署ごとのサブドメインを定義して利用することが多い(サブドメインについてはLinux Squareの「BIND9によるサブドメインの運用と委任」も参考になる)
DNSサーバで、あるドメインのサブドメインを定義/利用する場合、その方法には大きく分けて2つの方法がある。1つは既存のDNSのゾーン定義の中に、サブドメインのレコードも同時にすべて定義してしまう方法である。1つのDNSサーバで集中的にDNSサービスを提供、管理する場合に向いている。 もう1つの方法は、サブドメインに対するゾーンの定義を親のドメインとは分離して、独立した別のゾーンとして管理する方法である。ゾーンが異なれば、別のDNSサーバ上で分離して管理可能になり、部署ごとや地域ごとに異なるDNSサーバ管理者を任命して、その管理を依頼できるようになる。このような方法を「委任(delegation)」という(同一DNSサーバ上で複数のゾーンを管理することも可能)。 ここでは、イントラネット用途における、以上2つのサブドメインの作成方法について解説する。前者の、委任を利用しない方法についてはTI
対象OS:Windows 2000 Professional/Windows XP Professional/Windows XP Home Edition/Windows 2000 Server/Windows 2000 Advanced Server 解説 DNSとは、IPアドレスと名前(FQDN名)を(相互に)変換するためのデータベース・サービスであるが、Windows 2000やXPのDNSクライアントには、DNSサーバに問い合わせた結果をシステムの内部にキャッシュしておいて、外部のDNSサーバへの問い合わせをなるべく抑制するという機能が含まれている。これを「DNSリゾルバ・キャッシュ」といい、実際には「DNS Client」サービスが担当している。「リゾルバ(resolver)」とは、名前解決(name resolution)を行うための機能やサービスのことを指す(一般的にはネー
適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012 DNS サーバーを管理するためのコマンド ライン インターフェイスです。 このユーティリティは、バッチ ファイルを作成して、日常的な DNS 管理タスクを自動化する場合やネットワークに新しい DNS サーバーを無人で簡単にセットアップして構成する場合に便利です。 構文 dnscmd <servername> <command> [<command parameters>] Parameters パラメーター 説明
WindowsサーバはDNSレコードの登録や削除をMMCから操作する事が出来るので、直感的に操作しやすくて便利なのですが、大量のレコードの登録や削除があった場合には、これらの作業がかなり面倒になってしまいます。 このような場合には、DNSCMDを利用してコマンドラインからDNSへの登録や削除を実行するようにすれば時間もかからず便利です。 追加と削除を行う場合にはそれぞれ/RecordAddと/RecordDeleteを利用します。 DNSレコードの追加 レコードを追加する場合の基本的なコマンドは以下のようになります。 例えばゾーンpnpk.localにserver001という名前を192.168.1.10で登録する場合には以下のようになります。 同時に逆引きレコードも追加する場合には以下のようになります。 DNSレコードの削除 レコードを削除を行う場合は以下のようになります。 /fを入力す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く