ドメイン名解決の原則＃

ノートは先週、幸せに報われました。これらは私が先週更新するために一生懸命働いた2つの記事です。

この章の内容はDNSサービスです。リモート管理の章では、PUTTETを使用し、Hostsファイルを使用してドメイン名を相手のIPにポイントします。実際、DNSはすでに関与しています。

DNS（ドメインネームサービス）中国のドメインネームシステムは、ドメイン名とIPの間の変換を担当します。通常Webサイトにアクセスする文字列「wuhash.com」はドメイン名と呼ばれます。ネットワークの基本の章で説明したように、コンピューターはIPアドレスを使用して通信します。 IPの増加とメモリ不足の問題を解決するために、DNSが登場しました。ドメイン名とIPの対応を記録したアドレス帳と考えてください。

IPv4アドレスが枯渇し、IPv6の時代が到来し始めていることを私たちは知っています。

[ドメイン名解決]（https://cloud.tencent.com/product/cns?from=10680）システムについて話すとき、ほとんどの場合、DNSを指しますが、なぜそう言うのですか？小規模なローカルエリアネットワークでは、通常、別のドメイン名解決サービスであるMicrosoftのWINSがあります。

通常のwww.wuhash.comはFQDDN（Fully Qualified Domain Name）と呼ばれ、ドメインの一般名とコンピューター名、wwwはホスト名、wuhash.comはドメインです。 DNSは分散システムであり、サーバーは世界中に散在しています。各DNSサーバーは、対応するレコードを格納する独自のデータベースを維持します。 DNS全体の構造は次のとおりです。

各ドメインに対応するDNSサーバーはすべてのドメインのDNSレコードを持っていないため、クエリが要求されると、最初に要求がルートドメインに転送され、ルートドメインがレベルごとにターゲットドメインに委任されます。現在、ルートドメインはICANNによって管理されています。

さまざまな種類のレコードもあります。次の図は、Dnspodの分析を示しています。

ここにいくつかの一般的に使用されるレコードがあります、そして理解するためにいくつかがあります

SOA：開始機関であるSOAレコードは、データのバージョンと更新および有効期限の情報を設定します。
PTR：IP解決をドメイン名に逆にする

DNSクエリ構造##

このセクションでは、DNSのアプリケーションと展開の詳細を紹介します

ドメインには、マスタードメインネームサーバー（マスターDNS）、セカンダリドメインネームサーバー（スレーブDNS）、およびキャッシュサーバー（キャッシュDNS）の3つのDNSサーバーの役割があります。

マスターDNS：ゾーンデータファイルを含むDNSサービスサービスを提供します
スレーブDNS：データファイルはマスターの同期から取得されます
キャッシュDNS：クライアントクエリの代わりにゾーンデータファイルが含まれていません。結果はキャッシュに保存され、TTLが到着するとキャッシュ結果は削除されます。

ホームネットワークでは、一般的なネットワーク構造は、光モデムアップリンクオペレータによって提供される光ファイバであり、ホームLANのワイヤレスAPまたはスイッチはダウンストリームに接続されます。光モデムダイヤルは、IP、DNS、およびその他の情報を取得します。ここでのDNSは、実際にはオペレーターが提供するキャッシュDNSサーバーです。追加の構成が実行されない場合、LANのホストDHCPによって取得されるDNSは、光モデムまたはワイヤレスAPのLANポートIPです。 LAN IPがDNSとして使用される場合、クライアントのDNS要求はプロキシされます（転送）。 DNSアドレスを直接使用する場合、DNS要求は設定されたサーバーに直接送信されます。

したがって、DNS要求が事前定義されたサーバーに送信された後に何が起こるか

DNS要求プロセス中、クライアントからローカルサーバーへのプロセスは再帰クエリと呼ばれ、ルートサーバーからローカルサーバーによるサーバーへのクエリへのプロセスは反復クエリと呼ばれることがわかります。

DNSサービスのインストール##

企業内のユーザー数が一定の規模に達すると、ネットワークトラフィックの最適化が問題になります。 1つの方法は、独自のDNSサーバーを構築して、境界ゲートウェイでのDNS要求の転送量を減らし、より多くの帯域幅を解放することです。次回WinServerのDNSServerを作成する機会があったときは、UbuntuでのDNSサービスの確立について紹介します。最も広く使用されているDNSサーバーソフトウェアは、複数のプラットフォームをサポートするBInd（Berkeley Internet Name Domain）です。デフォルトでは、サービスにTCP 53 / UDP53ポートを使用します。クライアントはサービスのクエリ時にUDPポート53を使用し、TCPポートはプライマリDNSとセカンダリDNS間の同期とデータ送信に使用されます。特別な場合、クライアントがDNSクエリ要求を送信した後、受信した応答の全長が512バイトを超え、TCPを使用してクエリ要求を再送信します。

