この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第18回です。
第2章では、要件定義で整理した条件をもとに、 IPアドレス、VLAN、ルーティング、冗長化、WANなどの 基本設計へ落とし込む方法を学びます。
DNS・DHCP設計とは？企業ネットワークで必要な設計項目を解説
DNSとDHCPは、利用者からは見えにくいサービスですが、 企業ネットワークの通信を支える重要な基盤です。 「DNSサーバーを2台置く」「DHCPでIPアドレスを配る」だけでは 十分な設計とはいえません。 名前空間、ゾーン、冗長化、スコープ、リース時間、 DHCPリレー、障害時の動作、運用方法まで含めて設計します。
中級編では、DNSの名前解決やDHCPによるIPアドレス配布、 DHCPリレー、DNS・DHCP障害の切り分けを学びました。
上級編で考えるのは、 「どのようなDNS・DHCP基盤を作れば、要件を満たせるのか」 です。
サーバーの台数だけではなく、 障害時の影響、拠点構成、VLAN数、端末数、将来拡張、 セキュリティ、運用担当者まで考えて設計します。
この記事を読み終えるとできること
- DNS・DHCP設計で決める項目を整理できる
- 社内DNSの名前空間とゾーンを設計できる
- DNSサーバーの冗長化を検討できる
- DHCPスコープと払い出し範囲を設計できる
- リース時間やDHCPオプションを判断できる
- DHCPリレーを含む構成を設計できる
- 障害時の影響を考えて冗長化できる
- 設計理由を顧客へ説明できる
DNS・DHCP設計とは何か
DNS・DHCP設計とは、 名前解決とIPアドレス自動設定を安定して提供するために、 サーバー配置、名前空間、ゾーン、スコープ、冗長化、 セキュリティ、運用方法などを決定する工程です。
DNSとDHCPは役割が異なります。
| サービス | 主な役割 | 停止した場合の代表的な影響 |
|---|---|---|
| DNS | ホスト名・ドメイン名とIPアドレスを対応付ける | 名前を使ったWeb・メール・業務システムへの接続が失敗する |
| DHCP | 端末へIPアドレスなどのネットワーク設定を自動配布する | 新規接続・リース更新する端末が正常なIP設定を取得できなくなる |
どちらもネットワークの「付加機能」のように見えますが、 企業ネットワークでは多数の通信がDNSとDHCPへ依存します。
DNS・DHCPサーバー自身へpingが通ることと、 DNS・DHCPサービスが正常に利用できることは別です。
設計ではサーバーの生存だけでなく、 名前解決、アドレス払い出し、リース更新、 ゾーン転送などサービス単位で考える必要があります。
DNS・DHCP設計の全体像
DNS・DHCP設計では、端末からサーバーまでの通信経路を 一つの構成として考えることが重要です。
DNS・DHCPを利用する企業ネットワークの基本イメージ
設計では4つの視点に分ける
機能
どの名前を解決するのか、 どのネットワークへIPアドレスを配布するのかを決めます。
可用性
サーバー障害や経路障害が発生しても サービスを継続する必要があるかを判断します。
セキュリティ
DNS問い合わせ、ゾーン転送、DHCP払い出しなどを 誰に許可するか決めます。
運用
レコード追加、スコープ変更、監視、 バックアップ、障害対応の方法を決めます。
要件からDNS・DHCPの設計条件へ変換する
基本設計では、先に製品や設定値を決めるのではなく、 要件定義で確認した内容を設計条件へ変換します。
| 要件・背景 | 設計で検討すること |
|---|---|
| 業務システムを名前で利用する | 社内DNSゾーン、レコード登録、DNSサーバー配置 |
| DNS障害で業務を止めたくない | DNSサーバー複数台構成、ゾーン同期、複数DNS配布 |
| PCを数百台運用する | DHCP利用、スコープサイズ、リース時間 |
| 複数VLANでDHCPを利用する | VLANごとのスコープとDHCPリレー |
| 端末数が今後増える | アドレスプールの余裕、スコープ拡張方法 |
| 拠点障害時も利用を継続する | DNS・DHCPサーバーの配置場所と冗長方式 |
設計値には理由を持たせます。
「DNSを2台にした」「リース時間を8時間にした」ではなく、 なぜ2台なのか、なぜ8時間なのかを 要件や利用状況へ結びつけて説明できる状態にします。
DNS設計で決めること
DNS設計では、単にDNSサーバーのIPアドレスを決めるだけではありません。 主に次の項目を設計します。
1．名前空間を決める
最初に、組織内でどのような名前を使用するのか整理します。
例：
www.example.com：インターネット公開Webmail.example.com：公開メール関連app01.corp.example.com：社内業務サーバーdns01.corp.example.com：社内DNSサーバー
公開用DNSと社内用DNSでは、利用者も公開範囲も異なります。 そのため、 外部公開する名前と社内だけで使用する名前を整理する ことが重要です。
2．DNSゾーンを決める
DNSサーバーが管理する名前空間をゾーンとして整理します。
| ゾーン例 | 用途 |
|---|---|
example.com |
外部公開サービスの名前管理 |
corp.example.com |
社内サーバー・社内端末向けの名前管理 |
| 逆引きゾーン | IPアドレスからホスト名を確認するために利用 |
大規模環境では、組織・拠点・管理責任ごとに ゾーンを分割する場合もあります。
3．登録するDNSレコードを整理する
| レコード | 代表的な用途 |
|---|---|
| A | ホスト名とIPv4アドレスを対応付ける |
| AAAA | ホスト名とIPv6アドレスを対応付ける |
| CNAME | 別名を設定する |
| MX | メール配送先を指定する |
| PTR | IPアドレスから名前を逆引きする |
| TXT | 各種検証・ポリシー情報などを登録する |
4．DNSサーバーの役割と配置を決める
企業ネットワークでは、DNSサーバーを データセンター、サーバーセグメント、クラウドなどへ配置します。
配置を決めるときは、次の点を確認します。
- どの利用者・拠点から利用するか
- DNSサーバーまでの通信経路
- 拠点間WAN障害時の影響
- サーバー障害時の代替経路
- クラウドからの名前解決が必要か
- 社内DNSと外部DNSをどのように連携させるか
5．フォワーダーを設計する
社内DNSサーバー自身が管理していない名前について、 どのDNSサーバーへ問い合わせを転送するのか決めます。
社内DNSから外部名前解決を行うイメージ
6．TTLを設計する
DNSでは、問い合わせ結果がキャッシュされる時間を考慮します。
TTLが長い場合は問い合わせ回数を抑えやすい一方、 IPアドレス変更後も古い情報が残る時間が長くなります。
TTLが短い場合は変更を反映しやすくなりますが、 DNS問い合わせ数が増える可能性があります。
たとえば移行直前だけTTLを短くし、 移行完了後に通常値へ戻すという運用があります。
重要なのは特定の数値を暗記することではなく、 変更頻度とキャッシュの影響を考えて決めることです。
DHCP設計で決めること
DHCP設計では、VLANやIPアドレス設計と連携して 「誰に、どのアドレスを、どの条件で配布するか」を決めます。
1．DHCPを使用するネットワークを決める
すべての機器をDHCPにする必要はありません。
| 端末・機器 | 一般的な検討 |
|---|---|
| 社員PC | DHCPによる自動設定を検討 |
| 無線LAN端末 | DHCPによる自動設定を検討 |
| ゲスト端末 | 専用VLAN・専用スコープを検討 |
| サーバー | 固定IPアドレスを基本として検討 |
| ルーター・スイッチ | 管理用IPは固定設定を基本として検討 |
2．スコープを設計する
DHCPスコープは、原則として IPサブネット・VLANとの対応関係が分かるように設計します。
例：
| VLAN | ネットワーク | DHCP払い出し範囲 |
|---|---|---|
| VLAN 10 社員PC | 10.10.10.0/24 | 10.10.10.100 ～ 10.10.10.199 |
| VLAN 20 技術部 | 10.10.20.0/24 | 10.10.20.100 ～ 10.10.20.199 |
| VLAN 30 ゲスト | 10.10.30.0/24 | 10.10.30.50 ～ 10.10.30.230 |
3．固定利用領域とDHCP領域を分ける
同じサブネット内で、固定IPとDHCPを混在させる場合は、 アドレス重複が起きないよう範囲を分離します。
10.10.10.0/24 のアドレス利用例
固定利用
10.10.10.1 ～ 99
ゲートウェイ、プリンター、固定端末など
DHCP
10.10.10.100 ～ 199
一般クライアント
予備
10.10.10.200 ～ 254
将来拡張・予約用
この数字は一例です。 実際には端末数、固定IP利用数、将来増加率を考慮して決めます。
4．リース時間を決める
DHCPで払い出したIPアドレスにはリース期間があります。
リース時間は、端末の入れ替わり頻度と 利用可能なIPアドレス数のバランスで考えます。
| 環境 | 考え方 |
|---|---|
| 社員PC中心 | 同じ端末が長時間利用するため、比較的長めでも運用しやすい |
| 来客用Wi-Fi | 利用者の入れ替わりが多いため、アドレス回収を早める設計を検討 |
| イベント会場 | 短時間に多数の端末が接続するため、プールサイズとリース時間を慎重に設計 |
「DHCPリース時間は必ず○時間」という正解はありません。
同時接続数、アドレス数、端末の滞在時間から設計する ことが重要です。
5．DHCPオプションを決める
DHCPではIPアドレスだけでなく、 クライアントが通信するために必要な情報も配布できます。
| 項目 | 内容 |
|---|---|
| サブネットマスク | 所属ネットワークを判断するための情報 |
| デフォルトゲートウェイ | 他ネットワークへ通信するための出口 |
| DNSサーバー | 名前解決で利用するDNSサーバー |
| ドメイン情報 | 環境に応じてクライアントへ配布 |
特にDNSサーバーの設定ミスは、 「IP通信はできるのに業務システムへ接続できない」 という障害につながります。
DHCPリレーを設計する
DHCPサーバーとクライアントが異なるIPネットワークに存在する場合、 DHCPリレーを利用する構成を検討します。
複数VLANからDHCPサーバーを利用する構成
1台のDHCPサーバーから複数VLANへIPアドレスを配布する場合、 L3スイッチやルーター側でDHCPリレーを設定します。
DHCPリレー設計で確認すること
- どのVLANでDHCPを利用するか
- DHCPサーバーのIPアドレス
- 冗長DHCPサーバーがある場合の転送先
- ルーティング上、DHCPサーバーまで到達できるか
- ACL・ファイアウォールで必要通信が許可されているか
- スコープとクライアントVLANが正しく対応しているか
DHCPサーバーが正常でも、リレー設定が誤っていれば配布できません。
「特定VLANだけIPアドレスを取得できない」場合は、 スコープだけでなくL3インターフェースの DHCPリレー設定も確認対象になります。
DNS・DHCPを冗長化する
DNS・DHCPは多数の端末が依存するため、 可用性要件に応じて冗長化を検討します。
DNSの冗長化
クライアントへ複数のDNSサーバーを設定し、 1台が利用できない場合でも名前解決を継続できる構成を検討します。
DNSサーバー2台構成
ただし、サーバーを2台にしただけでは不十分です。
- 両方へ必要なゾーン情報が存在するか
- レコードが同期されるか
- クライアントへ両DNSを設定しているか
- 両DNSまでのネットワーク経路が独立しているか
- 同じ電源・同じ仮想基盤障害で同時停止しないか
DHCPの冗長化
DHCPも、端末数や停止影響に応じて 複数サーバーによる冗長化を検討します。
負荷分散型
複数DHCPサーバーが通常時から払い出し処理を担当する方式です。
待機型
通常時は主系が処理し、障害時に待機系で継続する方式です。
実際の冗長方式は利用するDHCP製品やサービスにより異なります。 基本設計では、 どの障害まで継続させる必要があるか を先に決めます。
サーバー冗長化だけで終わらせない
| 障害 | 確認すべき設計 |
|---|---|
| DNS1障害 | DNS2へ問い合わせできるか |
| DHCP1障害 | DHCP2から新規払い出し・更新できるか |
| L3スイッチ障害 | DHCPリレー経路も冗長化されているか |
| WAN障害 | 遠隔拠点が中央DNS・DHCPへ依存していないか |
| 仮想基盤障害 | DNS1・DNS2が同一障害ドメインに集中していないか |
DNS・DHCPのセキュリティを設計する
DNS・DHCPはネットワーク基盤であるため、 誰でも自由に変更・利用できる状態にしてはいけません。
DNSで検討すること
- 社内向けDNS問い合わせを許可するネットワーク
- 外部から再帰問い合わせを受け付ける必要があるか
- ゾーン転送を許可するDNSサーバー
- DNSレコード変更権限
- 動的更新を許可する範囲
- 管理アクセスの接続元制限
- 問い合わせログ・変更ログの取得
DHCPで検討すること
- 正規DHCPサーバー以外からの払い出しを防止する
- 管理者以外がスコープを変更できないようにする
- アドレス払い出し状況を記録する
- 必要に応じてDHCP Snoopingなどを検討する
- ゲスト用と社内用のスコープを分離する
不正なDHCPサーバーが存在すると、 クライアントへ誤ったデフォルトゲートウェイやDNSサーバーを 配布される可能性があります。
DHCP設計はアドレス管理だけでなく、 アクセススイッチ側のセキュリティ設計とも関連します。
企業ネットワークのDNS・DHCP設計例
ここまでの内容を、小規模な本社ネットワークを例にまとめます。
要件
- 社員PCは約100台
- 社員PCはDHCPでIPアドレスを取得する
- サーバーは固定IPアドレスを使用する
- 社内システムをホスト名で利用する
- DNSサーバー1台の障害で業務を停止させない
- DHCPサーバー障害時にも新規端末を接続できる構成とする
ネットワーク構成
| 用途 | ネットワーク |
|---|---|
| 社員PC VLAN | 10.10.10.0/24 |
| サーバー VLAN | 10.10.100.0/24 |
DNS設計例
| 項目 | 設計値例 |
|---|---|
| DNS1 | 10.10.100.53 |
| DNS2 | 10.10.100.54 |
| 社内ゾーン | corp.example.com |
| 外部名前解決 | 指定した上位DNSへ転送 |
| クライアント設定 | DNS1とDNS2の両方をDHCPから配布 |
DHCP設計例
| 項目 | 設計値例 |
|---|---|
| 対象ネットワーク | 10.10.10.0/24 |
| 払い出し範囲 | 10.10.10.100 ～ 10.10.10.220 |
| デフォルトゲートウェイ | 10.10.10.1 |
| DNS | 10.10.100.53、10.10.100.54 |
| DHCPサーバー | 10.10.100.61、10.10.100.62 |
| DHCPリレー | 社員PC VLANのL3インターフェースに設定 |
この構成では、DNS・DHCPだけを見るのではなく、 VLAN設計、IPアドレス設計、ルーティング設計、 冗長化設計と組み合わせて考えています。
基本設計の各項目は独立していません。
DNS・DHCP設計書に残すパラメータ
基本設計では、 後工程の詳細設計・構築担当者が判断できる情報を残します。
DNS設計表の例
| 項目 | 記載内容例 |
|---|---|
| サーバー名 | DNS01 / DNS02 |
| IPアドレス | 10.10.100.53 / 10.10.100.54 |
| 役割 | 社内名前解決 |
| 管理ゾーン | corp.example.com |
| 逆引きゾーン | 必要なネットワークを定義 |
| フォワーダー | 転送先DNSを記載 |
| 冗長方式 | DNS01・DNS02の2台構成 |
| 監視 | サービス状態・名前解決確認 |
DHCP設計表の例
| 項目 | 記載内容例 |
|---|---|
| スコープ名 | VLAN10-EMPLOYEE |
| ネットワーク | 10.10.10.0/24 |
| 払い出し範囲 | 10.10.10.100 ～ 10.10.10.220 |
| 除外・予約範囲 | 固定利用領域を記載 |
| デフォルトゲートウェイ | 10.10.10.1 |
| DNSサーバー | 10.10.100.53 / 10.10.100.54 |
| リース時間 | 利用環境から決定した値 |
| DHCPリレー | 設定対象L3インターフェースを記載 |
| 冗長方式 | 採用方式と役割を記載 |
詳細設計ではさらに、 実際の製品設定、サービス設定、 ゾーン転送条件、アクセス制御などへ具体化していきます。
DNS・DHCP設計でよくある失敗
1．DNSを2台置いただけで安心する
同じ仮想基盤、同じネットワーク、同じ電源へ依存していると、 共通障害で2台とも利用できなくなる可能性があります。
2．クライアントへDNSを1台しか配布しない
DNS2を構築しても、クライアントがDNS1しか知らなければ 冗長化の効果を得られません。
3．固定IPとDHCP範囲を重複させる
同じIPアドレスを固定端末とDHCPクライアントが使用すると、 IPアドレス重複障害につながります。
4．端末数と同じ数しか確保しない
将来増加、予備端末、一時利用端末などを考慮しないと、 DHCPプールを早期に使い切る可能性があります。
5．DHCPリレーを忘れる
DHCPサーバーが別セグメントにいる場合、 必要なリレー設定がなければアドレスを取得できません。
6．サービス試験をしない
pingだけではDNS・DHCPの正常性を確認できません。 名前解決や実際のアドレス取得まで試験します。
顧客・上司へDNS・DHCP設計をどう説明するか
技術に詳しくない相手へ 「DNSを冗長化します」「DHCPリレーを設定します」 と説明するだけでは、設計の価値が伝わりにくい場合があります。
DNS冗長化の説明例
社内システムはサーバー名を使って接続するため、 DNSが停止するとネットワーク自体が正常でも 多くの業務システムへ接続できなくなる可能性があります。 そのためDNSサーバーを複数構成とし、 1台故障時も名前解決を継続できる設計とします。
DHCP利用の説明例
社員PCへIPアドレスを手作業で設定すると、 入力ミスやアドレス重複が発生しやすく、 端末増加時の運用負荷も大きくなります。 DHCPで設定を一元管理することで、 クライアント設定を標準化し、運用負荷を抑えます。
上流工程では「技術 → 業務影響」に変換する
| 技術設計 | 顧客への説明 |
|---|---|
| DNSを冗長化 | 1台故障時も業務システムの名前解決を継続する |
| DHCPを利用 | 端末設定を標準化し、設定ミスと運用工数を減らす |
| DHCPリレー | 各フロアへDHCPサーバーを個別配置せず集中管理する |
| アドレスプールに余裕を確保 | 端末増加時のネットワーク変更を抑える |
DNS・DHCP設計で使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| DNS server | DNSサーバー |
| Name resolution | 名前解決 |
| DNS zone | DNSゾーン |
| Forwarder | フォワーダー・転送先 |
| Zone transfer | ゾーン転送 |
| DHCP scope | DHCPスコープ |
| Address pool | アドレスプール |
| Lease time | リース時間 |
| DHCP relay | DHCPリレー |
| Default gateway | デフォルトゲートウェイ |
設計レビューで使える表現
Two DNS servers will be configured for redundancy.
冗長化のため、DNSサーバーを2台構成とします。
The DHCP scope must have enough addresses for future growth.
DHCPスコープには将来増加を考慮した十分なアドレスを確保する必要があります。
DHCP relay will be configured on each client VLAN.
各クライアントVLANにDHCPリレーを設定します。
What is the required DNS availability?
DNSにはどの程度の可用性が必要ですか？
理解度チェック
DNS・DHCPの用語ではなく、 設計判断ができるか確認してみましょう。
問題1． DNSサーバーを2台構築したにもかかわらず、 クライアントにはDNS1のIPアドレスしか設定されていません。 この設計の問題点は何ですか。
解答を見る
DNS2が存在してもクライアントがDNS2を利用できないため、 DNS1障害時の冗長化が十分に機能しません。 DHCPや端末設定を含めて複数DNSを利用できるよう設計します。
問題2． DHCPサーバーは10.10.100.0/24にあり、 クライアントは10.10.10.0/24にあります。 DHCPサーバーへルーティングできるだけで十分でしょうか。
解答を見る
十分とは限りません。 異なるセグメントのDHCPサーバーを利用する場合は、 L3スイッチやルーターでDHCPリレーを設計する必要があります。
問題3． 社員PCが現在90台あり、DHCP払い出し範囲を 90アドレスだけ確保しました。 どのような問題が考えられますか。
解答を見る
端末増加、交換端末、一時利用端末などに対応できず、 DHCPアドレスプールが枯渇する可能性があります。 将来増加や最大同時接続数を考慮して設計します。
問題4．
DNSサーバーへpingは成功しますが、
app01.corp.example.comへ接続できません。
ping成功だけでDNS正常と判断できますか。
解答を見る
判断できません。 pingでは主にIP到達性を確認しているだけです。 DNSサービスが動作しているか、 対象レコードが存在するか、 実際に名前解決できるかを確認する必要があります。
問題5． DNS1とDNS2を同じ物理ホスト上の仮想マシンとして配置した場合、 どのようなリスクがありますか。
解答を見る
物理ホストや仮想基盤の障害により、 DNS1とDNS2が同時停止する可能性があります。 冗長化ではサーバー台数だけでなく、 共通障害点も確認します。
実践演習：DNS・DHCP基本設計を作成する
次の要件からDNS・DHCP設計を考えてください。
顧客要件
- 本社に社員200名が勤務する
- 社員PCはDHCPで設定したい
- 現在のPCは180台、3年後には230台を想定する
- 社員PC用ネットワークは10.20.10.0/24
- サーバーネットワークは10.20.100.0/24
- 社内システムはホスト名でアクセスする
- DNSサーバー1台障害時も業務を継続したい
- DHCPサーバーはサーバーネットワークへ集約する
課題1．DNS構成を決める
次の項目を決めてください。
- DNSサーバー台数
- DNSサーバーの配置
- 社内DNSゾーン
- クライアントへ設定するDNSサーバー
- 障害時の動作
課題1の設計例を見る
- DNSサーバーは2台構成とする
- サーバーネットワークへ配置する
- 例として社内ゾーンをcorp.example.comとする
- クライアントへDNS1・DNS2の両方を配布する
- DNS1障害時はDNS2で名前解決を継続できる構成とする
課題2．DHCPスコープを決める
将来230台まで増える想定を踏まえ、 10.20.10.0/24をどのように利用するか考えてください。
固定・予約領域：
リース時間の考え方：
課題2の考え方を見る
/24には利用可能なアドレス数の上限があるため、 230台のPCに加えてゲートウェイ、固定利用、 将来増加、予備端末まで考えると余裕が小さくなります。
この場合は単純に払い出し範囲を決めるだけでなく、 10.20.10.0/24で将来要件を本当に満たせるか をIPアドレス設計へ戻って再確認することが重要です。
課題3．DHCPリレーを設計する
DHCPサーバーは10.20.100.0/24、 クライアントは10.20.10.0/24に存在します。 どの機器へどのような機能が必要でしょうか。
転送先：
確認する関連設定：
課題3の設計例を見る
社員PC VLANのデフォルトゲートウェイとなる L3スイッチまたはルーターへDHCPリレーを設定し、 DHCPサーバーへ転送します。
あわせてルーティング、ACL、 DHCPスコープ、冗長DHCPサーバーへの到達性を確認します。
自分の言葉で説明する課題
顧客から 「DNSとDHCPはサーバーを1台ずつ置けば十分ではないのですか？」 と質問されました。
可用性と業務影響を含めて説明してください。
説明例を見る
DNSは多くの業務システムの名前解決に利用するため、 1台だけの場合、そのサーバー障害によって ネットワーク自体が正常でもサービスへ接続できなくなる可能性があります。
またDHCPが停止すると、 新しく接続するPCやIPアドレスの更新が必要なPCが 正常な設定を取得できなくなる可能性があります。
そのため、業務上どの程度の停止を許容できるか確認し、 必要な場合はサーバーと通信経路を冗長化します。
まとめ
- DNS・DHCP設計では、サーバー配置だけでなく 名前空間、ゾーン、スコープ、冗長化、運用まで決める
- DNSでは公開・社内の名前空間、ゾーン、 レコード、フォワーダー、TTLなどを設計する
- DNSを冗長化するときは、サーバー台数だけでなく クライアント設定と共通障害点も確認する
- DHCPではVLAN・サブネットごとに 払い出し範囲、除外領域、リース時間、配布情報を設計する
- DHCPサーバーとクライアントが異なるネットワークにいる場合は DHCPリレーを検討する
- アドレスプールは現在の台数だけでなく、 将来増加と最大同時接続数を考慮する
- DNS・DHCPはVLAN、IPアドレス、ルーティング、 冗長化、監視設計と連携して考える
- 上級編では「何を設定するか」だけでなく、 「なぜその設計にするのか」を説明できることが重要
良いDNS・DHCP設計とは、 正常時に動くだけでなく、 障害時・端末増加時・変更時にも 安定してネットワークサービスを提供できる設計です。
第2章「基本設計」では、 要件定義で整理した条件を具体的なネットワーク構成へ 落とし込む方法を学びます。
コメント