sudo apt install bind9 dnsutils #テストツールdighostnslookupおよびその他のコマンドはdnsutilsパッケージから取得されます
cat /etc/bind/db.root #このファイルには、すでに世界中に配布されている13のルート論理ドメイン名サーバーアドレスが含まれています。急いでIPv4アドレス、さらにはIPv6アドレスもあります。ここに質問があります.13のルート論理ドメインネームサーバーアドレスは、13のルートドメインネームサーバーアドレスのみを表すのに十分ですか？いいえ、13個のIPはanycast IPであり、実際には物理サーバーのanycastミラーポイントに対応しています。 IPは、ルートを最も近い対応するノードにルーティングします。
ll /usr/sbin/named #メインプログラムファイル
cat /etc/bind/named.conf #メイン構成ファイル、多くの構成ファイルへの入り口
/etc/bind/named.conf.options #DNS転送サーバーをキャッシュDNSサーバーになるように構成します
/etc/bind/named.conf.local #内部ゾーンを定義するファイル
/etc/bind/named.conf.default-zones #ゾーンを定義するファイル

sudo vim /etc/bind/named.conf.options
acl "local"{10.10.10.10/24；
} # 許可されるDNS要求ネットワークセグメントを指定します
options {
 recursion yes； #再帰を許可する
 listen-on {10.10.10.131;}； #リスニングネットワークカードを指定する
 // forwarders {//  8.8.8.8} #転送するDNSサーバーを指定します
}; # ここではすべての構成を示したわけではなく、変更された部分のみを示したことに注意してください。

zone "sina.com.cn"{
 type forward;
 forwarders {1.1.1.1;};};#ゾーン転送を定義し、"sina.com.cn"ドメインの下のホストレコードは1に転送されます.1.1.1

上記の構成ファイルを構成したら、同じネットワーク下のホストを使用してDNSテストとして設定できます。このプロセス中にパケット検証を表示するには、wiresharkを使用することをお勧めします。

DNSサーバーは構成されていますが、ネットワークカード構成でDNSを指定する必要があります。特定のルートドメインサーバーの詳細については、ここで確認できます。 DNSサーバーをパブリックネットワークに展開する場合は、このドメイン外で再帰クエリを無効にすることをお勧めします。

Bindの代替##

Djbdns:Dbndns、ndjbdns
dnsmasq：DNS + DHCPパッケージング用の軽量ソリューション
PowerDNS：モジュラーKaiyuanDNSサーバーソフトウェア

マスターサーバーの構成###

DNSは、ドメイン名とIP間の変換を解決するシステムです。 FQDNからIPへの解決を順方向解決として定義し、IP解決をfqdnとして逆方向解決として定義します。ここでの構成は前方分析です。

構成環境

DNS server : Ubuntu server (10.10.10.131)、Bind9
WEB server : Ubuntu server(10.10.10.130)、Apache
DNS client：Kali Linux(10.10.10.132)

sudo vim /etc/bind/named.conf.local 
zone "example.com"{
 type master;
 file "/etc/bind/db.example.com";};

cd /etc/bind/
cp db.local db.example.com

sudo vim db.example.com
@ IN NS ns  #ファイルの最後にある構成を対応するホストレコードに変更します
@ IN A 10.10.10.130
ns IN A 10.10.10.130 #nsレコードを追加する必要があります。追加しないと、エラーが報告されます
www IN A 10.10.10.130 #ホストレコード
# ここで説明するために、同じホストレコードが複数のAレコードアドレスを追加できるため、負荷分散の効果が得られます。DNSキャッシングメカニズムが実験的な解決結果に影響することに注意してください。ウィンドウで「ifconfig」を使用してください。/flushdns」でキャッシュをクリアします。

sudo named-checkconf    #構成ファイルを確認してください
sudo named-checkzone example.com /etc/bind/db.example.com #ゾーンファイルを確認する
sudo systemctl restart bind9  #サービスを再開します
sudo systemctl status bind9 #ステータスを確認する

ここでは他の仮想マシン検証を開かず、Kaliの下のツールを使用してテストします。

dig example.com  @10.10.10.131 ANY #DNSサーバーを10として指定します.10.10.131、すべてのレコードを照会
nslookup -qt=A example.com 10.10.10.131 #DNSサーバーを10として指定します.10.10.131.タイプAのレコードを照会しても、digをチェックできないという意味ではありません。両方のツールを使用できます。

逆解析構成####

FQDNの構成が完了したら、リバースゾーンを構成します。レコードタイプのレコードの1つがMXレコードであることを忘れないでください。メールボックスサーバーのアドレスを設定し（メールボックスサーバーの構築については後で紹介します）、前に「example.com」という名前のゾーンを作成できます。「example.com」を使用できます。「メールを送信します。ここに問題がありますか？実際、私は「example.com」ドメイン名を所有していません。受信者が私を受け取ったときに自分の信頼性を確認するにはどうすればよいですか？逆解析の役割が反映されています。

cd /etc/bind/
sudo vim named.conf.local #新しいゾーンを作成する
zone "10.10.10.in-addr.arpa"{ 
 type master;
 file "/etc/bind/db.10.10.10";}; #上で-addrの部分では、アドレスは解析されたネットワークセグメントの逆の順序です。アドレスが特別であるため、ここにいます。
cp 

cp db.127 db.10.10.10
sudo vim db.10.10.10 #他の構成はあまり導入されていません。ここに大きな落とし穴があります。FQDNの後にポイントを記述しないでください。-Checkzoneはエラーを検出できませんが、構成を効果的に行うことはできません
@ IN  NS ns.example.com.130 IN     PTR example.com.

kalilinuxで確認する

dig -x 10.10.10.130 @10.10.10.131 #digコマンドを使用して分析を逆にします。構成が正しい場合は、対応するPTRレコードを確認できます。

スレーブDNSサーバーの構成##

冗長性は常に話題になっています。スレーブDNSサーバーの構成は非常に必要です。必ずしもスレーブが1つだけではありません。変更レコードはマスターでのみ操作されます。スレーブサーバーはバージョン番号（シリアル、手動でのみ変更可能）を介して同期するように通知されます。セキュリティ上の理由から、サーバーはゾーン転送をグローバルに禁止し（ドメイン内のすべてのDNSレコードを同期し）、指定されたIPと指定されたゾーンのSLaveサーバーのみにゾーン転送の実行を許可する必要があります。ゾーン転送：すべてのDNSレコードの転送を申請します。ゾーン転送は、DNSサーバー間、またはクライアントとDNSサーバー間で発生する可能性があります。

dig @10.10.10.130 example.com axfr #ゾーン転送は禁止されていません。このコマンドを使用してすべてのレコードをフェッチできます

マスターDNSサーバー上のファイルを変更する

sudo vim named.conf.options
options {
allow-transfer {none;};}; #この行をオプションに挿入します
sudo systemctl restart bind9 
sudo systemctl status bind9

次に、Kaliでdigコマンドを使用して、ゾーン転送が不可能であることを確認します。

sudo vim named.conf.local #ローカル構成ファイルの優先順位はオプションによるものです
allow-transfer {10.10.10.130;};
# ゾーン内のゾーンとリバースゾーンに転送できるIPを追加します。

以前に構成されたnsレコードもそれに応じて変更されました。「10.10.10.133」は、私がクローンをリンクしたマシンです。

以下はスレーブサーバーの構成です

sudo vim /etc/bind/named.conf.options #リンクされたクローン、ファイルも存在します
listen-on {10.10.10.133;}; #スレーブとして構成されているネットワークカードアドレスを変更し、残りの構成は変更しないでください
sudo vim named.conf.local
zone "example.com"{
 type slave;
 file "db.example.com";
 masters {10.10.10.131;};};
zone "10.10.10.in-addr.arpa"{
 type slave;
 file "db.10.10.10";
 masters {10.10.10.131;};};#ファイルとファイルファイルの種類に注意してください

sudo systemctl restart bind9 
sudo systemctl status bind9

cd /var/cache/bind #同期キャッシュの場所、暗号化
sudo grep bind /var/log/syslog #除外できるバインドに関するシステムログを確認します
# ここで、作成者は実験の最初の数回はキャッシュに同期しませんでした。"sudo systemctl status bind9"マスターがエラーを報告し、変更を確認した後、同期が成功したことがわかります。

dig www.example.com @ 10.10.10.133を使用してカリの下で確認すると、得られたレコード結果は「10.10.10.131」と同じになります。解決レコードを変更し、マスターDNS構成ファイルのバージョン番号を更新して、サービスを再起動します。構成が正しければ、変更された結果も同期されます。同期を高速化するために、この構成をマスターのローカルに追加することをお勧めします。

sudo vim named.conf.local
zone "example.com"{
 type master;
 file "/etc/bind/db.example.com";
 allow-transfer {10.10.10.133;};
 Also-notify {10.10.10.133;}; #追加された構成
};
zone "10.10.10.in-addr.arpa"{
 type master;
 file "/etc/bind/db.10.10.10";
 allow-transfer {10.10.10.133;};
 Also-notify {10.10.10.133;}; #追加された構成
};

あとがき##

ここに書かれているように、手首は本当にそれを保持することができず、腱滑膜炎はそれを本当に傷つけることはできません。首の痛みは私の座った姿勢に関係しているのかもしれません。次の章の内容は少し怖いので、一週間後に作ってみます。

参照リンク##

DNSバインドサービス構成の解決

エントリーからマスターまでのUbuntuサーバー

DNSの原則を始める

第7章DNSと基本から詳細へのバインド

Ubuntuサーバー第8章DNSサービス